1 2012-11-24 01:45:37 <wizkid057> "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
2 2012-11-24 01:45:40 <wizkid057> but i wanna.....
3 2012-11-24 01:56:56 <D34TH> its not really a error
4 2012-11-24 01:57:04 <D34TH> its more of a "HEY LISTEN"
5 2012-11-24 01:57:05 <D34TH> its more of a "HEY LISTEN"
6 2012-11-24 01:57:31 <wizkid057> hm... wth is the difficulty on testnet3?
7 2012-11-24 01:57:52 <D34TH> sec
8 2012-11-24 01:57:53 <D34TH> ill get it
9 2012-11-24 01:57:54 <D34TH> ill get it
10 2012-11-24 01:58:07 <wizkid057> getinfo says 1, but that must be a lie
11 2012-11-24 01:58:43 <D34TH> "difficulty" : 177.61478768,
12 2012-11-24 01:58:54 <D34TH> i just dont think its done a full retarget to 1
13 2012-11-24 01:58:58 <D34TH> its supposed to be 1
14 2012-11-24 01:59:07 <wizkid057> doh
15 2012-11-24 02:00:03 <wizkid057> "difficulty" : 1.00000000,
16 2012-11-24 02:00:08 <wizkid057> not sure why mine is lying
17 2012-11-24 02:00:13 <D34TH> yea it shows that on mine
18 2012-11-24 02:00:18 <D34TH> but look 2 blocks back
19 2012-11-24 02:01:37 <wizkid057> interesting
20 2012-11-24 02:03:08 <D34TH> suddenly main net flips to one diff
21 2012-11-24 02:03:11 <D34TH> everyone cries
22 2012-11-24 02:03:32 <SomeoneWeird> lol
23 2012-11-24 02:06:43 <wizkid057> haha
24 2012-11-24 02:46:16 <Luke-Jr> wizkid057: getinfo tells you the difficulty of the LAST block
25 2012-11-24 03:46:36 <jgarzik> sipa: noted
26 2012-11-24 03:46:46 <jgarzik> ACTION is out of commission for a while, so fixups won't be immediate
27 2012-11-24 05:20:26 <swulf--> i have paytxfee=0.00 in bitcoin.conf, why is it that sendfrom/sendtoaddress will still sometimes charge a fee?
28 2012-11-24 05:21:15 <gmaxwell> swulf--: Bitcoin will apply a fee when it itself would have treated the txn as a DOS attack otherwise??? because it's rapidly respending recent payments or has outputs less than 0.01 BTC.
29 2012-11-24 05:21:16 <gmaxwell> swulf--: Bitcoin will apply a fee when it itself would have treated the txn as a DOS attack otherwise??? because it's rapidly respending recent payments or has outputs less than 0.01 BTC.
30 2012-11-24 05:21:36 <gmaxwell> ("it itself" and thus ~all your peers)
31 2012-11-24 05:21:45 <swulf--> understood
32 2012-11-24 05:22:20 <swulf--> is there a different rpc call that will tell me so i can confirm the fee before proceeding instead of just doing it behind the scenes?
33 2012-11-24 05:23:13 <gmaxwell> No, not currently. It's complicated because the fee need and amount depends on the state of all your inputs??? so new txn or blocks can change it.
34 2012-11-24 05:23:26 <gmaxwell> The gui prompts, but blocks all processing in bitcoin in order to accomplish that.
35 2012-11-24 05:23:27 <gmaxwell> The gui prompts, but blocks all processing in bitcoin in order to accomplish that.
36 2012-11-24 05:23:45 <swulf--> ah
37 2012-11-24 05:24:00 <swulf--> an 'acceptfeeiflessthanX' could work, in the rpc code
38 2012-11-24 05:24:19 <Luke-Jr> swulf--: if you merge my ancient pullreq, you can get bitcoind to error if the fee is >= some maximum
39 2012-11-24 05:24:24 <swulf--> as well as telling me what the fee ended up being in the output after executing sendfrom/sendto
40 2012-11-24 05:24:30 <gmaxwell> I believe luke had a patch for that basically.
41 2012-11-24 05:24:34 <swulf--> ah, neat
42 2012-11-24 05:24:43 <gmaxwell> Ah. yea.
43 2012-11-24 05:24:57 <Luke-Jr> 1645 (originally 557)
44 2012-11-24 05:24:58 <Luke-Jr> 1645 (originally 557)
45 2012-11-24 05:25:21 <Luke-Jr> gmaxwell: safe rest of your trip?
46 2012-11-24 05:25:22 <Luke-Jr> gmaxwell: safe rest of your trip?
47 2012-11-24 05:25:31 <gmaxwell> swulf--: if it helps you at all, the fee can't be higher than 0.05 BTC with the unmodified software??? and even that is only in the insane 100kbyte transaction case.
48 2012-11-24 05:25:56 <swulf--> well
49 2012-11-24 05:25:57 <swulf--> well
50 2012-11-24 05:26:11 <swulf--> if i'm running a merchant site, similar to mtgox, then you can imagine how the fees would add up
51 2012-11-24 05:26:14 <gmaxwell> Luke-Jr: I'm still not back home yet??? which is why I haven't been on much... I'm in Juno tonight.
52 2012-11-24 05:26:15 <gmaxwell> Luke-Jr: I'm still not back home yet??? which is why I haven't been on much... I'm in Juno tonight.
53 2012-11-24 05:27:15 <gmaxwell> swulf--: No, I can't in fact. Normal fees are only 0.0005 when they aren't zero. Making them larger requires really inefficient transactions (lots of dust inputs). Just charge your customers a fixed 0.001 fee??? or something like that??? on withdraws and you'll cover them easily.
54 2012-11-24 05:27:16 <Luke-Jr> gmaxwell: ah, well I hope the rest remains safe then! ???
55 2012-11-24 05:27:42 <gmaxwell> (even if a few are larger)
56 2012-11-24 05:27:43 <gmaxwell> (even if a few are larger)
57 2012-11-24 05:28:24 <swulf--> gmax, good call.
58 2012-11-24 05:28:26 <swulf--> thanks
59 2012-11-24 05:28:59 <Luke-Jr> swulf--: also more fair, since the sender isn't the one determining the fee cost ;)
60 2012-11-24 05:29:20 <Luke-Jr> swulf--: note that MtGox also has out-of-band peering agreements with some pools to process their transactions without fee in all cases
61 2012-11-24 05:29:45 <swulf--> that would be nice, but not good for a small site like what i'm interested in
62 2012-11-24 05:32:48 <swulf--> thanks:)
63 2012-11-24 06:15:24 <midnightmagic> wait "Juno" or "Juneau"?
64 2012-11-24 06:17:09 <gmaxwell> hah. The one you can wear flipflops at.
65 2012-11-24 06:32:08 <midnightmagic> LOL
66 2012-11-24 06:32:22 <midnightmagic> I was going to call you crazy.
67 2012-11-24 06:32:40 <midnightmagic> and then ask you say hello to some people
68 2012-11-24 07:19:47 <weenfan> looking for a way to broadcast a raw tx I made
69 2012-11-24 07:47:05 <weenfan> i wonder how long a never confirming tx will drop from blockchain.info?
70 2012-11-24 07:47:52 <weenfan> I send some coins that were double spent in another tx and mixed them w/ good coin .. any way to broadcast a raw tx I made that doesn't contain the bad coin?
71 2012-11-24 07:53:48 <freewil> create a new transaction without the bad coin?
72 2012-11-24 07:55:13 <weenfan> yep
73 2012-11-24 07:55:25 <weenfan> did that .. I have the rawtx made but no way to broadcast it
74 2012-11-24 07:55:55 <weenfan> sendrawtransaction from the console returns -22
75 2012-11-24 07:55:58 <freewil> sendrawtransaction rpc call
76 2012-11-24 07:56:11 <weenfan> 00:56:11 ??? TX rejected (code -22)
77 2012-11-24 07:56:29 <weenfan> It's still downloading the blocks though
78 2012-11-24 07:56:44 <freewil> maybe it doesnt have the inputs yet?
79 2012-11-24 07:56:56 <freewil> or it's invalid for some other reason
80 2012-11-24 07:57:01 <weenfan> 010000000278487e111c7fb119a5cfc95e66492cc21df66f04d87d5f70b6b682e19c17804b010000008a47304402208f596efbdde07d1a7bfe58adf11a372df7236dd7d0aea6aa16421734f2ff60720220ba4f36f2068eae3c66cee52d9d3fb5761c2d622e10ec0a738365d510b11a9c9f014104b5a121a1eeb30eccf50b319c3dcf7f4c8d313ef9f099b51c1b3badfbde82989df3b553d2419ffed3b0545eac9bcd2b3fd5ac40212ee1e943ed3d6c4923d84f15ffffffff894f7a17b745737b7516d50320eed76de30a61c42aff6924fcf3b018d19583300
81 2012-11-24 07:57:25 <weenfan> I'm thinking my client does not have the blockchain downloaded yet
82 2012-11-24 07:57:26 <weenfan> I'm thinking my client does not have the blockchain downloaded yet
83 2012-11-24 07:57:44 <freewil> probably
84 2012-11-24 07:57:47 <weenfan> blockchain.info has the bad transaction still in it's db
85 2012-11-24 07:57:48 <freewil> https://en.bitcoin.it/wiki/Raw_Transactions
86 2012-11-24 07:57:55 <weenfan> so I can't send it from there either
87 2012-11-24 08:00:01 <weenfan> anyone mind pasting that in their client's console? .. heh
88 2012-11-24 08:00:15 <weenfan> sendrawtransaction 010000000278487e111c7fb119a5cfc95e66492cc21df66f04d87d5f70b6b682e19c17804b010000008a47304402208f596efbdde07d1a7bfe58adf11a372df7236dd7d0aea6aa16421734f2ff60720220ba4f36f2068eae3c66cee52d9d3fb5761c2d622e10ec0a738365d510b11a9c9f014104b5a121a1eeb30eccf50b319c3dcf7f4c8d313ef9f099b51c1b3badfbde82989df3b553d2419ffed3b0545eac9bcd2b3fd5ac40212ee1e943ed3d6c4923d84f15ffffffff894f7a17b745737b7516d50320eed76de30a61c42aff69
89 2012-11-24 08:01:27 <weenfan> Error Pushing Transaction An outpoint is already spent .. << error from using https://blockchain.info/pushtx
90 2012-11-24 08:11:22 <weenfan> Trying out multibit .. :)
91 2012-11-24 10:49:47 <ThomasV> https://bitcointalk.org/index.php?topic=127536.msg1354466#msg1354466
92 2012-11-24 10:49:48 <ThomasV> https://bitcointalk.org/index.php?topic=127536.msg1354466#msg1354466
93 2012-11-24 10:50:07 <ThomasV> I suppose I might get banned for that post
94 2012-11-24 10:50:48 <sipa> little bobby tables...
95 2012-11-24 10:51:05 <ThomasV> yeah
96 2012-11-24 10:53:09 <ThomasV> unfortunately, theymos has no sense of humor
97 2012-11-24 10:53:11 <ThomasV> unfortunately, theymos has no sense of humor
98 2012-11-24 10:53:50 <sipa> oh, that's in bitcointalk? :s
99 2012-11-24 10:54:03 <ThomasV> yup :)
100 2012-11-24 10:54:30 <ThomasV> well, dropping tables is not the most interesting thing to try.
101 2012-11-24 10:54:31 <ThomasV> well, dropping tables is not the most interesting thing to try.
102 2012-11-24 10:58:48 <SomeoneWeird> <ThomasV> unfortunately, theymos has no sense of humor < lol +1 to that
103 2012-11-24 16:07:17 <sipa> ;;bc,blocks
104 2012-11-24 16:07:18 <sipa> ;;bc,blocks
105 2012-11-24 16:07:19 <gribble> 209385
106 2012-11-24 16:17:22 <Matt_von_Mises> For anyone confused about the "Segmented Block Relaying": https://bitcointalk.org/index.php?topic=103295.msg1354828#msg1354828
107 2012-11-24 16:34:14 <sipa> ;;bc,blocks
108 2012-11-24 16:34:15 <gribble> 209390
109 2012-11-24 16:34:15 <sipa> ;;bc,blocks
110 2012-11-24 17:32:48 <Matt_von_Mises> sipa: Thanks for replying to the thread. I made a reply: https://bitcointalk.org/index.php?topic=103295.0 The purpose of the proposal is primarily a method for parrellel block downloads.
111 2012-11-24 17:33:20 <Matt_von_Mises> It's a very rough idea. It's something that I might come back to at a later stage.
112 2012-11-24 17:34:31 <BlueMatt> Matt_von_Mises: Im still confused as to why you should just download part of a block at a time, seems needless to split up individual blocks
113 2012-11-24 17:35:34 <Matt_von_Mises> Not "part of a block at a time" but "multiple parts of a block at once"
114 2012-11-24 17:35:53 <BlueMatt> yes, ok, but still...why?
115 2012-11-24 17:37:12 <Matt_von_Mises> The same reason bittorrent downloads from multiple peers.
116 2012-11-24 17:37:21 <Matt_von_Mises> "I do not suggest that this proposal is important right now. I was thinking about the future and the increasing demand for block-space."
117 2012-11-24 17:37:57 <BlueMatt> is this a suggestion for if max block size is increased or for when blocks reach current max block size?
118 2012-11-24 17:38:08 <D34TH> hey bluematt, if a client is synced up to the network
119 2012-11-24 17:38:09 <BlueMattBot> Project Bitcoin build #156: FAILURE in 5.2 sec: http://jenkins.bluematt.me/job/Bitcoin/156/
120 2012-11-24 17:38:14 <BlueMatt> awww
121 2012-11-24 17:38:18 <D34TH> do all blockchain files have the same hash?
122 2012-11-24 17:39:01 <maaku> D34TH: no
123 2012-11-24 17:39:10 <D34TH> maaku, why not?
124 2012-11-24 17:39:27 <BlueMatt> orphans
125 2012-11-24 17:39:30 <maaku> blocks are stored in order received, not block chain order
126 2012-11-24 17:39:32 <maaku> and orphan blocks
127 2012-11-24 17:39:55 <D34TH> damn, i was hoping i could quickly diagnose which file on my server broke abe and transfer it over
128 2012-11-24 17:40:03 <D34TH> thanks maaku BlueMatt
129 2012-11-24 17:40:09 <Matt_von_Mises> BlueMatt: I do not know when the proposal will become beneficial and how much it will influence download speeds without the right data. It's something that people would almost certainly need to start thinking about if the max block size increases.
130 2012-11-24 17:41:05 <BlueMattBot> Project Bitcoin build #157: STILL FAILING in 1 min 15 sec: http://jenkins.bluematt.me/job/Bitcoin/157/
131 2012-11-24 17:41:49 <D34TH> im getting 500 internal server error
132 2012-11-24 17:41:50 <D34TH> D:
133 2012-11-24 17:42:10 <BlueMatt> D34TH: the server is moving (the dns points to the old one still, sorry)
134 2012-11-24 17:42:15 <D34TH> ahh
135 2012-11-24 17:42:24 <BlueMatt> Matt_von_Mises: ok, so there is the problem I have, I agree if we increase max block size significantly we may want something like that, but for current max block size, I have yet to see much, if any, evidence that that would be necessary on current block sizes
136 2012-11-24 17:43:09 <Matt_von_Mises> BlueMatt: You are probably right. My proposal was never designed to be implemented now. I was jsut thinking ahead about what could be done about the scalability issues.
137 2012-11-24 17:43:18 <sipa> Matt_von_Mises: premature optimization is the root of all evil :)
138 2012-11-24 17:43:31 <BlueMatt> Matt_von_Mises: considering the max block size may never be changed, it seems premature :)
139 2012-11-24 17:43:32 <BlueMatt> Matt_von_Mises: considering the max block size may never be changed, it seems premature :)
140 2012-11-24 17:43:44 <sipa> changing the network protocol is easy, compared with changing the validity rules
141 2012-11-24 17:44:02 <Matt_von_Mises> The max block size is one of the most controversial issues I think.
142 2012-11-24 17:44:09 <sipa> it certainly is
143 2012-11-24 17:44:10 <sipa> it certainly is
144 2012-11-24 17:44:17 <BlueMatt> yep
145 2012-11-24 17:44:19 <sipa> but it also one of the hardest things to change
146 2012-11-24 17:44:28 <sipa> (of those that seem viable to change at all)
147 2012-11-24 17:44:32 <BlueMatt> sipa: its controversial for that reason ;)
148 2012-11-24 17:45:09 <BlueMatt> jenkins is faaaast
149 2012-11-24 17:45:43 <sipa> BlueMatt: yes... "huh 5 new mails tonight? oh, all pullreq tests :p"
150 2012-11-24 17:46:15 <BlueMatt> sipa: better than waiting a week :)
151 2012-11-24 17:58:40 <BlueMattBot> Yippie, build fixed!
152 2012-11-24 17:58:41 <BlueMattBot> Project Bitcoin build #158: FIXED in 11 min: http://jenkins.bluematt.me/job/Bitcoin/158/
153 2012-11-24 17:58:56 <BlueMatt> woo
154 2012-11-24 17:59:16 <D34TH> dns fixed
155 2012-11-24 17:59:17 <D34TH> :3
156 2012-11-24 17:59:25 <BlueMatt> 11 minutes for a build :)
157 2012-11-24 17:59:46 <D34TH> :O
158 2012-11-24 17:59:47 <D34TH> :O
159 2012-11-24 18:00:40 <D34TH> quick dl speeds also
160 2012-11-24 18:00:45 <D34TH> 1.9 MB/s
161 2012-11-24 18:05:02 <jgarzik> block size is an economic resource
162 2012-11-24 18:05:05 <jgarzik> intentionally limited
163 2012-11-24 18:05:12 <jgarzik> otherwise miner incentives are all screwed up
164 2012-11-24 18:05:41 <TD> i think that's a debate we need to have in the core developer group and eventually reach consensus, btw
165 2012-11-24 18:05:45 <TD> i'm in favor of a floating limit
166 2012-11-24 18:05:46 <TD> i'm in favor of a floating limit
167 2012-11-24 18:06:22 <ThomasV> floating how? to optimize miners profit?
168 2012-11-24 18:06:25 <TD> no
169 2012-11-24 18:06:26 <TD> no
170 2012-11-24 18:06:48 <TD> aim for having blocks be slightly larger than the average demand. a bit like difficulty.
171 2012-11-24 18:07:13 <TD> if blocks are constantly full then raise the limit in steps until blocks stop being full
172 2012-11-24 18:07:14 <TD> if blocks are constantly full then raise the limit in steps until blocks stop being full
173 2012-11-24 18:07:27 <TD> ie, attempt to meet all demand, with throttling in place so you can't troll the network with an unusually huge block
174 2012-11-24 18:10:28 <sipa> that may encourage miners to garbage-fill blocks that would otherwise be unfull
175 2012-11-24 18:10:51 <TD> why?
176 2012-11-24 18:11:12 <sipa> to be able to cash more fees at times when there are more transactions
177 2012-11-24 18:11:26 <sipa> (not saying I'm against it, just raisaing a maybe-far-fetched concern)
178 2012-11-24 18:11:27 <sipa> (not saying I'm against it, just raisaing a maybe-far-fetched concern)
179 2012-11-24 18:11:38 <TD> and how would they know if there are going to be more transactions? if the system is working correctly, they should always be able to include the transactions they want to
180 2012-11-24 18:11:49 <TD> only if there's a sudden, very unusual surge in transaction volume might that be an issue
181 2012-11-24 18:12:01 <TD> and by definition, if there's a sudden surge, miners probably didn't anticipate it
182 2012-11-24 18:12:02 <TD> and by definition, if there's a sudden surge, miners probably didn't anticipate it
183 2012-11-24 18:12:31 <TD> if they DID anticipate it, then "stuffing the blocks" is basically just a hack to get a collective vote on a size adjustment, and if that was felt to be a useful thing, it could be added as a feature
184 2012-11-24 18:12:32 <TD> if they DID anticipate it, then "stuffing the blocks" is basically just a hack to get a collective vote on a size adjustment, and if that was felt to be a useful thing, it could be added as a feature
185 2012-11-24 18:12:38 <sipa> ok, let's say there is a consistently higher valid-transaction-creation-rate on weekdays vs weekends
186 2012-11-24 18:12:39 <sipa> ok, let's say there is a consistently higher valid-transaction-creation-rate on weekdays vs weekends
187 2012-11-24 18:13:10 <sipa> in that case, miners may be encouraged to fill their own weekend blocks to the notch, to be able to raise the blocksize more quickly to deal with it during the week
188 2012-11-24 18:13:11 <sipa> in that case, miners may be encouraged to fill their own weekend blocks to the notch, to be able to raise the blocksize more quickly to deal with it during the week
189 2012-11-24 18:13:48 <sipa> probably too far-fetched, but i essentially don't like miners being able to control the block size
190 2012-11-24 18:13:49 <sipa> probably too far-fetched, but i essentially don't like miners being able to control the block size
191 2012-11-24 18:13:49 <TD> that sounds like the flex period is set wrong, then
192 2012-11-24 18:14:13 <TD> i mean if it's calculated over a period of a month or two, then there should be no incentive to try and even out weekday/weekend differences
193 2012-11-24 18:14:14 <TD> i mean if it's calculated over a period of a month or two, then there should be no incentive to try and even out weekday/weekend differences
194 2012-11-24 18:15:00 <sipa> also, if the increase is limited to something corresponding to a few % per year, i would have even less problems
195 2012-11-24 18:16:00 <sipa> anyway, as a side note: bitcoind's mempool handling of conflicting transactions is broken, and always has been
196 2012-11-24 18:16:09 <TD> how so?
197 2012-11-24 18:16:26 <sipa> if a tx A is in the mempool, and a new block comes in which conflicts with A, A doesn't get removed
198 2012-11-24 18:16:30 <sipa> and lingers forever
199 2012-11-24 18:16:46 <TD> but it won't get included into newly mined blocks, of course
200 2012-11-24 18:16:48 <TD> so it's basically a memory leak
201 2012-11-24 18:16:49 <TD> so it's basically a memory leak
202 2012-11-24 18:16:51 <sipa> indeed
203 2012-11-24 18:17:07 <TD> but then does the mempool even have size limits originally?
204 2012-11-24 18:17:08 <TD> but then does the mempool even have size limits originally?
205 2012-11-24 18:17:21 <sipa> don't think it ever had size limits
206 2012-11-24 18:17:41 <TD> i think the mempool will eventually just become another leveldb
207 2012-11-24 18:18:25 <sipa> (current head has an assert when running with -debug that triggers sometimes when the mempool has orphaned transactions)
208 2012-11-24 18:18:26 <sipa> (current head has an assert when running with -debug that triggers sometimes when the mempool has orphaned transactions)
209 2012-11-24 18:18:34 <sipa> so currently it's somewhat more than just a memory leak
210 2012-11-24 18:18:41 <sipa> but that's of course easier to fix
211 2012-11-24 18:19:22 <sipa> maybe conflicting transactions getting accepted wasn't a problem until recently, but now we see several a day, i think
212 2012-11-24 18:20:54 <TD> hm, really
213 2012-11-24 18:20:57 <TD> where do they come from
214 2012-11-24 18:48:55 <jgarzik> IMO: block size should be increased manually
215 2012-11-24 18:49:04 <jgarzik> algorithmically, it is too easy to game
216 2012-11-24 18:49:05 <jgarzik> algorithmically, it is too easy to game
217 2012-11-24 18:50:01 <Luke-Jr> manually = centralized authority
218 2012-11-24 18:51:24 <TD> more to the point, at some point bitcoin will reach the point email did where it can never be upgraded again because there are too many deployed nodes with unresponsive admins
219 2012-11-24 18:51:55 <TD> i think the underlying argument that needs to get resolved first is the economics of it
220 2012-11-24 18:51:56 <TD> i think the underlying argument that needs to get resolved first is the economics of it
221 2012-11-24 18:51:57 <jgarzik> manually = community consensus, because it requires a hard fork
222 2012-11-24 18:52:31 <TD> once everyone agrees that the perfect state is "processing as many transactions as legitimate users want to make", the only question is, how do you get there
223 2012-11-24 18:52:32 <TD> once everyone agrees that the perfect state is "processing as many transactions as legitimate users want to make", the only question is, how do you get there
224 2012-11-24 18:52:51 <TD> jgarzik: miner consensus is nearly as good from this perspective as miners are more likely to be engaged
225 2012-11-24 18:53:38 <jgarzik> TD: it requires a hard fork, so miner consensus is insufficient
226 2012-11-24 18:53:44 <TD> well, yes, today it does
227 2012-11-24 18:53:46 <jgarzik> TD: miner consensus may also conflict with community needs
228 2012-11-24 18:53:51 <jgarzik> e.g. incentives to increase
229 2012-11-24 18:53:57 <TD> but if the hard fork moment is used to replace it with a floating block size, after that, no more are needed
230 2012-11-24 18:54:12 <jgarzik> I agree with sipa that floating block size may be gamed
231 2012-11-24 18:54:29 <TD> gamed in what sense? the perfect state would be unlimited block size, so nobody ever has to artificially wait for confirmation
232 2012-11-24 18:54:50 <TD> the only issue is trying to stop people trolling participants with enormous blocks that act as a DoS attack on participants
233 2012-11-24 18:54:51 <TD> the only issue is trying to stop people trolling participants with enormous blocks that act as a DoS attack on participants
234 2012-11-24 18:55:13 <TD> the question then becomes "what is enormous" and obviously that will vary over time as legitimate use increases (or decreases)
235 2012-11-24 18:55:50 <Luke-Jr> ACTION notes as long as a median is used, someone would need 51% to game the block size limits
236 2012-11-24 18:57:04 <TD> (i'm assuming here, that we gain consensus that mining can be funded in the absence of artificial caps trying to push up tx fees)
237 2012-11-24 19:04:55 <edcba> manually suxx
238 2012-11-24 19:06:10 <jgarzik> TD: no, that's not the perfect state
239 2012-11-24 19:06:21 <jgarzik> TD: unlimited block size eliminates any economic incentive to pay for priority
240 2012-11-24 19:06:26 <edcba> enormous is not enough time to transmit before someone else find 2 blocks :)
241 2012-11-24 19:06:27 <edcba> enormous is not enough time to transmit before someone else find 2 blocks :)
242 2012-11-24 19:06:34 <TD> see my comment about gaining economic consensus
243 2012-11-24 19:06:58 <Luke-Jr> jgarzik: no, it doesn't??? miners still need to cover their electric costs
244 2012-11-24 19:07:14 <TD> i think it's obvious that unlimited IS the perfect long term state. the perfect payment system would let me send any amount of money, any time, instantly, for free, anywhere in the world, with no limits or artificial barriers and no scalability problems
245 2012-11-24 19:07:26 <jgarzik> Luke-Jr: in a larger bitcoin network, vastly different incentives exist
246 2012-11-24 19:07:34 <edcba> the only economic thing to pay attention is tragedy of commons
247 2012-11-24 19:07:35 <edcba> the only economic thing to pay attention is tragedy of commons
248 2012-11-24 19:07:37 <jgarzik> Luke-Jr: it is likely that, for example, Big Banks would mine at a loss, just to participate
249 2012-11-24 19:07:40 <TD> currently there is a lack of consensus on whether bitcoin can be that perfect payment system or whether it is destined to merely end up used for certain types of payments but not all, due to scalability or economic limitations
250 2012-11-24 19:08:03 <edcba> TD: doesn't matter time will tell :p
251 2012-11-24 19:08:04 <edcba> TD: doesn't matter time will tell :p
252 2012-11-24 19:08:17 <TD> block size limit is a decision that can affect the outcome quite significantly
253 2012-11-24 19:08:18 <TD> block size limit is a decision that can affect the outcome quite significantly
254 2012-11-24 19:08:38 <TD> which is why we eventually need to wrestle this issue to the ground and keep it there
255 2012-11-24 19:08:41 <edcba> i think removing limit is maybe a solution
256 2012-11-24 19:08:51 <edcba> now we have to see what would be the effects
257 2012-11-24 19:09:04 <edcba> ie limit is maybe not the right way to handle that kind of abuse
258 2012-11-24 19:09:05 <edcba> ie limit is maybe not the right way to handle that kind of abuse
259 2012-11-24 19:09:18 <Luke-Jr> hmm, my bitcoind seems to flood its peers at startup askign for mempool txns :D
260 2012-11-24 19:09:19 <TD> Luke-Jr: the argument (maybe jeffs argument) is that if there's no block size limit or other throttling in place, transaction fees and thus network speed will spiral towards zero
261 2012-11-24 19:09:20 <TD> Luke-Jr: the argument (maybe jeffs argument) is that if there's no block size limit or other throttling in place, transaction fees and thus network speed will spiral towards zero
262 2012-11-24 19:09:43 <Luke-Jr> TD: I think that will stop as soon as it becomes unprofitable to mine
263 2012-11-24 19:09:55 <TD> Luke-Jr: because miners don't actually care about how much mining they do. they just want to claim the fees. eventually it could all wind back to be cpu mining based
264 2012-11-24 19:10:08 <sipa> that's the entire tragedy of the commons discussion, which i prefer not to repeat here
265 2012-11-24 19:10:11 <TD> yeah
266 2012-11-24 19:10:13 <sipa> imho, we just don't know
267 2012-11-24 19:10:16 <TD> i don't really feel like going round it again
268 2012-11-24 19:10:17 <TD> i don't really feel like going round it again
269 2012-11-24 19:10:27 <TD> just that getting consensus on block size limit will eventually require consensus on it
270 2012-11-24 19:10:28 <TD> just that getting consensus on block size limit will eventually require consensus on it
271 2012-11-24 19:11:15 <sipa> jgarzik: regarding bug in your transport pulls, i got a free(unallocated_data) when destroying a CDataStream as part of a CNetMessage... my guess a CNetMessage that never got initialized
272 2012-11-24 19:11:20 <sipa> jgarzik: valgrind ftw
273 2012-11-24 19:11:21 <sipa> jgarzik: valgrind ftw
274 2012-11-24 19:11:28 <Luke-Jr> ACTION notes there is always the possibility of non-miner nodes deciding "I won't relay blocks over size X, n% of the time"
275 2012-11-24 19:11:39 <Luke-Jr> or simply a "spend X kB/s relaying blocks at most"
276 2012-11-24 19:11:40 <Luke-Jr> or simply a "spend X kB/s relaying blocks at most"
277 2012-11-24 19:12:07 <edcba> yes instead of central authority maybe just let the client choose
278 2012-11-24 19:12:08 <Luke-Jr> thus having a p2p limit
279 2012-11-24 19:12:09 <Luke-Jr> thus having a p2p limit
280 2012-11-24 19:12:14 <edcba> indeed
281 2012-11-24 19:12:24 <sipa> edcba: and have a separate blockchain per client setting? :S
282 2012-11-24 19:12:33 <edcba> Luke-Jr: why n% ?
283 2012-11-24 19:12:43 <edcba> 0% or 100% is not enough for you ?
284 2012-11-24 19:12:48 <Luke-Jr> edcba: to make the limit more soft
285 2012-11-24 19:12:49 <jgarzik> sipa: noted, thanks
286 2012-11-24 19:12:49 <Luke-Jr> edcba: to make the limit more soft
287 2012-11-24 19:13:00 <jgarzik> ACTION leaves to go shit back down
288 2012-11-24 19:13:01 <jgarzik> ACTION leaves to go shit back down
289 2012-11-24 19:13:04 <Luke-Jr> edcba: so perhaps the default could be 0% of 2 MB or 50% of 1.5 MB etc
290 2012-11-24 19:13:05 <Luke-Jr> edcba: so perhaps the default could be 0% of 2 MB or 50% of 1.5 MB etc
291 2012-11-24 19:13:19 <Luke-Jr> so 1.5 MB blocks have a poorer chance of being relayed
292 2012-11-24 19:13:20 <Luke-Jr> so 1.5 MB blocks have a poorer chance of being relayed
293 2012-11-24 19:13:24 <edcba> sipa: relaying not accepting
294 2012-11-24 19:13:24 <sipa> jgarzik: btw, not sure you saw my earlier comment about conflicting transactions lingering in the mempool
295 2012-11-24 19:13:25 <Luke-Jr> and 2 MB blocks very unlikely
296 2012-11-24 19:13:30 <TD> i prefer alternative ways to incentivize mining than trying to throttle the system and make people pay for access
297 2012-11-24 19:14:01 <sipa> pullreq coming up for that... i really like CTxMempool being encapsulated these days
298 2012-11-24 19:14:22 <Luke-Jr> sipa: get a chance to build rc1?
299 2012-11-24 19:14:36 <Luke-Jr> we need more people gitian-enabled :/
300 2012-11-24 19:14:37 <sipa> Luke-Jr: still on mobile data... not going to download a few hundred MB
301 2012-11-24 19:14:47 <Luke-Jr> ah
302 2012-11-24 19:15:22 <Luke-Jr> I think gitian-capable people has come down to sipa, gavin, wumpus, and myself :/
303 2012-11-24 19:15:28 <sipa> and BlueMatt
304 2012-11-24 19:15:32 <Luke-Jr> nope, his is broke
305 2012-11-24 19:15:33 <Luke-Jr> nope, his is broke
306 2012-11-24 19:15:46 <sipa> ACTION thinks we want a gitian on the core dev server
307 2012-11-24 19:15:53 <sipa> or maybe not... trust issues
308 2012-11-24 19:16:02 <Luke-Jr> yeah, gitian only makes sense because different humans do it
309 2012-11-24 19:16:40 <BlueMatt> sipa: na, trust there...
310 2012-11-24 19:20:22 <sipa> yeah, true
311 2012-11-24 19:24:36 <Luke-Jr> DBordello devrandom DrHaribo edcba midnightmagic wizkid057: any of you maybe able to setup gitian?
312 2012-11-24 19:26:11 <gribble> 209410
313 2012-11-24 19:26:11 <sipa> ;;bc,blocks
314 2012-11-24 19:27:15 <wizkid057> Luke-Jr: probably... just need it hosted some place?
315 2012-11-24 19:27:29 <Luke-Jr> wizkid057: ideally local to you
316 2012-11-24 19:27:33 <wizkid057> ah
317 2012-11-24 19:27:38 <wizkid057> wonder if my router machine will run it :P
318 2012-11-24 19:27:41 <Luke-Jr> no
319 2012-11-24 19:27:59 <Luke-Jr> wizkid057: gitian controls a KVM or LXC instance
320 2012-11-24 19:28:12 <wizkid057> oh, gotcha
321 2012-11-24 19:28:14 <wizkid057> hmm
322 2012-11-24 19:28:47 <wizkid057> dont have any spare machines for that, then
323 2012-11-24 19:29:22 <sipa> you just need to run it from time to time (at releases), not continuously
324 2012-11-24 19:29:36 <Luke-Jr> wizkid057: I run it inside a KVM <.<
325 2012-11-24 19:29:43 <sipa> i just run it on my laptop
326 2012-11-24 19:30:57 <wizkid057> hmm
327 2012-11-24 19:31:09 <wizkid057> alright, i'll put that on my TODO list for sometime in the next few days
328 2012-11-24 19:40:08 <sipa> > 1% fees!
329 2012-11-24 19:47:08 <Luke-Jr> gmaxwell: ping
330 2012-11-24 19:47:09 <Luke-Jr> gmaxwell: ping
331 2012-11-24 19:47:40 <Luke-Jr> what makes https://people.xiph.org/~greg/ultraprune_profile2.png ? :/
332 2012-11-24 19:48:26 <sipa> kcachegrind
333 2012-11-24 19:48:27 <sipa> kcachegrind
334 2012-11-24 19:50:34 <sipa> Luke-Jr: i' afraid i lost the nice commandline, but if you grep the logs of this channel, i'm sure you'll find it
335 2012-11-24 19:53:57 <Luke-Jr> [Sunday, July 08, 2012] [5:09:11 PM] <gmaxwell> Sure, I'll reprofile, but I'll also tell you how. Install kcachegrind, run valgrind like valgrind --tool=callgrind --trace-children=yes --collect-jumps=yes --separate-threads=yes ~/bitcoin/src/bitcoind it will write out a bunch of callgrind files when the program stops (or you break it). Start kcachgrind in that directory. It's a gui app, the images were the 'caller tree' or
336 2012-11-24 19:53:59 <Luke-Jr> something like that.
337 2012-11-24 19:54:41 <sipa> ^
338 2012-11-24 20:07:09 <abrkn> how come i am paying 0.0005 tran fee when getinfo shows paytxfee 0.00000000?
339 2012-11-24 20:07:10 <abrkn> how come i am paying 0.0005 tran fee when getinfo shows paytxfee 0.00000000?
340 2012-11-24 20:08:30 <Luke-Jr> because bitcoind forces fees if it thinks they're necessary
341 2012-11-24 20:09:08 <ThomasV> it thinks?
342 2012-11-24 20:09:09 <abrkn> so how do i know how much i am paying?
343 2012-11-24 20:09:23 <sturles> abrkn: Most likely because you paid with "young" coins. The result of a transaction with less than 6 confirmations. Could also be an output smaller than 0.01 BTC.
344 2012-11-24 20:09:24 <Luke-Jr> abrkn: you don't until after the fact.
345 2012-11-24 20:09:38 <sturles> Or (less likely) a transaction > 1 KB.
346 2012-11-24 20:09:57 <abrkn> sturles: output was small, yes. im not concerned about the fee itself, just that i dont know what it is
347 2012-11-24 20:09:58 <abrkn> sturles: output was small, yes. im not concerned about the fee itself, just that i dont know what it is
348 2012-11-24 20:09:58 <Luke-Jr> abrkn: also, the transaction fee needed has little to do with the transaction itself; more to do with your wallet
349 2012-11-24 20:10:00 <abrkn> hard to keep track of the wallet
350 2012-11-24 20:10:01 <abrkn> hard to keep track of the wallet
351 2012-11-24 20:10:26 <Luke-Jr> abrkn: so, for example, it would be wrong to pass the fee on to a user asking for the transaction to be sent
352 2012-11-24 20:16:00 <Luke-Jr> sipa: callgrind is so painfully slow, I think it will take all day :<
353 2012-11-24 20:26:14 <sipa> Luke-Jr: several hours at least, sure
354 2012-11-24 20:26:24 <Luke-Jr> sigh
355 2012-11-24 20:26:25 <Luke-Jr> sigh
356 2012-11-24 20:26:47 <sipa> abrkn: the paytxfee setting is how much voluntary fee you pay per kilobyte
357 2012-11-24 20:26:48 <sipa> abrkn: the paytxfee setting is how much voluntary fee you pay per kilobyte
358 2012-11-24 21:16:28 <Godzilla123> hi i need help with a transaction on satoshidice
359 2012-11-24 21:16:44 <Godzilla123> http://satoshidice.com/full.php?tx=6d97af51e7e20733748414c36e55b85774ef5ae14b98f3d28c5a7f0a92c2ae03
360 2012-11-24 21:17:10 <Godzilla123> the payment tx says "Sorry we could not find any blocks or transactions matching this hash"
361 2012-11-24 21:17:11 <Godzilla123> the payment tx says "Sorry we could not find any blocks or transactions matching this hash"
362 2012-11-24 21:34:49 <BlueMatt> sorry for the delay, but pull-tester is back up at its new home...see its first comment at https://github.com/bitcoin/bitcoin/pull/2033#issuecomment-10684635
363 2012-11-24 21:34:59 <BlueMatt> (note that dns may be stale for a week or so)
364 2012-11-24 21:36:28 <BlueMatt> ;;later tell gavinandresen ok, jenkins fully moved, you can kill the old server :)
365 2012-11-24 21:36:28 <gribble> The operation succeeded.
366 2012-11-24 21:36:29 <gribble> The operation succeeded.
367 2012-11-24 21:54:10 <TD> sipa: how is ultraprune doing?
368 2012-11-24 21:54:19 <TD> think it's getting stable enough to release soon?
369 2012-11-24 21:54:20 <TD> think it's getting stable enough to release soon?
370 2012-11-24 21:55:30 <Luke-Jr> doubt it, it's not even cleared for mining yet
371 2012-11-24 21:56:40 <Luke-Jr> ACTION should set up Eligius to test that <.<
372 2012-11-24 21:56:49 <TD> i think i saw some users are mining with it on p2pool at least. i saw a reference to that somewher
373 2012-11-24 21:57:11 <Luke-Jr> TD: right, but how many of them would notice if they were making invalid blocks?
374 2012-11-24 21:57:38 <TD> yeah, not sure. i guess the next step isn't really to mine, maybe, but to have one of those "compare multiple implementations in parallel" tools
375 2012-11-24 21:57:53 <Luke-Jr> TD: my test plan is to deploy some master-based bitcoind on Eligius in parallel with 0.6.0.x, and have the pool report any blocks created by master that 0.6.0.x doesn't like
376 2012-11-24 21:58:06 <Luke-Jr> TD: yeah, I have that basically all implemented in theory
377 2012-11-24 21:58:07 <Luke-Jr> TD: yeah, I have that basically all implemented in theory
378 2012-11-24 21:58:07 <TD> are you going to release those tools?
379 2012-11-24 21:58:26 <Luke-Jr> TD: https://github.com/bitcoin/bitcoin/pull/1816
380 2012-11-24 21:58:27 <Luke-Jr> TD: https://github.com/bitcoin/bitcoin/pull/1816
381 2012-11-24 21:59:00 <TD> cool
382 2012-11-24 21:59:03 <Luke-Jr> TD: Eloipool already uses this to check the templates it produces; I just need to set it up to check against multiple servers, and before/after manipulation\\
383 2012-11-24 21:59:34 <Luke-Jr> and logging any failures ofc
384 2012-11-24 22:01:54 <TD> ACTION shakes his fist at swiss air
385 2012-11-24 22:01:55 <TD> ACTION shakes his fist at swiss air
386 2012-11-24 22:02:18 <TD> the act of me searching for the flights i need at christmas modified the price of them, asynchronously. bastards.
387 2012-11-24 22:02:19 <TD> the act of me searching for the flights i need at christmas modified the price of them, asynchronously. bastards.
388 2012-11-24 22:17:29 <TD> does bitcoin still require a specific version of boost?
389 2012-11-24 22:17:36 <TD> like, it fails with 1.5 or anything like that?
390 2012-11-24 22:17:37 <TD> like, it fails with 1.5 or anything like that?
391 2012-11-24 22:18:25 <TD> i see matt upgraded us to boost 1.5
392 2012-11-24 22:18:26 <TD> i see matt upgraded us to boost 1.5
393 2012-11-24 22:18:28 <TD> hrm
394 2012-11-24 23:12:46 <Luke-Jr> TD: I think you mean 1.50? 1.5 is very old
395 2012-11-24 23:12:47 <Luke-Jr> TD: I think you mean 1.50? 1.5 is very old
396 2012-11-24 23:13:01 <TD> yeah
397 2012-11-24 23:16:21 <Luke-Jr> sipa: you available?
398 2012-11-24 23:16:22 <Luke-Jr> sipa: you available?
399 2012-11-24 23:48:19 <BlueMatt> TD akaik for the most part, no
400 2012-11-24 23:48:55 <TD> since upgrading to mountain lion i can't compile bitcoin anymore :(
401 2012-11-24 23:48:56 <TD> since upgrading to mountain lion i can't compile bitcoin anymore :(
402 2012-11-24 23:49:11 <TD> i get errors from boost
403 2012-11-24 23:49:31 <BlueMatt> Mac...
404 2012-11-24 23:50:09 <BlueMatt> Maybe ask gavin?
405 2012-11-24 23:50:59 <Diablo-D3> nope
406 2012-11-24 23:51:00 <Diablo-D3> its boost.
407 2012-11-24 23:51:01 <Diablo-D3> its boost.
408 2012-11-24 23:51:10 <Diablo-D3> boost is a collossal pile of shit
409 2012-11-24 23:51:12 <Diablo-D3> and it needs to die forever
410 2012-11-24 23:52:33 <maaku> TD: try switching compilers
411 2012-11-24 23:52:34 <maaku> TD: try switching compilers
412 2012-11-24 23:52:55 <Diablo-D3> maaku: he cant
413 2012-11-24 23:52:56 <Diablo-D3> maaku: he cant
414 2012-11-24 23:52:57 <Diablo-D3> hes on a mac
415 2012-11-24 23:53:01 <Diablo-D3> theres no more osx gcc
416 2012-11-24 23:53:06 <maaku> yes, there is
417 2012-11-24 23:53:13 <Diablo-D3> not an apple build, no
418 2012-11-24 23:53:21 <maaku> i'm on a mac too; you can switch gcc versions
419 2012-11-24 23:53:22 <maaku> i'm on a mac too; you can switch gcc versions
420 2012-11-24 23:53:30 <Diablo-D3> nope.
421 2012-11-24 23:53:32 <Diablo-D3> its now clang only
422 2012-11-24 23:53:47 <maaku> my own powerbook begs to differ
423 2012-11-24 23:53:48 <Diablo-D3> you can build your own version using upstream's osx arch support
424 2012-11-24 23:53:48 <maaku> my own powerbook begs to differ
425 2012-11-24 23:53:59 <Diablo-D3> powerbook? you're on 10.4 or 10.5
426 2012-11-24 23:54:04 <Diablo-D3> this happend in 10.6? 7?
427 2012-11-24 23:54:24 <maaku> s/powerbook/macbook/
428 2012-11-24 23:54:25 <maaku> s/powerbook/macbook/
429 2012-11-24 23:54:27 <maaku> dude just google it
430 2012-11-24 23:54:28 <maaku> dude just google it
431 2012-11-24 23:54:30 <maaku> it's easy to do
432 2012-11-24 23:54:38 <Diablo-D3> I dont have to google it, Im well aware of the problem.
433 2012-11-24 23:54:39 <Diablo-D3> I dont have to google it, Im well aware of the problem.
434 2012-11-24 23:54:46 <Diablo-D3> apple no longer ships builds of gcc.
435 2012-11-24 23:55:19 <Diablo-D3> if bitcoin cannot build out of the box on clang in 10.8, then its a bug
436 2012-11-24 23:55:28 <Diablo-D3> "install gcc" is not an acceptable fix
437 2012-11-24 23:59:55 <TD> well, i'd accept it
438 2012-11-24 23:59:56 <TD> well, i'd accept it