1 2013-04-24 13:30:48 <jgm> Does bitcoind support using nlocktime to broadcast a transaction and then change it afterwards? Any restrictions on it of which I should be aware before I start playing with it?
2 2013-04-24 13:35:54 <Ham> hi guys
3 2013-04-24 13:36:11 <Ham> i cant get websockets working :\\
4 2013-04-24 13:36:19 <Ham> not an uncommon problem i'm sure :)
5 2013-04-24 13:36:58 <Scrat> Ham: Bitcoin does not use websockets
6 2013-04-24 13:37:14 <Ham> oh sorry :)
7 2013-04-24 13:37:26 <Ham> i should be talking on the MtGox channel
8 2013-04-24 13:37:28 <Ham> my bad
9 2013-04-24 13:37:31 <Ham> cyas :)
10 2013-04-24 14:08:24 <BlueMattBot> Project Bitcoin build #287: FAILURE in 25 min: http://jenkins.bluematt.me/job/Bitcoin/287/
11 2013-04-24 14:08:39 <BlueMatt> hey, I thought I shut you down
12 2013-04-24 14:08:51 <BlueMattBot> Project Bitcoin build #288: ABORTED in 15 sec: http://jenkins.bluematt.me/job/Bitcoin/288/
13 2013-04-24 14:09:06 <gmaxwell> "It's allliiive!"
14 2013-04-24 14:09:19 <tumak> attack of the rogue sentient VC bots
15 2013-04-24 14:09:22 <BlueMatt> heh, well pull-tester should be coming back soonish
16 2013-04-24 14:09:45 <gmaxwell> BlueMatt: re: wine, have you tried it with the datadir in tmpfs?
17 2013-04-24 14:10:11 <gmaxwell> or perhaps you should just have a switch to disable the reorg test and disable it on windows? :(
18 2013-04-24 14:11:16 <BlueMatt> gmaxwell: yes, datadir has always been in tmpfs
19 2013-04-24 14:11:27 <BlueMatt> yea, for now reorg test is disabled inthe wine tests
20 2013-04-24 14:12:24 <gmaxwell> concerning, but at least you've run it manually on real windows.
21 2013-04-24 14:12:40 <BlueMatt> yea, Im not too concerned, though Im not a big fan
22 2013-04-24 14:12:48 <sipa> of windows?
23 2013-04-24 14:12:57 <BlueMatt> of it failing, sorry
24 2013-04-24 14:13:02 <BlueMatt> but, yes, of windows too
25 2013-04-24 14:13:03 <sipa> Oh.
26 2013-04-24 14:16:34 <HM2> this PayPal hearsay is fascinating
27 2013-04-24 14:17:18 <jgm> HM2: ?
28 2013-04-24 14:17:24 <BlueMatt> didnt someone say it was stated in the bloomberg video?
29 2013-04-24 14:17:32 <BlueMatt> ACTION hasnt watched it
30 2013-04-24 14:17:43 <klmist> would be nice if they support BTC denominated paypal transactions rather than just use it as a way to top up in USD
31 2013-04-24 14:18:27 <tumak> i'm having my doubts too
32 2013-04-24 14:18:34 <tumak> at best they'll replace bitinstant
33 2013-04-24 14:18:44 <tumak> ie btc->ppusd
34 2013-04-24 14:18:46 <tumak> but not vice versa
35 2013-04-24 14:19:12 <klmist> they're in a great position to do both (with verified accounts anyway)
36 2013-04-24 14:19:30 <tumak> doubt it
37 2013-04-24 14:19:58 <tumak> their fraud prevention is quite antiquated so they simply rely on chargebacks
38 2013-04-24 14:21:14 <HM2> I think they'll likely add it as a funding source for incoming only
39 2013-04-24 14:21:16 <tumak> klmist: but what do we know, maybe they'll come up with something creative
40 2013-04-24 14:21:28 <HM2> they won't allow withdrawals in BTC, that'd be suicide
41 2013-04-24 14:21:28 <tumak> like accepting tx as proof of delivery
42 2013-04-24 14:21:33 <tumak> that would be huge helper for otc
43 2013-04-24 14:22:44 <HM2> they can do all the KYC and account verification with deposits because they'll have someone to come down on. If they allow withdrawals to arbitrary BTC addresses then you can just say your account was hacked
44 2013-04-24 14:23:08 <tumak> it gets worse
45 2013-04-24 14:23:34 <tumak> 1) fraudster sets up verified/whatever it takes account which can withdraw in btc
46 2013-04-24 14:23:52 <klmist> then they close the account and ban you from opening a new one
47 2013-04-24 14:24:01 <tumak> 2) he sends lots of usd from hacked paypals to his account
48 2013-04-24 14:24:03 <tumak> 3) ....
49 2013-04-24 14:24:17 <tumak> klmist: sure
50 2013-04-24 14:24:22 <tumak> but by then, you've got your btc
51 2013-04-24 14:24:32 <klmist> well.. that's not paypal's problem :)
52 2013-04-24 14:24:39 <tumak> it is
53 2013-04-24 14:24:59 <tumak> because hacked accounts will hit you with yet another class action lawsuit
54 2013-04-24 14:25:05 <tumak> implying it was in fact paypal who stole their money
55 2013-04-24 14:25:49 <HM2> well centralised accounts do have some benefits
56 2013-04-24 14:25:53 <klmist> i think it would fail.. if people's accounts get hacked because of a reason that is their fault, not much you can do
57 2013-04-24 14:26:04 <HM2> my credit card company has stopped fraud on my account several times
58 2013-04-24 14:26:08 <tumak> klmist: however it happens a lot
59 2013-04-24 14:26:21 <tumak> klmist: and chargebacks are only thing to prevent that
60 2013-04-24 14:26:32 <klmist> the only reason banks chargeback is because they can screw their merchants
61 2013-04-24 14:26:33 <tumak> simply claim you were hacked and they'll chargeback almost any tx
62 2013-04-24 14:26:58 <tumak> klmist: banks are a bit different though
63 2013-04-24 14:27:11 <tumak> pp dispute process is decent in comparison imo
64 2013-04-24 14:27:52 <tumak> for example, at one point i ordered "unlimited" hotfile.com account
65 2013-04-24 14:28:11 <HM2> for porn? :P
66 2013-04-24 14:28:17 <tumak> well, after downloading 200gb in a week, they blocked me claiming i was reselling their service
67 2013-04-24 14:28:27 <tumak> because apparently 200gb a week is impossible for home user
68 2013-04-24 14:28:42 <tumak> (typical US guy thinking everyone got 16mbps adsl or something :)
69 2013-04-24 14:28:55 <gonffen> nobody in US has 16mbps adsl ;)
70 2013-04-24 14:28:58 <tumak> HM2: um, lets say for backups :)
71 2013-04-24 14:29:51 <HM2> backups are good
72 2013-04-24 14:29:55 <gonffen> 200gb is a lot to download AND consume in a non-commerical way
73 2013-04-24 14:30:04 <HM2> not really gonffen
74 2013-04-24 14:30:07 <gonffen> but they shouldn't have done that :P
75 2013-04-24 14:31:03 <gonffen> maybe not if you're downloading full blu-ray rips, but that seems kind of silly to me
76 2013-04-24 14:31:37 <HM2> it won't be long before streaming HD movies is completely normal
77 2013-04-24 14:31:41 <HM2> it's already almost there
78 2013-04-24 14:32:13 <HM2> but yeah, 200 GB is a lot
79 2013-04-24 14:32:25 <Scrat> 200 GB is 4 full bluray rips :p
80 2013-04-24 14:32:43 <HM2> anyway, I thought you could add arbitrary payment methods to ebay?
81 2013-04-24 14:32:51 <HM2> the problem is nobody likes using anything other than paypal
82 2013-04-24 14:33:09 <gonffen> Scrat: I know right! That's ~8 hours of content!
83 2013-04-24 14:33:27 <HM2> afaik there's nothing stopping Bitpay interfacing with eBay right now
84 2013-04-24 14:33:31 <gonffen> ebay strongly warns against using any other payment method
85 2013-04-24 14:34:53 <HM2> I have no idea how Paypals acquisition by eBay was allowed
86 2013-04-24 14:35:35 <helo> because freedom?
87 2013-04-24 14:35:46 <HM2> oh please
88 2013-04-24 14:35:47 <helo> 'murca etc
89 2013-04-24 14:36:13 <gonffen> it's a pretty logical acquisition
90 2013-04-24 14:36:38 <HM2> if they said they were only going to accept American Express or VISA or Mastercard and not the other 2 then there'd be uproar
91 2013-04-24 14:36:44 <gonffen> if they hadn't, they would've surely ended up making their own payment processor anyways
92 2013-04-24 14:37:39 <gonffen> for example, when you purchase something on amazon.com through a third party, it is handled by 'amazon payments'
93 2013-04-24 14:38:39 <BlueMatt> ok, pull-tester is doing good, sorry for the disruption
94 2013-04-24 14:38:39 <HM2> yeah
95 2013-04-24 14:40:49 <gonffen> oh apparently amazon allows options as well http://finance.yahoo.com/news/bitpay-integrates-bitcoin-fulfillment-amazon-133000525.html
96 2013-04-24 14:43:07 <Diapolo> BlueMatt: Can you restart the build for #2552 :)?
97 2013-04-24 14:43:27 <BlueMatt> Diapolo: I think I did, but whats the commit sha of the tip?
98 2013-04-24 14:45:02 <HM2> I do wonder whether by the time Bitcoin scripted contracts come to light, that things like escrow and mediation will have moved off chain to guys like Paypal
99 2013-04-24 14:45:16 <HM2> could ultimately end up being features not used by the mainstream
100 2013-04-24 14:45:57 <Diapolo> https://github.com/Diapolo/bitcoin/commit/61032f894247f7a4158ec5b41067bcd7c3f35910
101 2013-04-24 14:46:42 <BlueMatt> nope, already gone, itl retry soonish
102 2013-04-24 14:46:56 <Diapolo> okay :)
103 2013-04-24 14:46:58 <Diapolo> thanks
104 2013-04-24 14:48:33 <Killdozer> What is the preferred way to deal with transaction fees when sending bitcoins from the JSON Rpc API? There don't seem to be a function to check what each transaction is required in fees or how many kilobytes it will take, so that fee can be calculated.
105 2013-04-24 14:48:35 <Diapolo> sipa: Could your levelDB patch corrupt the block database?
106 2013-04-24 14:49:25 <gmaxwell> Diapolo: you mean the file descriptors cap?
107 2013-04-24 14:49:42 <Diapolo> gmaxwell: yeah
108 2013-04-24 14:50:09 <gmaxwell> The universe is not sane if it does.
109 2013-04-24 14:50:10 <Diapolo> I integrated it, did a build and startet my mainnet test-wallet, which told me I need to reindex... testnet wallet didn't do this
110 2013-04-24 14:50:21 <jgm> I'm playing with contracts now to see what state it's in. There are certainly some interesting ideas in there, but I do wonder about some of the implementation details. Guess I'll be finding out...
111 2013-04-24 14:51:09 <Diapolo> gmaxwell: only other change I integrated was an update for https://github.com/bitcoin/bitcoin/pull/2553
112 2013-04-24 14:51:48 <Diapolo> gmaxwell: exact error was LevelDB read failure: IO error: C:\\Users\\Diapolo\\AppData\\Roaming\\Bitcoin\\chainstate\\053590.sst: Could not create random access file.
113 2013-04-24 14:52:07 <gmaxwell> Diapolo: we've had intermittent corruption reports from windows users already. Any chance your prior shutdown was unclean?
114 2013-04-24 14:52:14 <gmaxwell> uh... how many files are in chainstate?
115 2013-04-24 14:52:37 <Diapolo> gmaxwell: now, it was a clean shutdown
116 2013-04-24 14:52:42 <Diapolo> no
117 2013-04-24 14:52:46 <Diapolo> let me see
118 2013-04-24 14:52:59 <Diapolo> 119
119 2013-04-24 14:53:30 <gmaxwell> :-/
120 2013-04-24 14:53:32 <Diapolo> and the testnet datadir has only 12 in chainstate
121 2013-04-24 14:54:41 <Diapolo> so we added a limit of 64 and I have 119, is that the problem?
122 2013-04-24 14:54:54 <gmaxwell> No.
123 2013-04-24 14:55:09 <gmaxwell> The limit is just for concurrently open.
124 2013-04-24 14:55:18 <Diapolo> that was what I meant, sorry ^^
125 2013-04-24 14:55:26 <gmaxwell> I'm almost completely sure that change has nothing to do with your issue.
126 2013-04-24 14:55:38 <gmaxwell> This thread is concerning: https://bitcointalk.org/index.php?topic=155140.0
127 2013-04-24 14:56:59 <Diapolo> gmaxwell: strange thing is this imediately happened after I integrated sipas patch, but I'm using current Git master and never saw that error before, at least I never noticed
128 2013-04-24 14:57:57 <BlueMatt> gmaxwell: yes, strange leveldb bugs are a very significant issue...and I dont know how to build a test-harness to debug them :(
129 2013-04-24 14:58:00 <Diapolo> gmaxwell: anything I can do to assis further without just doing the reindex?
130 2013-04-24 15:00:20 <gmaxwell> Diapolo: it's setup in that state now? you get the same error every time?
131 2013-04-24 15:00:41 <Diapolo> gmaxwell: I clicked abort to keep the state, didn't restart yet
132 2013-04-24 15:00:57 <gmaxwell> Diapolo: try restarting again without the reindex.
133 2013-04-24 15:01:01 <Diapolo> Am I right that this patch is the only one we are missing with our LevelDB code? https://code.google.com/p/leveldb/source/detail?r=514c943a8e9ce1b06c55ae5e47008f6b0854b36c
134 2013-04-24 15:01:50 <Diapolo> 2013-04-24 17:00:03 LevelDB read failure: IO error: C:\\Users\\Diapolo\\AppData\\Roaming\\Bitcoin\\chainstate\\053696.sst: Could not create random access file.
135 2013-04-24 15:01:50 <Diapolo> Same error, different file:
136 2013-04-24 15:02:49 <gmaxwell> Diapolo: great, can you shutdown, zip up the chainstate director and put it somewhere I can get it? it should be not terribly huge.
137 2013-04-24 15:03:08 <gmaxwell> you should then be able to delete the directory and it will rebuild it a little faster than a full reindex.
138 2013-04-24 15:04:32 <Diapolo> gmaxwell: shutdown the PC? client is shutdown
139 2013-04-24 15:04:40 <gmaxwell> client, not the pc.
140 2013-04-24 15:04:43 <Diapolo> ^^
141 2013-04-24 15:05:05 <Diapolo> chainstat is 193 MB
142 2013-04-24 15:05:13 <Diapolo> unzipped
143 2013-04-24 15:05:33 <gmaxwell> be glad I didn't ask for the blocks directory?
144 2013-04-24 15:05:37 <BlueMattBot> Project Bitcoin build #289: STILL FAILING in 27 min: http://jenkins.bluematt.me/job/Bitcoin/289/
145 2013-04-24 15:06:07 <Diapolo> chainstate = 193MB
146 2013-04-24 15:06:16 <BlueMatt> BlueMattBot: fuck you
147 2013-04-24 15:06:17 <BlueMattBot> BlueMatt you may not issue bot commands in this chat!
148 2013-04-24 15:06:34 <Diapolo> BlueMatt: LOL ^^
149 2013-04-24 15:07:15 <Diapolo> gmaxwell: I 7zipped it to 123MB still large :-/
150 2013-04-24 15:07:32 <BlueMatt> gavinandresen: did you break that?
151 2013-04-24 15:07:33 <gmaxwell> /mnt/mingw/qt/src/bin/qmake: not found
152 2013-04-24 15:08:39 <BlueMatt> gavinandresen: looks like paths in /mnt/mingw/qt have changed, is that due to the openssl-rebuild, and should the build-script.sh be updated to match?
153 2013-04-24 15:11:20 <Diapolo> seems that upload is killing my connection ^^
154 2013-04-24 15:21:55 <gavinandresen> BlueMatt: uhh???. I ran into weirdnesses with things built in /mnt/mingw not running in the chroot environment (and vice-versa)
155 2013-04-24 15:22:31 <BlueMatt> gavinandresen: strange I know the old stuff was just cp'd
156 2013-04-24 15:23:23 <gavinandresen> BlueMatt: ??? that's not the issue, though
157 2013-04-24 15:23:28 <gavinandresen> I think the path just needs to change
158 2013-04-24 15:23:31 <BlueMatt> gavinandresen: I believe the chroot may have accidentally been made in i386 whereas the host is x86-64, but the mingw stuff is all i586...
159 2013-04-24 15:23:49 <gavinandresen> should be /mnt/mingw/qt/bin/qmake
160 2013-04-24 15:23:58 <BlueMatt> will that work in the chroot too, now?
161 2013-04-24 15:24:51 <gavinandresen> BlueMatt: I'll check real quick...
162 2013-04-24 15:25:25 <BlueMatt> thanks
163 2013-04-24 15:26:09 <gavinandresen> BlueMatt: nope, same problem of binaries compiled outside chroot not working inside chroot
164 2013-04-24 15:26:21 <BlueMatt> :(
165 2013-04-24 15:26:25 <BlueMatt> whats the error?
166 2013-04-24 15:26:30 <gavinandresen> it only worked for jenkins because there was an old qmake in qt/src/bin/ ...
167 2013-04-24 15:26:50 <gavinandresen> BlueMatt: "No such file or directory" when trying to execute
168 2013-04-24 15:27:11 <BlueMatt> hmmm...maybe I lied, I thought the old stuff was cp'd
169 2013-04-24 15:27:37 <gavinandresen> BlueMatt: http://pastebin.com/K4wadvY4
170 2013-04-24 15:28:04 <gavinandresen> BlueMatt: that pastebin is when chroot'ed
171 2013-04-24 15:28:12 <BlueMatt> yep, I must've lied...those are native bins, not win32 bins
172 2013-04-24 15:28:18 <BlueMatt> so the chroot must've had a different build
173 2013-04-24 15:28:20 <BlueMatt> damn
174 2013-04-24 15:28:37 <BlueMatt> if you are really ambitious you could redo the chroot to be x86_64 instead of i386 like it is now
175 2013-04-24 15:28:42 <BlueMatt> sorry about that
176 2013-04-24 15:28:52 <gavinandresen> I don't know nuthin about redoing chroot environments
177 2013-04-24 15:29:04 <BlueMatt> its really been a while since that was set up (and I think I may have scp'd the chroot from the original jenkins server and such.....)
178 2013-04-24 15:29:17 <BlueMatt> ok, then probably just rebuild qt inside the chroot and it should work
179 2013-04-24 15:29:19 <BlueMatt> sorry about that
180 2013-04-24 15:29:22 <gavinandresen> I'll just make clean and make install the qt stuff inside chroot
181 2013-04-24 15:29:27 <BlueMatt> yea, sorry
182 2013-04-24 15:32:46 <gavinandresen> BlueMatt: hmm. Re-running configure I get : /usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h
183 2013-04-24 15:33:07 <BlueMatt> wat?
184 2013-04-24 15:33:19 <gavinandresen> Maybe because: -I/mnt/mingw/qt-everywhere-opensource-src-4.8.3/mkspecs/linux-g++-64
185 2013-04-24 15:33:33 <BlueMatt> probably
186 2013-04-24 15:33:37 <BlueMatt> well, maybe
187 2013-04-24 15:34:08 <Diapolo> gmaxwell: ping
188 2013-04-24 15:34:14 <BlueMatt> shouldn't you be using a mkspec that is like linux-g++-cross or something
189 2013-04-24 15:34:18 <BlueMatt> or win32-g++-cross
190 2013-04-24 15:34:43 <gavinandresen> Yes, no '64' in the configure command???.
191 2013-04-24 15:34:44 <BlueMatt> or isnt it unsupported/win32-g++-cross
192 2013-04-24 15:34:53 <BlueMatt> ahh
193 2013-04-24 15:35:00 <gavinandresen> .. and I started with 'make confclean'
194 2013-04-24 15:35:30 <Diapolo> AFAIK we are using win32-g++-cross for win builds
195 2013-04-24 15:35:34 <BlueMatt> iirc some sed rules are required to fix the mkspec before qt build, but, again, its been a long time since Ive looked at that stuff
196 2013-04-24 15:35:49 <gavinandresen> yes, I applied the sed rules, maybe one of those assumed 64-bit
197 2013-04-24 15:36:08 <BlueMatt> shouldnt, is the gitian vm 32-bit for win32 builds?
198 2013-04-24 15:36:29 <gavinandresen> yup
199 2013-04-24 15:36:37 <BlueMatt> hmm :(
200 2013-04-24 15:37:10 <gavinandresen> Aha: configure -v tells me: Determining system architecture... (Linux:2.6.32-46-server:x86_64)
201 2013-04-24 15:37:32 <BlueMatt> hmm, looks like its looking at the host kernel and assuming the chroot is the same
202 2013-04-24 15:37:41 <BlueMatt> so, yea, may have to rebuild chroot
203 2013-04-24 15:37:41 <gavinandresen> yup. How do I override?
204 2013-04-24 15:37:48 <sipa> linux32 <command>
205 2013-04-24 15:37:51 <BlueMatt> sed/uname/echo .../
206 2013-04-24 15:37:58 <sipa> runs it in an environment that thinks it's 32-bit
207 2013-04-24 15:38:08 <gavinandresen> linux32 configure appears to be working
208 2013-04-24 15:38:20 <BlueMatt> sipa: oh, hey, now thats convinient
209 2013-04-24 15:38:37 <gavinandresen> I'll linux32 make install and keep my fingers crossed
210 2013-04-24 15:39:01 <gavinandresen> BlueMatt: can you change the build_script path ?
211 2013-04-24 15:39:54 <BlueMatt> gavinandresen: git pull and reset
212 2013-04-24 15:40:09 <BlueMatt> ehh, fetch
213 2013-04-24 15:42:31 <gavinandresen> fetch / reset inside the chroot environment, outside, or both ?
214 2013-04-24 15:42:48 <BlueMatt> its cp'd before pull-tester starts
215 2013-04-24 15:42:54 <BlueMatt> so just in /mnt/test-scripts
216 2013-04-24 15:43:13 <gavinandresen> ok. Will do as soon as the linux32 make install finishes....
217 2013-04-24 15:44:56 <gavinandresen> sipa gmaxwell jgarzik and anybody else interested: I'm thinking we need a band-aid fix in the 0.8.2 release for transaction fees: https://gist.github.com/gavinandresen/5453840
218 2013-04-24 15:47:07 <jgarzik> gavinandresen: ACK
219 2013-04-24 15:47:16 <jgarzik> (just read it)
220 2013-04-24 15:51:07 <gmaxwell> at a min-relay-fee of 0.0001 what does that set the minimum output value to? (what is txout.size() there?)
221 2013-04-24 15:52:06 <gavinandresen> P2SH would be??? uhh??? 23? bytes?
222 2013-04-24 15:52:13 <sipa> more
223 2013-04-24 15:52:24 <sipa> 8 bytes amount, 1 byte script length, 23 bytes script
224 2013-04-24 15:52:29 <gmaxwell> (or perhaps a better question is what it the txout.size() of an empty script?)
225 2013-04-24 15:52:35 <gmaxwell> 1 I guess?
226 2013-04-24 15:52:36 <sipa> 9
227 2013-04-24 15:52:38 <gmaxwell> oh 9
228 2013-04-24 15:52:39 <gmaxwell> yea.
229 2013-04-24 15:53:59 <gavinandresen> ??? so 31 bytes P2SH, 32 bytes pay-to-address, up to a bunch for a n-of-3 raw multisig
230 2013-04-24 15:55:04 <sipa> so < 3.2 uBTC == dust?
231 2013-04-24 15:55:23 <gmaxwell> Perhaps we ought to make value=0 script==OP_RETURN standard at the same time... so people doing stupid data bloating things will at least put them in the form we want?
232 2013-04-24 15:55:46 <gavinandresen> i want it as simple as possible so we can get it in asap
233 2013-04-24 15:56:34 <gavinandresen> sipa: is that what it works out to?
234 2013-04-24 15:56:43 <gmaxwell> the IsStandard stuff doesn't worry me about getting it in, generally.. the wallet code does a little more.
235 2013-04-24 15:56:45 <sipa> for pay-to-pubkeyhash, yes
236 2013-04-24 15:57:09 <gavinandresen> adding a *10 to say "if it would cost more than 10% in fees to spend this, it is dust???" would be OK with me
237 2013-04-24 15:57:53 <gavinandresen> (I don't really care where the threshold is)
238 2013-04-24 15:58:09 <gmaxwell> .000003200 is small enough that this should be mostly harmless, though also not terribly effective.
239 2013-04-24 15:58:35 <gmaxwell> lemme see how many outputs that small were created in the last few blocks
240 2013-04-24 15:58:50 <mhanne> hi! i have a question about how it is decided which fork of the chain is 'longer'. is it right that it doesn't just count the number of blocks, but sums the difficulty targets these blocks would have filled (but didn't need to, at current difficulty)?
241 2013-04-24 15:59:18 <sipa> mhanne: it sums the estimated amount of work (=expected number of hashes) done for all blocks in the chain
242 2013-04-24 16:00:05 <mhanne> sipa: ok.. is this what's tracked in CBlockIndex.bnChainWork ?
243 2013-04-24 16:03:06 <gavinandresen> BlueMatt: rebuilt qt in the chroot environment, and git fetched/reset /mnt/test-scripts/
244 2013-04-24 16:03:40 <sipa> mhanne: indeed
245 2013-04-24 16:04:30 <BlueMatt> gavinandresen: ok, Ill run a test build on jenkins+pull-tester and make sure its all ok
246 2013-04-24 16:06:44 <mhanne> oh, maybe that's what i missed... is nBits in a block header the number of bits it actually has, or the number required to meet current difficulty?
247 2013-04-24 16:07:18 <sipa> it's a custom floating-point encoded target
248 2013-04-24 16:07:39 <sipa> bnChainwork is the cumulative of 2^256/target for each block
249 2013-04-24 16:08:16 <sipa> and the number of bits you have never matters, it's always how much you need
250 2013-04-24 16:09:04 <mhanne> what i mean is.. i thought the nBits was what is required at current difficulty (meaning it is the same for all blocks a certain height) - and if it only sums up those it wouldn't make much difference compared to just counting the height
251 2013-04-24 16:09:34 <sipa> you are right
252 2013-04-24 16:09:40 <sipa> and it almost never matters indeed
253 2013-04-24 16:09:54 <sipa> except when a reorganisation is across a retargetting boundary
254 2013-04-24 16:10:09 <mhanne> ooh, i see :D
255 2013-04-24 16:10:41 <Guest42720> gavinandresen: you need to add code to make the wallet not create dust change like my previous patch did
256 2013-04-24 16:10:41 <mhanne> that's a nice corner case i would have never thought about :)
257 2013-04-24 16:11:01 <sipa> Guest42720: who are you?
258 2013-04-24 16:11:14 <Guest42720> sipa: petertodd
259 2013-04-24 16:11:33 <sipa> yes, indeed
260 2013-04-24 16:12:13 <mhanne> sipa: thanks for clearing it up!
261 2013-04-24 16:14:02 <petertodd__> gavinandresen: oh, never mind, you did mention it
262 2013-04-24 16:23:02 <BlueMatt> memory-limited-mempool-used-to-determine-min-fee/prio: how to initialize min fee/prio? call p2p mempool command to fill mempool quickly (probably not possible until/unless we have tx replacement), start with low mempool size limit and slowly increase it until we reach maximum so that we always throw out crap?
263 2013-04-24 16:23:08 <BlueMatt> other ways to do it?
264 2013-04-24 16:23:27 <BlueMatt> ACTION hasnt thought much, but figures smart people here can come up with a solution rather quick ;)
265 2013-04-24 16:26:29 <BlueMattBot> Project Bitcoin build #290: STILL FAILING in 22 min: http://jenkins.bluematt.me/job/Bitcoin/290/
266 2013-04-24 16:33:17 <jspilman> In Payment Protocol - Payment Requests are signed by X.509 cert kept on the payee server, right?
267 2013-04-24 16:34:26 <lianj> jspilman: must not be the case. the cert is put into the request
268 2013-04-24 16:35:15 <jspilman> yes, public part of the cert is in the request - and private key of the cert is used to sign it the request?
269 2013-04-24 16:35:32 <lianj> jspilman: yes
270 2013-04-24 16:36:02 <jspilman> thanks, so the trick will be to keep that signing key safe, since it has to be 'hot' on the server, similar problem as a hot wallet?
271 2013-04-24 16:36:47 <jspilman> but in this case, if attacker gets the key, they can sign payment requests with their own addresses in them?
272 2013-04-24 16:37:09 <lianj> right, but same goes for any https server
273 2013-04-24 16:37:54 <jspilman> I was thinking if there was a way to sign something *offline* once, similar to watch only wallets. Write-up here: https://gist.github.com/jspilman/5454201/raw
274 2013-04-24 16:39:41 <lianj> i can't think of any way, but good question
275 2013-04-24 16:40:07 <jspilman> I think I found a way, but it would require an extension to payment request
276 2013-04-24 16:40:26 <jspilman> check out that gist if you have a min, would love to get feedback before emailing dev mailing list :-)
277 2013-04-24 16:42:52 <jspilman> I think the trouble will be getting a trusted cert authority to generate those certs for you -- I don't know of any off hand that would give you a child cert, or let you generate your own
278 2013-04-24 16:43:59 <jspilman> but the idea is your 'most trusted' cert would be used offline only to sign the Kpar, and a child cert or less-trusted cert would be used to sign the other stuff, like 'amount', 'description', 'merchant-data', and the 'I[0:32]'
279 2013-04-24 16:45:55 <gmaxwell> gavinandresen: so in the last 10 blocks (well last ten when I ran the query a bit ago) there have only been 123 outputs under 0.000004 created out of 12206 outputs.
280 2013-04-24 16:49:17 <gavinandresen> gmaxwell: excellent. Can you run again at 10*0.00???4 ?
281 2013-04-24 16:49:34 <gavinandresen> ??? or is there a magic threshold where suddenly there are lots of outputs?
282 2013-04-24 16:50:18 <gmaxwell> ECDF coming up.
283 2013-04-24 16:54:00 <HM2> ECDF?
284 2013-04-24 16:54:38 <gmaxwell> https://people.xiph.org/~greg/txouts.png < cumulative density, e.g. Y proportion of outputs are X or less. Log scale, the right side of the graph is 0.01.
285 2013-04-24 16:55:39 <gmaxwell> so <0.001 kills about 20% of the outputs. <0.0001 kills about 15%.
286 2013-04-24 16:56:34 <gmaxwell> I'll go collect more than 10 blocks..
287 2013-04-24 16:56:35 <sipa> 80% of outputs are >1 mBTC?
288 2013-04-24 16:56:44 <sipa> that's not too bad
289 2013-04-24 16:56:47 <gmaxwell> at least in my little 10 block window.
290 2013-04-24 16:57:04 <michagogo> How long is a simple, 1 input 2 output transaction in raw form?
291 2013-04-24 16:58:26 <sipa> michagogo: ~150 bytes or so
292 2013-04-24 16:58:30 <sipa> so twice that in hex
293 2013-04-24 17:02:29 <charybdis> hello, is there an updated version of bitointools to work with the new database format? https://github.com/gavinandresen/bitcointools
294 2013-04-24 17:02:39 <charybdis> If this question if off-topic, please let me know
295 2013-04-24 17:03:01 <sipa> not that i know, but what info exactly do you want?
296 2013-04-24 17:03:18 <charybdis> I want to be able to "watch" addresses to see their recent transactions
297 2013-04-24 17:03:26 <charybdis> and to be able to get all historical transactions
298 2013-04-24 17:04:04 <sipa> with -txindex enabled you can use getblock/getrawtransaction to see historic transactions
299 2013-04-24 17:04:07 <gavinandresen> charybdis: no, I've been too busy to keep bitcointools up to date.
300 2013-04-24 17:04:11 <sipa> using RPC
301 2013-04-24 17:04:34 <sipa> watching arbitrary addresses isn't possible (but i hope we'll have watch-only wallets somewhere soon, which will allow that)
302 2013-04-24 17:04:57 <charybdis> gavinandresen: ok, no worries. I'm thankful for all your work!
303 2013-04-24 17:05:10 <charybdis> sipa: yeah, that's what I'd love to have
304 2013-04-24 17:05:28 <BlueMattBot> Project Bitcoin build #291: FIXED in 31 min: http://jenkins.bluematt.me/job/Bitcoin/291/
305 2013-04-24 17:05:28 <BlueMattBot> Yippie, build fixed!
306 2013-04-24 17:05:51 <sipa> \\o/
307 2013-04-24 17:05:59 <BlueMatt> gavinandresen: http://jenkins.bluematt.me/pull-tester/master/test.log
308 2013-04-24 17:07:35 <aceat64> I don't understand why people assume that a single 51% attack (if it were to occur) means the death of bitcoin forever, sure it's not _good_ but it's not like the attacker instantly destroys the blockchain or something
309 2013-04-24 17:07:37 <gavinandresen> BlueMatt: bah, why did that happen? Must have run the wrong configure, it needs -lssl -lcrypto -lgdi32 ....
310 2013-04-24 17:08:06 <gmaxwell> aceat64: Well, not quite, but it would be a concrete disproval of our security assumptions.
311 2013-04-24 17:08:30 <Luke-Jr> aceat64: they *could* destroy eveything since the last checkpoint
312 2013-04-24 17:08:40 <BlueMatt> gavinandresen: it has those 3, not sure what else it needs, you can compare to the jenkins output above, maybe
313 2013-04-24 17:08:51 <michagogo> You'd need a lot more than 51% for that, though
314 2013-04-24 17:09:04 <gmaxwell> Luke-Jr: depending on how long they existed.. it takes an awful long time to cut the chain back if you're only at ~50%.
315 2013-04-24 17:09:20 <gmaxwell> michagogo: no, you can do at at any amount over the majority, given long enough time.
316 2013-04-24 17:09:48 <Luke-Jr> gmaxwell: but if 50% isn't feared, they have the time
317 2013-04-24 17:10:05 <gavinandresen> BlueMatt: -lgdi32 has to come AFTER -lssl ??? but qmake is adding in the -lssl -lcrypto and wants to control the order
318 2013-04-24 17:10:19 <BlueMatt> fun
319 2013-04-24 17:10:23 <gavinandresen> mmm. no.
320 2013-04-24 17:11:38 <aceat64> I think if we ever see a 51% attack, it will be short-lived, it'll likely have to be a combination of attacker mining power plus DDoSing most of the pools to help them get the edge
321 2013-04-24 17:12:08 <Luke-Jr> sipa: FWIW, multiwallet will allow watch-only wallets by coincidence
322 2013-04-24 17:12:37 <Luke-Jr> sipa: ie, mark it "encrypted" and not provide the keys;
323 2013-04-24 17:12:41 <BlueMatt> [RFC]: fees based on mempool contents and memory-limited mempool: https://github.com/TheBlueMatt/bitcoin/commits/fees
324 2013-04-24 17:13:13 <gavinandresen> BlueMatt: I forgot to set OPENSSL_LIBS='-L/mnt/mingw/openssl-1.0.1c/ -lssl -lcrypto -lgdi32'
325 2013-04-24 17:13:23 <BlueMatt> in the build-script?
326 2013-04-24 17:13:26 <aceat64> with the amount of money someone would have to spend to execute a 51%, I just don't see it happening the "legit" way
327 2013-04-24 17:13:27 <gavinandresen> BlueMatt: re-running configure and make install in the chroot environment....
328 2013-04-24 17:13:32 <BlueMatt> ahh
329 2013-04-24 17:13:42 <Luke-Jr> aceat64: it has before
330 2013-04-24 17:14:08 <aceat64> Luke-Jr: on the main chain?
331 2013-04-24 17:14:23 <Luke-Jr> aceat64: yes, Deepbit had 51% very briefly years ago
332 2013-04-24 17:14:28 <helo> it would be nice if all miners were able to switch overy to solo mining in an emergency situation
333 2013-04-24 17:14:49 <aceat64> Luke-Jr: that's not an attack per se
334 2013-04-24 17:14:49 <Luke-Jr> helo: I've started adding benefits for BFGMiner users who setup a local bitcoind ;)
335 2013-04-24 17:15:10 <Luke-Jr> aceat64: yes, I mean someone attained 51% the "legit" way
336 2013-04-24 17:15:30 <aceat64> Luke-Jr: ahh
337 2013-04-24 17:16:13 <kadoban> aceat64: if someone just wanders into your bank vault, but they're nice and don't take anything..still not a ringing endorsement of your security
338 2013-04-24 17:17:11 <aceat64> kadoban: fair enough, though I think GBT should help keep pools from taking full control of the processing power, correct?
339 2013-04-24 17:17:57 <kadoban> GBT?
340 2013-04-24 17:18:22 <aceat64> kadoban: Getblocktemplate
341 2013-04-24 17:18:52 <kadoban> aceat64: ah. i'm not super clear on how that works yet honestly, i wouldn't know
342 2013-04-24 17:19:26 <Luke-Jr> aceat64: should, yes
343 2013-04-24 17:19:57 <petertodd__> kadoban: It's pretty simple. Without getblocktemplate a pool gives you a number and tells you "go hash this". You have no idea what you are working on.
344 2013-04-24 17:20:02 <Luke-Jr> but does need miners to configure multiple pools and ideally a local bitcoind to really take advantage of it
345 2013-04-24 17:20:04 <aceat64> kadoban: I haven't fully read through it, but the basic gist appears to be that the pool says "these parts of the block are mandatory"
346 2013-04-24 17:20:15 <petertodd__> kadoban: With getblocktemplate the pool tells you how that number was derived, IE what you are actually hashing.
347 2013-04-24 17:20:38 <sipa> it doesn't tell younat all what to hash
348 2013-04-24 17:20:51 <sipa> just what you need to know to build the work to hash yourself
349 2013-04-24 17:21:17 <petertodd__> sipa: yeah, that's a better way to say it
350 2013-04-24 17:21:31 <petertodd__> point is, with getblocktemplate you can know what is in the block you are working on
351 2013-04-24 17:21:34 <petertodd__> emphasis on *can*
352 2013-04-24 17:23:06 <Luke-Jr> petertodd__: actually, it's intentional that with GBT, you *must* know what is in the block :p
353 2013-04-24 17:23:10 <Luke-Jr> there's no way to avoid that
354 2013-04-24 17:23:15 <charybdis> is there an architectural overview of how the leveldb stuff works or is the code the best place to learn?
355 2013-04-24 17:23:44 <kinlo> gbt does allow to just send the hashes of the transactions instead of the full transactions, right?
356 2013-04-24 17:23:52 <petertodd__> Luke-Jr: getblocktemplate does not mandate the pool giving you every transaction, or did I misread the standard?
357 2013-04-24 17:23:53 <kinlo> or did I misread
358 2013-04-24 17:24:19 <Luke-Jr> petertodd__: it does, and makes an exception for cases where the client claims it has its own
359 2013-04-24 17:24:30 <Luke-Jr> petertodd__: GBT does not support sending blind data (merkle links etc)
360 2013-04-24 17:25:14 <Luke-Jr> kinlo: it allows miners to send just hashes
361 2013-04-24 17:25:14 <petertodd__> Luke-Jr: right, so GBT doesn't work with large blocksizes then...
362 2013-04-24 17:25:31 <Luke-Jr> petertodd__: well, it has 1 MB templates ;)
363 2013-04-24 17:25:43 <petertodd> Luke-Jr: heh
364 2013-04-24 17:25:45 <Luke-Jr> which are usually gzip'd
365 2013-04-24 17:26:01 <Luke-Jr> but yeah, it could be improved..
366 2013-04-24 17:26:18 <sipa> charybdis: the code is probably the best documentation there is; i can give you some pointers
367 2013-04-24 17:26:28 <petertodd> Luke-Jr: See, I was thinking getblocktemplate would be *really* appropriate for a "mining opportunities" service that served up blocks that paid the whole coinbase back to you. Not a pool, just really convenient solo mining.
368 2013-04-24 17:26:35 <Luke-Jr> I was thinking adding a persistent session identifier, and only sending hashes for previously-send transactions
369 2013-04-24 17:26:49 <charybdis> sipa: ok, I'm digging into it now
370 2013-04-24 17:27:22 <kinlo> the problem I have with GBT is that you need to send the entire block every time - if it's 600KB, and you want to refresh work every minute, that's at least 10kb/sec
371 2013-04-24 17:27:46 <kinlo> not even counting the fact that we're sending raw data in encoded format, which explodes the data in size
372 2013-04-24 17:27:49 <petertodd> Luke-Jr: similar for pools kinda like p2pool where your share of the coinbase is updated directly as you hash, so you can verify on the fly
373 2013-04-24 17:28:35 <Luke-Jr> kinlo: don't forget gzip ;p
374 2013-04-24 17:28:36 <petertodd> kinlo: yup, I mine over tor myself and don't use gbt for that reason
375 2013-04-24 17:28:45 <sipa> charybdis: the most important part is probably the explicit representation of the UTXO set; see class CCoins and CCoinsView in main.h/.cpp
376 2013-04-24 17:28:52 <kinlo> Luke-Jr: gzip will not solve the entire problem
377 2013-04-24 17:28:57 <Luke-Jr> kinlo: but yeah.. got time to spearhead session-oriented GBT? :p
378 2013-04-24 17:29:10 <kinlo> Luke-Jr: we have stratum...
379 2013-04-24 17:29:28 <kinlo> it's not that a malicious pool can include the wrong transactions
380 2013-04-24 17:29:29 <charybdis> sipa: okay, thanks
381 2013-04-24 17:29:55 <bVector> no blocks mined for 30min
382 2013-04-24 17:29:59 <kinlo> besides excluding certain transactions, there is not much a pool can do that you cannot verify with stratum
383 2013-04-24 17:30:16 <bVector> devs kick on your supar sekret instablock solvers
384 2013-04-24 17:30:38 <kinlo> you have the entire coinbase transaction with stratum, and the prev-block etc...
385 2013-04-24 17:30:41 <petertodd> bVector: 30min blocks happen very frequently
386 2013-04-24 17:31:04 <bVector> I know, just need to get a transaction confirmed, so kick open the backdoors :P
387 2013-04-24 17:31:12 <Luke-Jr> kinlo: stratum is just as insecure as getwork
388 2013-04-24 17:31:30 <petertodd> bVector: don't clutter up the channel
389 2013-04-24 17:31:34 <kinlo> Luke-Jr: you can't verify the generation transaction with getwork, so I have to disagree
390 2013-04-24 17:31:39 <Luke-Jr> kinlo: the important part is the transaction data
391 2013-04-24 17:31:49 <Luke-Jr> the generation transaction has no effect on network security
392 2013-04-24 17:31:55 <sipa> stratum is excellent as a communication protocol from a trusted node to miners
393 2013-04-24 17:32:02 <kinlo> not really, if the transaction data is invalid, the block won't get validated
394 2013-04-24 17:32:11 <Luke-Jr> ???
395 2013-04-24 17:32:35 <kinlo> if the pool excludes a certain transaction, another pool will
396 2013-04-24 17:33:02 <kinlo> even if the pool has 75% and continues to build on the global chain, not performing the 51% attack
397 2013-04-24 17:33:06 <sipa> unless all pools are manned by miners who don't really care about the blocks mined itself
398 2013-04-24 17:33:12 <sipa> but sure, there are degrees
399 2013-04-24 17:33:19 <Luke-Jr> kinlo: excluding transactions is a miner's right, not something to worry about
400 2013-04-24 17:33:22 <Luke-Jr> the problem is double-spends
401 2013-04-24 17:34:06 <kinlo> except for 0-confirmation transactions, you can't really do anything wrong if you're properly building on the previous block
402 2013-04-24 17:34:37 <kinlo> and yes, if a pool decides to doublespend a 0-confirmation transaction, it would be visible immediatly after a block is found
403 2013-04-24 17:34:40 <charybdis> I don't know who runs the bitcoin wiki, but it seems to be down...
404 2013-04-24 17:34:47 <TD> good evening
405 2013-04-24 17:34:59 <BlueMatt> hey TD
406 2013-04-24 17:35:24 <petertodd> kinlo: don't think coming to consensus on which transaction was the double-spend is easy...
407 2013-04-24 17:35:27 <gavinandresen> BlueMatt: qt rebuild done
408 2013-04-24 17:35:30 <TD> hey BlueMatt
409 2013-04-24 17:35:55 <kinlo> petertodd: it's not required, you know something fishy happened, and that's the thing you should monitor
410 2013-04-24 17:36:00 <BlueMatt> gavinandresen: thanks, restarting test
411 2013-04-24 17:36:17 <kinlo> imho, the whole doublespent issue is not that bad as long as you wait for confirmations
412 2013-04-24 17:36:49 <The_Fly> wondering if there's any method for receiving push notifications from bitcoind?
413 2013-04-24 17:37:05 <petertodd> kinlo: if you start punishing miners for it you open up bitcoin to malicious actors flooding the network with contradictory transactions, broadcasting double-spends can help bring clarity as to what happened, but it's not in the p2p protocol yet
414 2013-04-24 17:37:11 <TD> The_Fly: there's a pull request to add 0mq support
415 2013-04-24 17:37:12 <The_Fly> other than polling it
416 2013-04-24 17:37:21 <BlueMatt> The_Fly: there is a 0mq branch as well as the -blocknotify parameter
417 2013-04-24 17:37:32 <BlueMatt> or just connect via the p2p protocol
418 2013-04-24 17:37:58 <The_Fly> connect and listen for messages on the address in question?
419 2013-04-24 17:38:16 <The_Fly> ive not yet looked at connecting via the bitcoin p2p protocol
420 2013-04-24 17:38:32 <TD> well it depends what you want to do
421 2013-04-24 17:38:52 <The_Fly> https://github.com/bitcoinjs/bitcoinjs-server/
422 2013-04-24 17:38:53 <sipa> The_Fly: there is -blocknotify (and in 0.8.2, -walletnotify) which execute a command when a new block is retrieved and when wallet transactions are updated
423 2013-04-24 17:38:54 <The_Fly> that looks ok
424 2013-04-24 17:39:00 <kinlo> petertodd: what do you mean with "punish" ? :)
425 2013-04-24 17:39:01 <The_Fly> sipa: thanks
426 2013-04-24 17:39:28 <The_Fly> TD: i'd just like to know when a transaction is made to addresses contained in my wallet
427 2013-04-24 17:39:39 <The_Fly> and i suppose when they receive each confirmation
428 2013-04-24 17:39:54 <The_Fly> anything really to avoid needing to poll bitcoind, which feels like a nasty hack
429 2013-04-24 17:39:58 <petertodd> kinlo: there have been proposals to do things like make miners not mine on top of blocks that appear to have a double-spend in them. (block discouragement)
430 2013-04-24 17:40:31 <The_Fly> i think BlueMatt's suggestion of p2p sounds ok, but then id be also calling out to bitcoind for balances etc
431 2013-04-24 17:40:33 <helo> is it a particular implementation that creates the negative R-value signatures?
432 2013-04-24 17:40:49 <sipa> helo: unknown
433 2013-04-24 17:40:52 <BlueMatt> helo: at this point I dont think anyone knows
434 2013-04-24 17:40:53 <TD> The_Fly: well, it's a bit complicated when you take into account confidence, etc. do you care if the tx never confirms, for instance
435 2013-04-24 17:40:56 <Luke-Jr> The_Fly: -blocknotify '/path/to/script which scans active transactions'
436 2013-04-24 17:41:02 <gmaxwell> petertodd: well discouragement doesn't make sense unless you can be pretty confident most other miners will do it.
437 2013-04-24 17:41:03 <kinlo> petertodd: that would open up an attack where I broadcast 2 transactions using the same input at 2 locations at the same time. The network will be splitted and miners would not know where to mine?
438 2013-04-24 17:41:08 <sipa> helo: there have been implementations that did, but that's a long time ago
439 2013-04-24 17:41:11 <BlueMatt> The_Fly: you may want to just use a library that does it all for you, again, what are you trying to do?
440 2013-04-24 17:41:11 <The_Fly> TD: the goal is to build an in-house transaction processor
441 2013-04-24 17:41:18 <BlueMatt> yea, use a library
442 2013-04-24 17:41:31 <The_Fly> ok, had a scan for some but didn't pull up much
443 2013-04-24 17:41:45 <petertodd> kinlo: exactly, that's a case where even if you know that every miner applies the same *rules* they won't come to consensus about which block to discourage
444 2013-04-24 17:41:46 <BlueMatt> there are a million, pick a language
445 2013-04-24 17:41:52 <kinlo> petertodd: also, having a hash of every transaction would suffice for that purpose, no?
446 2013-04-24 17:42:11 <The_Fly> the implementation language is not so important, just the API/interface
447 2013-04-24 17:42:15 <petertodd> kinlo: no, you need the double-spending signatures
448 2013-04-24 17:42:21 <The_Fly> C++/JS...
449 2013-04-24 17:42:46 <petertodd> kinlo: which is interesting, because that means in the case of single input transactions, currently you have no choice but to give miners enough information to chose which of the two transactions they'll mine
450 2013-04-24 17:42:53 <The_Fly> there's also auction elements to what i want to do
451 2013-04-24 17:42:55 <BlueMatt> The_Fly: bitcoinjs, picocoin, or bitcoinj if you are into java
452 2013-04-24 17:43:07 <BlueMatt> js, C, java
453 2013-04-24 17:43:32 <kinlo> well, I'll see what you can get to, doesn't seem to be the biggest issue for me
454 2013-04-24 17:43:53 <helo> seems like there would be a lot of people complaining if there was a client that somewhat frequently created invalid transactions like that
455 2013-04-24 17:44:19 <helo> so i'd guess that it is possibly intentional?
456 2013-04-24 17:44:23 <The_Fly> BlueMatt: thanks, saw bitcoinjs but didn't see how it could perform push notifications
457 2013-04-24 17:45:14 <The_Fly> https://github.com/bitcoinjs/bitcoinjs-server/wiki/Events
458 2013-04-24 17:45:19 <The_Fly> hm, looks promising
459 2013-04-24 17:46:36 <aceat64> ya, it looks like the bitcoin.it wiki is having MySQL issues
460 2013-04-24 17:46:54 <aceat64> "(Can't contact the database server: Lost connection to MySQL server at 'reading initial communication packet', system error: 111 (mysql))"
461 2013-04-24 17:47:23 <aceat64> probably not the best idea to have error message displayed for a production site
462 2013-04-24 17:50:44 <kinlo> petertodd: btw, wouldn't it be more wise to create a protocol that let's the server tell the client which transactions it will accept by sending the hashes?
463 2013-04-24 17:51:15 <kinlo> petertodd: in that way, both client and server must agree, and client can just only accept those it has in it's own memorypool
464 2013-04-24 17:52:01 <kinlo> both stratum and gbt can't do that presently tough
465 2013-04-24 17:53:02 <petertodd> kinlo: see I'm unconvinced that pool centralization is that big of a risk provided setting up a new pool is easy. you can muck about with zero-conf, but you can't attempt double-spends against confirmed tx's without losing a lot of money
466 2013-04-24 17:53:53 <kinlo> I'm not sure that setting up a pool is easy to do ;)
467 2013-04-24 17:54:03 <TD> sipa: how much bandwidth does your dns seed use?
468 2013-04-24 17:54:22 <sipa> TD: a lot, when you have many crawler threads
469 2013-04-24 17:54:28 <petertodd> kinlo: you need tech chops, but actual costs aren't so bad (provided you don't fuckup and get your wallet stolen...)
470 2013-04-24 17:54:33 <TD> yes. my vps just hit its bandwidth cap and got shut down :)
471 2013-04-24 17:54:37 <sipa> ow
472 2013-04-24 17:54:46 <Luke-Jr> kinlo: GBT allows pool to omit transactions when the client has its own set
473 2013-04-24 17:54:47 <TD> i suppose once the initial crawl is done there's not much point in having many crawl threads
474 2013-04-24 17:54:52 <kinlo> petertodd: you need a lot of miners to trust you and that's not something that comes very easy
475 2013-04-24 17:54:59 <TD> do you have any formulas that could estimate usage per thread?
476 2013-04-24 17:55:14 <petertodd> kinlo: trust != money != expertise
477 2013-04-24 17:55:34 <petertodd> kinlo: also if you do payouts in coinbase, trust is lessoned
478 2013-04-24 17:55:38 <sipa> TD: 300 bytes/second per thread
479 2013-04-24 17:55:52 <TD> ok
480 2013-04-24 17:55:54 <TD> thanks
481 2013-04-24 17:56:01 <kinlo> petertodd: I don't say it is, but I'm saying it isn't easy
482 2013-04-24 17:56:17 <TD> any idea how fast you have to crawl to be useful?
483 2013-04-24 17:56:32 <petertodd> kinlo: you're talking to a room full of people who could do it...
484 2013-04-24 17:56:48 <kinlo> petertodd: I'm doing it, I speak out of experience :)
485 2013-04-24 17:56:56 <petertodd> kinlo: ha, which pool?
486 2013-04-24 17:57:01 <kinlo> triplemining
487 2013-04-24 17:57:07 <sipa> TD: it tells you how long a cycle takes
488 2013-04-24 17:57:21 <TD> yeah, i mean, any idea what cycle time is acceptable?
489 2013-04-24 17:57:30 <TD> before the results get stale/useless
490 2013-04-24 17:57:43 <sipa> a day?
491 2013-04-24 17:57:51 <petertodd> kinlo: cool, so what motivates you to run it?
492 2013-04-24 17:58:10 <TD> thanks
493 2013-04-24 17:58:30 <kinlo> play with technology, proove myself I can do it, and mainly: helping the bitcoin community by attempting to do good for the network
494 2013-04-24 18:04:19 <ahf> hm, bitcoin-qt question: the GetAdjustedTime() function exists in case a given nodes clock is off, or is there another reason for it to be there?
495 2013-04-24 18:05:12 <ahf> the protocol rules wiki entry just mentions that a block should be rejected if the timestamp is more than two hours in the future.
496 2013-04-24 18:07:47 <gmaxwell> ahf: it just makes the times used a bit more consistent, thats all.
497 2013-04-24 18:09:20 <ahf> yeah, it adds an offset based on the peer's that the given client communicates with, but if one is to do another implementation, wouldn't it be possible to require that the user uses NTP?
498 2013-04-24 18:10:48 <sipa> i think satoshi intended to build an NTP client into the software at some point
499 2013-04-24 18:10:58 <gmaxwell> ahf: That wouldn't be especially wise, NTP is a centeralized time source and is surprisingly devoid of sanity checking.
500 2013-04-24 18:11:12 <gmaxwell> (NTP plus sanity checking would be fine I suppose)
501 2013-04-24 18:11:36 <ahf> sipa: i see.
502 2013-04-24 18:12:03 <sipa> /// when NTP implemented, change to just nTime = GetAdjustedTime()
503 2013-04-24 18:12:05 <sipa> in net.cpp
504 2013-04-24 18:12:13 <ahf> gmaxwell: i am just trying to figure out if i can slack a bit and go for block.timestamp > current time + 2 hours of if i should go for the full monty
505 2013-04-24 18:12:17 <ahf> ah, thanks sipa. i must have missed that
506 2013-04-24 18:12:25 <ahf> it looked a lot like the logic you would find in an NTP client
507 2013-04-24 18:12:27 <ahf> thanks a lot guys!
508 2013-04-24 18:17:20 <Luke-Jr> sipa: FWIW, i0coin (IIRC) has NTP builtin (but it leaks memory)
509 2013-04-24 18:17:38 <gmaxwell> it's also dumb about it... e.g. it doesn't bother to check if NTP thinks its own time is accurate.
510 2013-04-24 18:18:17 <gmaxwell> sipa: gavinandresen: https://people.xiph.org/~greg/txouts2.png < this is on the last 1008 blocks. pretty similar to the older graph, but some more very small ones.
511 2013-04-24 18:18:56 <Scrat> Luke-Jr: can GBT work over HTTP? damn bitcoin.it still down and I can't see the google cache
512 2013-04-24 18:19:03 <jgarzik> gmaxwell: what did you use to generate that?
513 2013-04-24 18:19:15 <Luke-Jr> Scrat: GBT is only used over HTTP today
514 2013-04-24 18:19:17 <jgarzik> gmaxwell: i.e. software, and input data format for that software
515 2013-04-24 18:19:42 <jgarzik> sipa: yeah, he did
516 2013-04-24 18:19:45 <sipa> "x86 assembly, bits"
517 2013-04-24 18:19:48 <petertodd> ACTION wonders if anyoen has been shoving data into the chain in the past week...
518 2013-04-24 18:20:01 <gavinandresen> gmaxwell: what is the Y axis?
519 2013-04-24 18:20:02 <gmaxwell> jgarzik: for b in {232959..231951} ; do H=`./bitcoind getblockhash $b` ; ./bitcoind getblock $H | grep ' "' | cut -d'"' -f2 | xargs -n1 -iblah ./bitcoind getrawtransaction blah 1 | grep ' "value"' | cut -d':' -f2 | cut -d',' -f1 >> values3 ; done and then startup GNU R and type plot(ecdf(scan('values3')),xlim=c(0.00000001,0.01),log="x")
520 2013-04-24 18:20:04 <devurandom> Hello!
521 2013-04-24 18:20:28 <sipa> devurandom: oh, you turned unlocked!
522 2013-04-24 18:20:36 <devurandom> ?
523 2013-04-24 18:20:52 <sipa> /dev/urandom = unlocked random?
524 2013-04-24 18:21:05 <gmaxwell> gavinandresen: proportion, e.g. the graph says that about 19% are ~1e-5 or smaller.
525 2013-04-24 18:21:07 <Luke-Jr> sipa: different person
526 2013-04-24 18:21:10 <sipa> oh
527 2013-04-24 18:21:17 <sipa> devurandom: mistook you for devrandom, sorry!
528 2013-04-24 18:21:28 <gmaxwell> devrandom must be blocked.
529 2013-04-24 18:21:30 <devurandom> Happens sometimes ;)
530 2013-04-24 18:21:49 <Luke-Jr> curious to have both RNGs involved in bitcoin
531 2013-04-24 18:22:11 <petertodd> especially since one is based on the other...
532 2013-04-24 18:22:31 <devurandom> Luke-Jr: One more question about python-blkmaker: Does it already deal with longpolling and new blocks arriving - invalidating the existing work?
533 2013-04-24 18:23:21 <Luke-Jr> devurandom: it expects the consumer software to manage templates; it will tell you how long until you need a new one, but you need to decide which one to use and such
534 2013-04-24 18:23:56 <Luke-Jr> to keep dependencies down and portability up, it avoids anything thread/network related
535 2013-04-24 18:25:05 <Luke-Jr> (well, that was for the C libblkmaker, which python-blkmaker is a port of)
536 2013-04-24 18:26:02 <devurandom> Luke-Jr: It seems blktemplate.py is somehow broken: File ".../python-blkmaker/blktemplate.py", line 75, in add \\\\ self.diffbits = _a2b_hex(json['bits'])[::-1] \\\\TypeError: 'str' does not support the buffer interface
537 2013-04-24 18:27:20 <gavinandresen> gmaxwell: ??? so 3 uBTC == dust looks pretty safe to me, although I'm tempted to make it more like 10 uBTC == dust
538 2013-04-24 18:27:47 <gmaxwell> yes, I'd be tempted to make it more like 10.
539 2013-04-24 18:27:49 <jgarzik> gavinandresen: 10 uBTC please
540 2013-04-24 18:28:02 <jgarzik> ACTION had already been thinking that, for a few months
541 2013-04-24 18:28:06 <devurandom> Luke-Jr: Do you have an idea what it means? Is "the buffer interface" that ::-1 part?
542 2013-04-24 18:28:16 <petertodd> still less than a tenth of a penny, so hopefully that at least is uncontroversial...
543 2013-04-24 18:28:21 <gmaxwell> I'm also wondering if we shouldn't do the fee ramp thing that litecoin uses?
544 2013-04-24 18:28:36 <jgarzik> gmaxwell: not 0.8.2 material, imo, but worth considering
545 2013-04-24 18:28:36 <sipa> gmaxwell: which is?
546 2013-04-24 18:28:37 <petertodd> like a fee for every dust output?
547 2013-04-24 18:28:55 <gmaxwell> petertodd: If bitcoin gets to $1000 it will be a penny .. and presumably at that point people will be too excited about it being $1000 to complain. :)
548 2013-04-24 18:29:15 <gmaxwell> sipa: it multiplies the base fee by the number of distinct dust outputs it creates.
549 2013-04-24 18:29:35 <gavinandresen> a fee for every dust output doesn't make sense if you're not mining dust outputs because those transactions are non-standard
550 2013-04-24 18:29:38 <Luke-Jr> gavinandresen: I like 6 uBTC ;)
551 2013-04-24 18:29:54 <gmaxwell> gavinandresen: different dust definition there.
552 2013-04-24 18:30:06 <petertodd> well, the code doesn't have to be in IsStandard()...
553 2013-04-24 18:30:23 <Luke-Jr> wait
554 2013-04-24 18:30:28 <Luke-Jr> I was thinking mBTC >_<
555 2013-04-24 18:30:46 <Luke-Jr> 10 uBTC is way smaller than I'd have considered, so whatever O.o
556 2013-04-24 18:31:29 <gmaxwell> Luke-Jr: well look at the chart, 10 ??BTC is enough to cut out a lot of those really small outputs.
557 2013-04-24 18:31:33 <gavinandresen> 10 uBTC means a spam-blockchain-with-data person must spend 1,000 times what they would spend with wasted 1-satoshi outputs. Which is good.
558 2013-04-24 18:31:52 <petertodd> gavinandresen: no, work it out in terms of cost per kb of data
559 2013-04-24 18:31:55 <Luke-Jr> gmaxwell: ??? until they just increase it to a just-as-uneconomic-but-still-working level
560 2013-04-24 18:32:12 <Luke-Jr> I'm sure whoever creates them will have some reaction to their filtering
561 2013-04-24 18:32:21 <gmaxwell> Luke-Jr: well, as gavin says??? it's 1000 times more costly for unredeemable junk.
562 2013-04-24 18:32:36 <gavinandresen> yes, I'm only thinking about the unredeemable junk that people are using to encode data.
563 2013-04-24 18:32:39 <Luke-Jr> in any case, I don't care particularly strongly on this
564 2013-04-24 18:32:52 <Luke-Jr> gavinandresen: perhaps inform ASICMiner you're screwing their spam up :p
565 2013-04-24 18:32:56 <gmaxwell> yea, it's a low enough value that it's unlikely to impact normal usage any time soon.
566 2013-04-24 18:33:05 <gavinandresen> what is ASICMiner doing?
567 2013-04-24 18:33:15 <Luke-Jr> ASICMiner is regularly sending out 1-satoshi-per-share-held transactions
568 2013-04-24 18:33:35 <petertodd> most efficient data crap is to use OP_CHECKMULTISIG, and that gets you 192 bytes per output, so your 10uBTC limit adds just 0.05mBTC per KB of data, meaningless
569 2013-04-24 18:33:42 <gavinandresen> they should stop doing that??? can't stop them, though, they're minign themselves, right?
570 2013-04-24 18:33:47 <Luke-Jr> clutters my wallet quite a bit, but they seem to have ignored my complaint :/
571 2013-04-24 18:33:52 <gmaxwell> of course they aren't??? they pool mine.
572 2013-04-24 18:34:03 <gmaxwell> on the largest pool because fuck-you-decenteralization.
573 2013-04-24 18:34:38 <gavinandresen> petertodd: formula is per-kilobyte: it will be something like 3* (txout.nValue*1000)/txout.size()
574 2013-04-24 18:34:45 <gmaxwell> they were splitting some rate onto ozcoin to, but I presume not now considering ozcoin is kablooie.
575 2013-04-24 18:34:48 <petertodd> if you ban OP_CHECKMULTISIG that's 1.5mBTC/KB, still cheap, and if you go as far as P2SH only, 5mBTC.
576 2013-04-24 18:35:01 <devurandom> Luke-Jr: Do you want a fix for that? -->> from binascii import a2b_hex \\\\ def _a2b_hex(ascii): \\\\ return a2b_hex(ascii.encode("utf-8"))
577 2013-04-24 18:38:07 <jgarzik> gmaxwell: hehe, to be fair, other pools besides BTC Guild keeps going kablooie
578 2013-04-24 18:38:21 <jgarzik> gmaxwell: BTC Guild is reliable for ASIC miners, even if centralized
579 2013-04-24 18:38:32 <Luke-Jr> devurandom: Py3.2 incompatibility; pushed a fix
580 2013-04-24 18:38:39 <devurandom> Luke-Jr: thx!
581 2013-04-24 18:38:43 <jgarzik> gmaxwell: related: someone commented to be recently that "bitcoin is very monopolistic" (i.e. the community loves the guy with 80% marketshare)
582 2013-04-24 18:39:07 <jgarzik> (for the record, I just switched from slush back to eligius)
583 2013-04-24 18:39:38 <petertodd> gavinandresen: ah, right, so basically it works out to be you pay 1mBTC/KB minimum in lost outputs for the data dump case
584 2013-04-24 18:39:49 <BlueMatt> gavinandresen: nope http://jenkins.bluematt.me/pull-tester/master/test.log
585 2013-04-24 18:40:22 <petertodd> gavinandresen: not terribly exciting, the wikileaks thing paid 25mBTC/KB
586 2013-04-24 18:40:23 <gmaxwell> gavinandresen: I have more concerns with the gist. :( What will happen is someone will try to send 1e-8 and it will tell them no. And then they'll go google a bit and set that commandline option to 0 and it will let them, and they'll have a stuck transaction. :(
587 2013-04-24 18:40:26 <Luke-Jr> jgarzik: fwiw, we've had talk about setting up a separate priority server for miners over x hashrate
588 2013-04-24 18:41:05 <petertodd> gmaxwell: it does work better with the ability to change fees after the fact...
589 2013-04-24 18:41:34 <gmaxwell> petertodd: oh sure, I'm not saying its fatal, but in terms of something that can be rapidly and safely deployed thats unfortunate.
590 2013-04-24 18:41:39 <gavinandresen> petertodd: wikileaks would have to pay 25mBTC/KB PLUS a bunch more to make the unspendable outputs large enough to get mined
591 2013-04-24 18:42:23 <petertodd> gavinandresen: no, it'd work out to just an extra 1mBTC/KB, not a big deal
592 2013-04-24 18:42:24 <gavinandresen> gmaxwell: I don't know what to say about users shooting themselves in their feet. See shadowofharbringer's patch for how far people will go???
593 2013-04-24 18:43:04 <gmaxwell> gavinandresen: even his patch doesn't make it possible for people to create feeless dust outputs. But certantly people will do it if it's just a commandline switch.
594 2013-04-24 18:43:27 <gavinandresen> gmaxwell: do you have a suggestion for what to do instead?
595 2013-04-24 18:44:13 <gmaxwell> gavinandresen: we could make the parameter change only the IsStandard rule but not the wallet behavior. I believe this would address that concern.
596 2013-04-24 18:45:01 <saracen> saivann: "I'm not sure if a virgule is appropriate here" - can you clarify what you mean here? I thought "virgule" refered to a punctuation slash, but there doesn't appear to be any in the text?
597 2013-04-24 18:45:19 <sipa> saracen: it's french for comma, maybe he meant that?
598 2013-04-24 18:45:36 <gmaxwell> Also, I think perhaps we should make the 'size' part of your formula a constant: my rational is that the difference between largest-standard and smallest are only a factor of maybe 4 or so? It is easier for people to understand what the current rules are if we can just say "no outputs under 0.00001"
599 2013-04-24 18:45:38 <saivann> saracen : Indeed, comma, sorry!
600 2013-04-24 18:46:23 <gavinandresen> gmaxwell: we can just say that anyway, because the client never creates raw multisig transactions
601 2013-04-24 18:46:39 <saivann> saracen : Just stick to what you think is best. I was just unsure about this one and I wanted to highlight