1 2013-08-15 00:09:29 <gmaxwell> sipa: I seem to have managed to get it stuck, switched it to the public network.
  2 2013-08-15 00:09:56 <gmaxwell> oh. hm. not stuck, just really slow.
  3 2013-08-15 00:47:50 <petertodd> https://www.proofofexistence.com/developers <- they added a developer api... :-/
  4 2013-08-15 00:48:33 <petertodd> so the API gives you a pay address, which you pay some btc too, and then it creates a *second* transaction with their shitty SHA256 spread over two outputs crap
  5 2013-08-15 00:54:26 <petertodd> heh, and the service is also broken right now; their file uploader spits out 67dd4d3c5de2007c594536eff42bd3bf7ee16a7d3f950bb43832d6b1353c1863 for every file
  6 2013-08-15 00:55:43 <gmaxwell> petertodd: gah, I want to go to a bitcoin monestary where I can pretend awful stuff like that doesn't exist.
  7 2013-08-15 00:56:36 <petertodd> gmaxwell: well, you do live in california, I'm sure there's a suitable place local to you
  8 2013-08-15 00:57:03 <gmaxwell> also, coinbase is apparently funding some "hosted mining" company, proposing to sell 5TH/s boxes that they run for you.
  9 2013-08-15 00:57:13 <petertodd> lol
 10 2013-08-15 00:57:26 <Cusipzzz> thought that was coinlab
 11 2013-08-15 00:57:38 <gmaxwell> oh indeed.
 12 2013-08-15 00:57:42 <gmaxwell> sorry!
 13 2013-08-15 00:57:44 <gmaxwell> stupid names.
 14 2013-08-15 00:57:45 <petertodd> oh, I talked to peter yesterday about that venture...
 15 2013-08-15 00:58:06 <gmaxwell> fwiw, it was right in my head.
 16 2013-08-15 00:58:11 <gmaxwell> few things are.
 17 2013-08-15 00:58:18 <petertodd> heh
 18 2013-08-15 00:58:46 <petertodd> I'm far from convinced the industrial-scale mining really makes sense in the long run from the perspective of heat dissippation
 19 2013-08-15 00:59:33 <gmaxwell> yea, thats been an argument I've proposed. Waste heat hotspots are no good.
 20 2013-08-15 00:59:47 <gmaxwell> ... is there really no way to encode a sendmany in a bitcoin uri?
 21 2013-08-15 00:59:51 <petertodd> yup, and scaling laws kill you too
 22 2013-08-15 01:03:45 <gmaxwell> sipa: doesn't seem to overlap validation and recieving well.
 23 2013-08-15 01:09:14 <rethaw> what better way to heat your arcology then a .5 PH/s farm?
 24 2013-08-15 01:16:20 <jgarzik> I want an arcology
 25 2013-08-15 01:16:43 <rethaw> you're well on your way!
 26 2013-08-15 01:19:42 <rethaw> new hashpower metric: number of swimming pools heated
 27 2013-08-15 01:27:16 <gmaxwell> rethaw: mining heated my home quite nicely for several winters (summer was another problem???)
 28 2013-08-15 01:27:42 <gmaxwell> maybe mining will inspire some interesting work with high temp electronics.. miners working at 400 deg C would be fantastic.
 29 2013-08-15 01:27:45 <gmaxwell> :P
 30 2013-08-15 01:30:10 <nsh> heh
 31 2013-08-15 01:30:28 <nsh> i don't think electronics at 400 deg C could ever be particularly fantastic
 32 2013-08-15 01:31:27 <nsh> ACTION wonders about reversible-computing asics
 33 2013-08-15 01:32:00 <nsh> gmaxwell, what would be a main difficulty with making a hashing machine that uses reversible manipulations?
 34 2013-08-15 01:33:09 <nsh> it strikes me that hashing would be especially difficult to do on a reversible substrate
 35 2013-08-15 01:33:22 <nsh> but i'm not sure i can  justify that with like sciencemathswords
 36 2013-08-15 01:33:51 <gmaxwell> nsh: Toffoli is universal. you can happily wire up a sha256 miner out of them. actually getting the power savings is another matter.
 37 2013-08-15 01:34:11 <nsh> hmm
 38 2013-08-15 01:35:49 <petertodd> nsh: actually high-temp capable electronics would revolutionize the industry: cooling something is much easier if your deltaT is bigger
 39 2013-08-15 01:36:06 <nsh> oh, yes that does make sense
 40 2013-08-15 01:36:36 <gmaxwell> plus the waste heat is just more useful, with existing hardware the only real uses for the waste heat is slow enviromental heating for people/plants/animals in cold enviroments.
 41 2013-08-15 01:36:53 <petertodd> nsh: There's been a huge amount of money poured into trying to up the temp limits on electronics; the only reason it hasn't happened is the fundemental physics makes it really hard.
 42 2013-08-15 01:37:23 <nsh> ACTION thinks
 43 2013-08-15 01:37:54 <petertodd> There's some niche stuff mainly used for downhole applications that IIRC can do up to 200degC, but the lifetime is awful and the cost horrendous. Other than that underhood automotive is the main driver.
 44 2013-08-15 01:38:40 <nsh> what is it that starts breaking, physically, inside silicons information systems as the temperature rises?
 45 2013-08-15 01:39:21 <nsh> thermal noise?
 46 2013-08-15 01:39:34 <nsh> dopant motility
 47 2013-08-15 01:39:50 <nsh> bandgap jumping
 48 2013-08-15 01:40:02 <gmaxwell> nsh: well that happens, but at high temps semiconductors stop being semi.
 49 2013-08-15 01:40:08 <nsh> hmm
 50 2013-08-15 01:41:12 <petertodd> Yup. Also even if you manage to keep them being semiconductors, you get issues with thermal stress leading to fatigue failure and similar "engineering" level issues.
 51 2013-08-15 01:42:43 <nsh> ACTION reads http://electronics.stackexchange.com/questions/13873/why-exactly-do-chips-start-malfunctioning-once-they-overheat
 52 2013-08-15 03:15:07 <jgarzik> http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/
 53 2013-08-15 03:17:15 <weex> Google didn't even have to pay that bounty.
 54 2013-08-15 03:18:01 <Graet> ACTION questions sanity of someone putting that many btc on a phone
 55 2013-08-15 03:21:52 <jgarzik> Linked blog post with more tech details, for the lazy: http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html
 56 2013-08-15 03:22:10 <Cusipzzz> no thanks to the detectives in here? :/
 57 2013-08-15 03:22:29 <jgarzik> In a perfect world, Google would reimburse the stolen bitcoins ;p
 58 2013-08-15 03:22:37 <Cusipzzz> to...whom? :)
 59 2013-08-15 03:29:29 <gmaxwell> Cusipzzz: just sign message with the address they were taken from!!!!
 60 2013-08-15 03:29:32 <gmaxwell> :P
 61 2013-08-15 03:30:35 <Cusipzzz> no, i'm spartacus!
 62 2013-08-15 04:56:16 <random_cat> i saw som recent noise about improvements in heat recapture via thermionc/semiconductor tech, but i've lost the thread; the upshot was 18% overall efficiancy in recapture
 63 2013-08-15 04:57:04 <random_cat> (dT @ 200C)
 64 2013-08-15 05:05:51 <sipa> gmaxwell: yeah, you need a larger receive buffer for that
 65 2013-08-15 09:03:11 <rdymac> "bip32 wallet structure for electrum???  it is now necessary to adopt a convention concerning address allocation" https://bitcointalk.org/index.php?topic=274182.0
 66 2013-08-15 09:03:29 <Luke-Jr> sipa: I think the only lack of progress on multiwallet is that CodeShark is waiting for each individual step to get merged before he moves on to the next one :/
 67 2013-08-15 09:06:17 <sipa> Luke-Jr: that, and that he's mostly working on other things :)
 68 2013-08-15 09:42:07 <ThomasV> bitcoin.it is down :(
 69 2013-08-15 09:47:32 <Happzz> is there a way to make bitcoin-qt not take like 10 minutes to load every time?
 70 2013-08-15 09:47:48 <sipa> that's really slow
 71 2013-08-15 09:47:50 <sipa> what hardware?
 72 2013-08-15 09:48:00 <Happzz> moo: os: Microsoft Windows 7 Ultimate - Service Pack 1 (6.1.7601) up: 7mins 3secs cpu: Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz (x64) at 2931MHz gfx: NVIDIA GeForce 8600 GT 256MB res: x bit Hz ram: 2602/4087.5MB (63.65%) [||||||----] hdd: C:\\ 25.23GB/111.69GB D:\\ 225.78GB/465.76GB E:\\ 148.63GB/931.51GB G:\\ 71.54MB/100MB K:\\ 687.28GB/1.82TB net:
 73 2013-08-15 10:01:30 <Luke-Jr> Happzz: why so low specs?
 74 2013-08-15 10:02:10 <Diablo-D3> http://android-developers.blogspot.com.au/2013/08/some-securerandom-thoughts.html
 75 2013-08-15 10:02:18 <Happzz> "so low specs"?
 76 2013-08-15 10:02:20 <Happzz> you serious?
 77 2013-08-15 10:22:53 <Luke-Jr> Happzz: Windows, nvidia, mere 4 GB RAM
 78 2013-08-15 10:23:23 <Happzz> Luke-Jr arrogance won't get you anywhere. that's what i could afford.
 79 2013-08-15 10:23:49 <SomeoneWeird> yeah, don't be mean Luke-Jr
 80 2013-08-15 10:23:52 <SomeoneWeird> >.<
 81 2013-08-15 10:24:24 <sipa> and nonetheless, 10 minutes for statup is ridiculous
 82 2013-08-15 10:24:32 <sipa> do you have a huge wallet?
 83 2013-08-15 10:24:40 <sipa> encrypted hard drive?
 84 2013-08-15 10:24:45 <Luke-Jr> Happzz: cheaper to get better <.<
 85 2013-08-15 10:24:52 <Luke-Jr> sipa: even for Windows with low RAM? O.o
 86 2013-08-15 10:25:19 <sipa> it should just read through the block index, which is a few megabytes on disk, and sha256 it
 87 2013-08-15 10:25:30 <sipa> hmm
 88 2013-08-15 10:25:30 <sipa> oh, and the rollback check of course
 89 2013-08-15 10:25:32 <Luke-Jr> and verify the most recent blocks
 90 2013-08-15 10:26:02 <sipa> Happzz: mind running with -logtimestamps, and then sending me the part of debug.log about startup?
 91 2013-08-15 10:26:08 <sipa> i'd like to know what is taking so long
 92 2013-08-15 10:28:12 <Happzz> of course.
 93 2013-08-15 10:29:43 <Happzz> logtimestamps should be a default btw
 94 2013-08-15 10:29:57 <jgarzik> Satoshi disagrees, for privacy reasons
 95 2013-08-15 10:30:06 <Happzz> sipa regarding huge wallet and encrypted hdd: no and no
 96 2013-08-15 10:30:16 <Happzz> i have like 20 "receive" addresses.
 97 2013-08-15 10:30:20 <jgarzik> but I think that is perhaps irrelevant now, with so many nodes possibly sampling
 98 2013-08-15 10:31:21 <Happzz> sipa i restarted bitcoin with the logtimestamps. i'll hit you up when it finishes loading.
 99 2013-08-15 10:31:30 <Happzz> i assume it'll take shorter than what it took it after the reboot th
100 2013-08-15 10:31:34 <Happzz> though*
101 2013-08-15 10:32:55 <Luke-Jr> then it's other programs slowing it down at reboot..
102 2013-08-15 10:37:59 <Happzz> sipa you need the log up to the point it starts connecting to nodes, right?
103 2013-08-15 10:41:30 <Happzz> sipa i pmed you with the log. it took 6 minutes this time.
104 2013-08-15 10:51:45 <Zoop_> i'm still waiting for the option to choose where to store the blockchain
105 2013-08-15 10:52:13 <Zoop_> i won't load bitcoin-qt until then
106 2013-08-15 10:52:57 <sipa> if storing 10GB of data is that much of a burden to you, you're likely better off running something else
107 2013-08-15 10:53:43 <Diablo-D3> jesus
108 2013-08-15 10:53:48 <Diablo-D3> =/
109 2013-08-15 10:53:48 <Diablo-D3> my irc logs get that much every day
110 2013-08-15 10:54:10 <Zoop_> storing 10gb in the OS drive is a pain
111 2013-08-15 10:54:20 <Zoop_> i used to have junctions
112 2013-08-15 10:54:22 <sipa> then store it elsewhere
113 2013-08-15 10:54:26 <Zoop_> but they don't work anymore
114 2013-08-15 10:54:30 <Diablo-D3> Zoop_: my OS drive is a pair of 2TB drives in raid 1.
115 2013-08-15 10:54:39 <Zoop_> good for you Diablo-D3
116 2013-08-15 10:54:42 <Diablo-D3> I dont think Ill have problems for a couple more years.
117 2013-08-15 10:54:53 <Diablo-D3> and those are considered small nowadays, btw
118 2013-08-15 10:55:04 <sipa> with -datadir (or datadir= in config file) you can change the storage location
119 2013-08-15 10:55:13 <Zoop_> you do realise bitcoin has a great potential in africa?
120 2013-08-15 10:55:14 <sipa> 0.9 will have a dialog to choose the location on first startup
121 2013-08-15 10:55:22 <Zoop_> excellent
122 2013-08-15 10:56:17 <Diablo-D3> Zoop_: africa will need reliable communications before that can happen
123 2013-08-15 10:56:29 <sipa> ...
124 2013-08-15 10:57:13 <Diablo-D3> I didnt say high bandwidth reliable communications
125 2013-08-15 10:57:17 <Diablo-D3> just reliable
126 2013-08-15 10:57:34 <Zoop_> where is this config file sipa?
127 2013-08-15 10:57:46 <Diablo-D3> I mean, it could be something as simple as putting a sat in orbit that repeats the chain twice every day
128 2013-08-15 10:57:50 <sipa> https://en.bitcoin.it/wiki/Data_directory
129 2013-08-15 10:58:12 <Diablo-D3> and using some sort of bitcoin tx over SMS protocol
130 2013-08-15 10:58:22 <Diablo-D3> that sends it to someone running a SMS to bitcoin gateway
131 2013-08-15 10:58:38 <sipa> SMS is 140 7-bit characters or so
132 2013-08-15 10:58:45 <sipa> not enough for even a standard tx
133 2013-08-15 10:58:50 <Diablo-D3> sipa: =/
134 2013-08-15 10:58:59 <Diablo-D3> maybe some sort of app that spams multiple SMS
135 2013-08-15 10:59:06 <Diablo-D3> a multipart message
136 2013-08-15 10:59:24 <Cryo> use it as ping data
137 2013-08-15 10:59:40 <Cryo> for -s txsize :)
138 2013-08-15 10:59:50 <Diablo-D3> sipa: I mean
139 2013-08-15 10:59:51 <Diablo-D3> lets face it
140 2013-08-15 10:59:55 <Diablo-D3> in most of africa
141 2013-08-15 11:00:01 <Diablo-D3> they have "the internet"
142 2013-08-15 11:00:09 <Diablo-D3> and by "the internet" I mean an entire nation shares a dialup line
143 2013-08-15 11:00:27 <Diablo-D3> and the countries that DO have decent internet (ie, egypt) turn it off when theres political unrest
144 2013-08-15 11:00:38 <Diablo-D3> so we need a communications method they cant turn off
145 2013-08-15 11:01:11 <Diablo-D3> I mean, I almost like googles idea
146 2013-08-15 11:01:28 <Diablo-D3> large scale wifi APs dangling from zepplins
147 2013-08-15 11:01:38 <Diablo-D3> and builds a mesh in the clouds (hurrrrrr)
148 2013-08-15 11:02:39 <bmcgee> hey any of you guys using this: https://github.com/freewil/bitcoin-testnet-box
149 2013-08-15 11:03:28 <bmcgee> I'm finding after the first block is mined the difficulty jumps to 121
150 2013-08-15 11:15:39 <marcusw> Diablo-D3: those are pretty easy to turn off with russian missiles, actually
151 2013-08-15 11:15:58 <Diablo-D3> marcusw: funny you say that
152 2013-08-15 11:16:08 <Diablo-D3> did you know UPS and Fedex aircraft use anti-missile defenses?
153 2013-08-15 11:16:19 <marcusw> but russians
154 2013-08-15 11:16:31 <Diablo-D3> american made anti-missile defenses.
155 2013-08-15 11:18:32 <tgs3> ups... anti-missile.. whaat?
156 2013-08-15 11:18:57 <Diablo-D3> tgs3: yup.
157 2013-08-15 11:19:12 <tgs3> oh 'mericans
158 2013-08-15 11:19:23 <tgs3> thought its not that stupid, like it doesn't hurt anyone
159 2013-08-15 11:19:27 <Luke-Jr> tgs3: he still says BFL is a scam too
160 2013-08-15 11:19:38 <Diablo-D3> Luke-Jr: BFL has yet to deliver units en masse.
161 2013-08-15 11:19:45 <Luke-Jr> ^ see
162 2013-08-15 11:20:03 <Diablo-D3> dont forget luke, I know a lot of people who bought into BFL
163 2013-08-15 11:20:04 <tgs3> Luke-Jr: did BFL delivered? over 10?
164 2013-08-15 11:20:16 <Diablo-D3> they have yet to get their units, and they were early purchasers.
165 2013-08-15 11:20:18 <Luke-Jr> tgs3: ??? far more than 100 by now
166 2013-08-15 11:20:26 <Diablo-D3> Luke-Jr: prove it.
167 2013-08-15 11:20:31 <Luke-Jr> probably thousands
168 2013-08-15 11:20:35 <Diablo-D3> "thousands"
169 2013-08-15 11:20:36 <Diablo-D3> lol.
170 2013-08-15 11:21:01 <Diablo-D3> Luke-Jr: how much did they pay you to shill for them, it must have been a lot if you quit being a Christian over it
171 2013-08-15 11:21:39 <tgs3> Luke-Jr: got any prove?
172 2013-08-15 11:21:50 <tgs3> lol "being christian over it"
173 2013-08-15 11:22:12 <Diablo-D3> tgs3: luke claims hes a devout catholic, yet a real devout christian would never lie for profit.
174 2013-08-15 11:22:33 <bmcgee> this escalated quickly...
175 2013-08-15 11:22:33 <Luke-Jr> tgs3: besides everyone and their dog receiving them?
176 2013-08-15 11:23:43 <Diablo-D3> I dunno man, my dog is still waiting for his.
177 2013-08-15 11:24:00 <marcusw> ACTION hasn't heard of anyone getting any...except for a few people that had problems
178 2013-08-15 11:24:05 <tgs3> bmcgee: lol
179 2013-08-15 11:24:23 <Diablo-D3> marcusw: a lot of shill accounts on the forum said they got one
180 2013-08-15 11:24:31 <Diablo-D3> so maybe thats what luke is referring to
181 2013-08-15 11:24:32 <tgs3> who in this channel has BFL delivered the miner?  who ordered one but didn't got it?
182 2013-08-15 11:24:35 <Diablo-D3> sock puppetry is bad, mmkay
183 2013-08-15 11:24:55 <marcusw> https://forums.butterflylabs.com/blogs/
184 2013-08-15 11:24:55 <Ry4an> tgs3: this sounds like a conversation for #bitcoin
185 2013-08-15 11:25:04 <goodbtc> i have an order, but no hopes :P
186 2013-08-15 11:25:07 <Diablo-D3> tgs3: yochdog ordered several early on, and has not gotten them yet
187 2013-08-15 11:25:17 <tgs3> Ry4an: overall yes, but an testimony from a developer would be more trustworty to me
188 2013-08-15 11:25:26 <Luke-Jr> tgs3: I've received most of mine.
189 2013-08-15 11:25:37 <Luke-Jr> I believe jgarzik and gmaxwell have as well.
190 2013-08-15 11:25:42 <Diablo-D3> tgs3: hes also paid for fpga->asic upgrades for units he owns, and has not gotten them yet either
191 2013-08-15 11:25:45 <Ry4an> tgs3: the devs are in #bitcoin too, and that's where they prefer to talk about stuff that has nothing to do w/ development.
192 2013-08-15 11:25:49 <Diablo-D3> so Im not sure why luke says its not a scam
193 2013-08-15 11:26:10 <sipa> i have two BFL Jalapeno's
194 2013-08-15 11:26:45 <Graet> the jalepeno i won in a raffle arrived 350days after it was ordered
195 2013-08-15 11:26:53 <tgs3> Graet: lol
196 2013-08-15 11:27:01 <Graet> :)
197 2013-08-15 11:27:02 <sipa> for me it was only 10 months!
198 2013-08-15 11:27:02 <tgs3> if not a scam then maybe a pyramid
199 2013-08-15 11:27:13 <tgs3> sipa: why you waited so long with legal action
200 2013-08-15 11:27:23 <tgs3> or illegal one, like russians
201 2013-08-15 11:27:27 <sipa> tgs3: why would i take legal action over 300$?
202 2013-08-15 11:27:35 <Luke-Jr> lol
203 2013-08-15 11:27:54 <sipa> i knew they would overpromise when i pre-ordered
204 2013-08-15 11:28:31 <Graet> me too, thats why i never ordered, but figured throw a few 0.25btc at a raffle for a bit of fun :P
205 2013-08-15 11:28:46 <bmcgee> Anyone want to talk about calculating the reward for a block??????
206 2013-08-15 11:29:00 <sipa> ;;genrate 5000
207 2013-08-15 11:29:01 <gribble> The expected generation output, at 5000.0 Mhps, given difficulty of 50810339.0483, is 0.0494886007307 BTC per day and 0.00206202503045 BTC per hour.
208 2013-08-15 11:29:04 <Luke-Jr> bmcgee: what about it?
209 2013-08-15 11:29:32 <bmcgee> Luke-Jr: 2 secs, just double checking something
210 2013-08-15 11:31:14 <bmcgee> calculating the reward in satoshis is done like this: ((50 * 100000000) >> (height / 210000)) / 100000000
211 2013-08-15 11:31:27 <bmcgee> think i got this from sipa
212 2013-08-15 11:31:27 <sipa> no, in bitcoin :)
213 2013-08-15 11:31:39 <sipa> in satoshi it's without the /100000000 at the end :p
214 2013-08-15 11:31:54 <sipa> also, / is an integer division here (to be consistent with the use in height / 210000)
215 2013-08-15 11:31:55 <bmcgee> ah lol that would explain what i'm seeing
216 2013-08-15 11:32:35 <bmcgee> when specifying amounts in transactions it's always satoshis?
217 2013-08-15 11:33:10 <bmcgee> fees etc as well are all satoshis?
218 2013-08-15 11:33:25 <sipa> internally, all amounts are always in satoshi's, yes
219 2013-08-15 11:33:29 <sipa> and integersw
220 2013-08-15 11:33:42 <sipa> so they're just 64-bit integers
221 2013-08-15 11:33:44 <Luke-Jr> bmcgee: Bitcoin's low-level protocol only works in satoshis. RPC uses satoshis divided by 1e8
222 2013-08-15 11:33:59 <bmcgee> ok cool thx i'll give this a whirl and see what blocks it produces
223 2013-08-15 11:34:22 <bmcgee> is there a util for viewing a local blockchain?
224 2013-08-15 11:35:41 <goodbtc> sipa, the protocol is created in such way that after 200 yars all software will be compatible with other zeros added?
225 2013-08-15 11:35:46 <sipa> no
226 2013-08-15 11:35:58 <sipa> if we want to add digits, all software has to be updated
227 2013-08-15 11:36:06 <Luke-Jr> goodbtc: expanding precision requires breaking compatibility
228 2013-08-15 11:36:27 <goodbtc> i hoped is an easy move
229 2013-08-15 11:36:34 <sipa> it's not a philosophical change, so it's likely uncontroversial
230 2013-08-15 11:36:40 <sipa> when it's necessary
231 2013-08-15 11:36:45 <sipa> but it's not trivial
232 2013-08-15 11:37:15 <goodbtc> Y2K for btc in 2300, the end of finance world
233 2013-08-15 11:38:01 <goodbtc> we are able to take preemtive measures now?
234 2013-08-15 11:38:05 <sipa> why?
235 2013-08-15 11:38:16 <goodbtc> just because we love people from 2300 :)
236 2013-08-15 11:38:33 <sipa> i'm sure they'll be much more capable in dealing with their problems than we are
237 2013-08-15 11:38:41 <sipa> we have no clue what the bitcoin economy will look like
238 2013-08-15 11:38:53 <sipa> whether it will still exist at all, or be succeeded by something better
239 2013-08-15 11:39:01 <Luke-Jr> goodbtc: it's nothing like y2k
240 2013-08-15 11:39:17 <sipa> also, why 2300 specifically?
241 2013-08-15 11:39:23 <Luke-Jr> things won't just break one day. there will just not be better precision until someone plans it a few years in advance
242 2013-08-15 11:39:33 <goodbtc> because human mind love round numbers
243 2013-08-15 11:39:34 <sipa> if you're worried about the block payout being too low, that has nothing to do with the precision
244 2013-08-15 11:41:23 <TD> basically it means that some economic opportunities that would have happened, won't, because people won't be able to express prices small enough
245 2013-08-15 11:41:37 <TD> however if that were to ever happen people would find temporary workarounds and then the process of upgrading everyone would begin
246 2013-08-15 11:41:46 <TD> because bitcoin is a global consensus that should be "easy" as flag days are actually enforceable.
247 2013-08-15 11:45:43 <goodbtc> https://en.bitcoin.it/wiki/FAQ#How_divisible_are_bitcoins.3F A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.
248 2013-08-15 11:46:09 <goodbtc> When I read this I supposed we are already prepared
249 2013-08-15 11:46:23 <goodbtc> but not used yet, to not confuse users even further
250 2013-08-15 11:47:15 <sipa> i find that a stupid statement
251 2013-08-15 11:47:24 <sipa> of course the software can be adapted to change that
252 2013-08-15 11:47:30 <sipa> but you can change anything by changing the software
253 2013-08-15 11:47:42 <sipa> if everyone agrees to upgrade, anything is possible
254 2013-08-15 11:50:56 <realazthat> http://www.scipr-lab.org/
255 2013-08-15 11:51:00 <realazthat> SCIP website is up
256 2013-08-15 12:01:06 <renhei> are there plans to integrate zerocoin in bitcoin?
257 2013-08-15 12:03:12 <sipa> no
258 2013-08-15 12:03:37 <sipa> as is, zerocoin isn't very usable because of performance and bandwidth requirements, afaik
259 2013-08-15 12:03:53 <renhei> sipa: ok i see
260 2013-08-15 12:04:55 <renhei> so devs are waiting for a better version?
261 2013-08-15 12:10:31 <c0rw1n> there was a better idea some months ago
262 2013-08-15 12:11:03 <c0rw1n> can't really remember, maybe you'd find it if you seek through the zerocoin thread
263 2013-08-15 12:11:28 <TD> it needs more research. also it's a very very complicated technique when there are much simpler techniques available which already aren't used
264 2013-08-15 12:11:38 <TD> so it'd make more sense to do the simple improvements first and the more complicated ones later
265 2013-08-15 12:11:56 <sipa> it's the only measure that provides true anonymity i've heard of
266 2013-08-15 12:12:07 <sipa> but there are many ways to get better privacy without going that far
267 2013-08-15 12:15:26 <TD> depends what you mean by "true anonymity"
268 2013-08-15 12:15:54 <jgarzik> breaking anonymity is usually about social engineering, side channels, ...
269 2013-08-15 12:16:18 <c0rw1n> yeah well that can't be defended against, right? That's not what the automatic anon tools fdo
270 2013-08-15 12:16:39 <c0rw1n> good privacy tools make it so that it's necessary to attack anonymity sideways
271 2013-08-15 12:16:48 <c0rw1n> because you can't attack the tool
272 2013-08-15 12:17:09 <sipa> well zerocoin provides (IIRC) grouping of transactions in such a way that it cannot be inferred who did which
273 2013-08-15 12:17:52 <c0rw1n> so that's a good tool
274 2013-08-15 12:18:13 <c0rw1n> or not, it's huge and unwieldy
275 2013-08-15 12:18:18 <sipa> i guess chaumian e-banking is also anonymous, but requires a trusted central party (who however does not need to know its clients)
276 2013-08-15 12:18:27 <c0rw1n> yeah then no
277 2013-08-15 12:18:58 <c0rw1n> "needs a central point of failure by design" <- yeah then no
278 2013-08-15 12:19:56 <sipa> you can't have everything
279 2013-08-15 12:20:09 <c0rw1n> you can make that central party distributed and participated in by every client
280 2013-08-15 12:20:09 <sipa> scalability, decentralization, anonimity, ...
281 2013-08-15 12:23:55 <helo> sipa: is that "pick one", or "pick two"?
282 2013-08-15 12:24:30 <helo> it appears to be the former, with bitcoin choosing decentralization
283 2013-08-15 12:24:51 <helo> i guess bitcoin is scaleable in its own way
284 2013-08-15 12:26:27 <c0rw1n> depends how you measure scaleability
285 2013-08-15 12:28:55 <TD> i think you can have everything :)
286 2013-08-15 12:28:57 <TD> it's just not easy
287 2013-08-15 12:29:14 <c0rw1n> you can do "good enough" in all of them, oh yes
288 2013-08-15 12:30:16 <sipa> well you cannot have ultimate scalability (anyone can do as many transactions as they like)
289 2013-08-15 12:30:28 <sipa> and you cannot have ultimate decentralization (everyone can be sure that nobody is cheating)
290 2013-08-15 12:30:47 <sipa> i guess you could have ultimate anonimity if you give up the two other ones completely :)
291 2013-08-15 12:30:48 <c0rw1n> 1. why not? and 2. why not?
292 2013-08-15 12:30:59 <sipa> 1) requires infinite bandwidth
293 2013-08-15 12:31:06 <c0rw1n> wait
294 2013-08-15 12:31:07 <sipa> 2) requires zero-cost processing
295 2013-08-15 12:31:34 <sipa> by ultimate i don't mean "limited to some reasonable amount"
296 2013-08-15 12:31:46 <c0rw1n> you can't have infinity tx per second, but you can certtainly have infinity txes eventually
297 2013-08-15 12:31:57 <c0rw1n> same for decentralization
298 2013-08-15 12:32:09 <sipa> if you don't have infinite transactions per second, you'll never have an infinite number of transactions
299 2013-08-15 12:32:18 <c0rw1n> stop wordplay
300 2013-08-15 12:32:27 <sipa> this is not wordplay, this is math
301 2013-08-15 12:32:38 <sipa> the limit is infinity yes, sure, but that's irrelevant
302 2013-08-15 12:33:27 <c0rw1n> what's relevant is that the state propagates fast enough to be meaningful
303 2013-08-15 12:34:02 <sipa> all i'm saying is that there is no way you can have an infinitely-scalable system; it will at some point break down - and that's fine
304 2013-08-15 12:34:06 <c0rw1n> that's "good enough"
305 2013-08-15 12:34:19 <marcusw> so make it scale globally
306 2013-08-15 12:34:22 <marcusw> and leave it at that
307 2013-08-15 12:34:22 <sipa> and you can't have an infinitely-decentralized system; it will at some point break down - and that's fine
308 2013-08-15 12:34:36 <sipa> the question is which limits we consider reasonable
309 2013-08-15 12:35:04 <sipa> so the question is not "can we have 1 or 2 from that list"
310 2013-08-15 12:35:12 <sipa> it's always about to which extent you want them
311 2013-08-15 12:35:36 <sipa> they're not booleans
312 2013-08-15 12:44:49 <jgarzik> hrm
313 2013-08-15 12:45:21 <jgarzik> does RPC provide any way to (a) input a raw transaction, and (b) output a determination if all inputs are unspent ?
314 2013-08-15 12:45:28 <petertodd> no
315 2013-08-15 12:45:39 <jgarzik> I suppose I could iterate through 'gettxout', but that's annoying
316 2013-08-15 12:45:48 <petertodd> we should have something like "validatetx" that skips actualy adding a tx to the mempool
317 2013-08-15 12:46:07 <michagogo> jgarzik: You could also patch bitcoind and remove the "send" code from sendrawtransaction
318 2013-08-15 12:46:09 <jgarzik> well signrawtransaction does some validation
319 2013-08-15 12:46:16 <jgarzik> just not spent-ness
320 2013-08-15 12:46:18 <petertodd> should come in versions that use the mempool logic, as well as the logic that would determine if a transaction were valid if it were in a block
321 2013-08-15 12:46:32 <jgarzik> petertodd, you can pass a fully signed tx to signrawtransaction, for validation purposes
322 2013-08-15 12:46:57 <jgarzik> I agree that's a bit esoteric, which validatetx would be more clean
323 2013-08-15 12:48:15 <sipa> jgarzik: gettxout can tell you whether an input is available
324 2013-08-15 12:48:20 <petertodd> yeah, the functionality needs to be separated, and it really should go through the same code as is used for tx validation, not by something we've duplicated
325 2013-08-15 12:48:28 <sipa> ah
326 2013-08-15 12:48:56 <michagogo> I think at one point I wanted a way to mine a given transaction into a testnet block without the rest of testnet seeing it
327 2013-08-15 12:49:11 <petertodd> one issue is that signrawtransaction can't tell you if a transaction is invalid as-is - it'll sign it first after all!
328 2013-08-15 12:49:18 <michagogo> I just cut out a bit of the code
329 2013-08-15 12:49:27 <michagogo> petertodd: You can run it on a wallet with no privkeys
330 2013-08-15 12:49:38 <michagogo> Then it won't sign unless you also specify a key in the command
331 2013-08-15 12:49:59 <petertodd> michagogo: right, good point, you can tell give it an empty privkey list
332 2013-08-15 12:50:10 <michagogo> Oh, right
333 2013-08-15 12:50:13 <michagogo> Forgot about that part
334 2013-08-15 12:50:57 <petertodd> Of course, in any other project you'd just refactor some code to create ValidateTransaction()... here that could result in a consensus bug. :(
335 2013-08-15 12:51:11 <michagogo> Consensus bug?
336 2013-08-15 12:52:21 <petertodd> michagogo: read up on consensus on the wiki or something if you don't know what I mean, important topic
337 2013-08-15 12:53:17 <michagogo> "There is currently no text in this page."
338 2013-08-15 12:53:29 <petertodd> sheesh...
339 2013-08-15 12:53:58 <petertodd> it's the most important thing about bitcoin :/
340 2013-08-15 12:54:21 <michagogo> Well, write https://en.bitcoin.it/wiki/Consensus then :-P
341 2013-08-15 12:55:02 <petertodd> michagogo: busy :) anyway, gotta go, you write it! worst that can happen is you'll just force one of us to fix it :)
342 2013-08-15 12:55:19 <michagogo> petertodd: But what's the problem with adding a command that runs the same checks as sendrawtransaction?
343 2013-08-15 12:55:40 <michagogo> But just doesn't actually send?
344 2013-08-15 12:55:58 <petertodd> try doing that yourself, you'll see
345 2013-08-15 12:55:59 <petertodd> later
346 2013-08-15 12:56:02 <michagogo> ...
347 2013-08-15 12:58:18 <graingert> :3
348 2013-08-15 13:47:57 <jgarzik> sipa, any chance for a user-visible no-wallet mode in 0.9?  The coding is easy, but never could settle on how it should behave.  You seemed meh over -nowallet and ifdefs.
349 2013-08-15 13:50:05 <michagogo> no-wallet mode?
350 2013-08-15 13:50:11 <michagogo> So just a verify/relay node?
351 2013-08-15 13:58:31 <gmaxwell> jgarzik: Why bother?
352 2013-08-15 14:02:42 <Cusipzzz> no wallet = no risk of theft. the secure bitcoin platform!
353 2013-08-15 14:04:27 <jouke> Cusipzzz: no bitcoins in wallet = no risk of theft as well?
354 2013-08-15 14:04:52 <gmaxwell> (I'm actually curious, not just being snarky)
355 2013-08-15 14:50:42 <bmcgee> hey is there a simple way of viewing a block locally, say if you're running a private testnet?
356 2013-08-15 14:51:00 <gmaxwell> getblock <blockhash>
357 2013-08-15 14:51:22 <bmcgee> i feel really stupid right now...
358 2013-08-15 14:56:27 <jgarzik> gmaxwell, to start hammering out what a no-wallet-code, public blockchain-only bitcoind would look like
359 2013-08-15 14:56:38 <jgarzik> gmaxwell, figure out which RPCs to keep, which to ditch.
360 2013-08-15 14:57:41 <jgarzik> gmaxwell, looking forward to the day when wallet/GUI/account system are separate from public blockchain/P2P engine
361 2013-08-15 14:57:46 <gmaxwell> Okay, fair enough.
362 2013-08-15 14:59:49 <jgarzik> Call it "router mode"
363 2013-08-15 15:00:05 <jgarzik> or router build, if ifdefs are employed
364 2013-08-15 15:00:48 <jouke> But would it really give a performance boost?
365 2013-08-15 15:01:47 <jgarzik> no
366 2013-08-15 15:03:34 <jgarzik> jouke, One possible, months-away goal is to separate wallet/GUI and blockchain engines into completely separate processes.
367 2013-08-15 15:03:54 <jgarzik> jouke, the wallet could become an SPV client quite easily, once sipa's headers-first work is complete
368 2013-08-15 15:27:59 <jgarzik> It works!
369 2013-08-15 15:28:32 <jgarzik> pwalletMain==NULL works; bitcoind continues to process the blockchain and relays blocks and TXs as normal
370 2013-08-15 15:29:53 <sipa> what happens if you turn on mining? :p
371 2013-08-15 15:30:24 <nsh> BIG BADDABOOM!
372 2013-08-15 15:30:42 <michagogo> or call validateaddress?
373 2013-08-15 15:30:45 <jgarzik> sipa, mining is disabled
374 2013-08-15 15:30:55 <michagogo> Or call any of the wallet-like functions?
375 2013-08-15 15:31:02 <goodbtc> multipass
376 2013-08-15 15:31:02 <jgarzik> michagogo, those are disabled
377 2013-08-15 15:31:29 <michagogo> Will it still signrawtransaction if you give it the keys?
378 2013-08-15 15:31:42 <jgarzik> michagogo, yes
379 2013-08-15 15:32:15 <Cusipzzz> pretty cool
380 2013-08-15 15:32:37 <michagogo> I don't know if I've ever had this many connections
381 2013-08-15 15:32:42 <michagogo> bitcoin-qt
382 2013-08-15 15:32:48 <michagogo> bitcoin-qt's corner icon says I have 34
383 2013-08-15 15:33:03 <michagogo> BTW, is there any value to running a testnet node with tor?
384 2013-08-15 15:33:42 <michagogo> (I mean, it's just a matter of adding one HiddenServicePort line in torrc, but I suspect there may not be any reason to)
385 2013-08-15 15:34:11 <jgarzik> Pull req with working no-wallet code: https://github.com/bitcoin/bitcoin/pull/2901
386 2013-08-15 15:34:27 <Luke-Jr> sipa: no reason mining would care about wallet
387 2013-08-15 15:34:29 <jgarzik> It's surprisingly little code -- though admittedly some RPCs still need going-over with a fine-toothed comb
388 2013-08-15 15:34:49 <jgarzik> Luke-Jr, current implementation wants an address for coinbase
389 2013-08-15 15:34:57 <jgarzik> even for GBT
390 2013-08-15 15:35:01 <Luke-Jr> hmm
391 2013-08-15 15:35:14 <Luke-Jr> jgarzik: then I'll propose we remove getwork and fix that :p
392 2013-08-15 15:35:18 <petertodd> jgarzik: obviously the thing to do is put a anyone-can-spend output by default to show your love for bitcoin :P
393 2013-08-15 15:35:19 <jgarzik> getwork clearly needs it
394 2013-08-15 15:35:27 <jgarzik> Luke-Jr, my pull req disables getwork completely
395 2013-08-15 15:35:34 <jgarzik> Luke-Jr, and GBT would need minor changes
396 2013-08-15 15:35:46 <jgarzik> petertodd, hah
397 2013-08-15 15:36:50 <sipa> Luke-Jr: it fetches an address :)
398 2013-08-15 15:37:28 <jgarzik> our multi-wallet dispatch functions make pwalletMain==NULL easier
399 2013-08-15 15:38:57 <michagogo> Isn't that, by definition, what a pull request is?
400 2013-08-15 15:38:57 <michagogo> "NOT FOR MERGING."
401 2013-08-15 15:39:44 <sipa> it's also a convenient way to give a patch exposure :)
402 2013-08-15 15:39:50 <jgarzik> sometimes github is just a useful patch viewing tool
403 2013-08-15 15:39:55 <jgarzik> exactly
404 2013-08-15 15:40:02 <sipa> if only it had side-by-side diff view :(
405 2013-08-15 15:41:34 <michagogo> What does the software do behind the scenes when gen=1?
406 2013-08-15 15:41:51 <michagogo> Does it generate and try to solve a getwork, or what?
407 2013-08-15 15:42:14 <sipa> no, it doesn't use getwork
408 2013-08-15 15:42:21 <sipa> it's more low level
409 2013-08-15 15:42:31 <michagogo> I see
410 2013-08-15 15:42:45 <jgarzik> BTW, I was reminded of HTTP REST + GBT:  it would be nice if a block template were returned simply get "GET /block/next"  HTTP returns a binary serialized block, template header + all transactions.  That works just fine in no-wallet situations.
411 2013-08-15 15:42:49 <handle> getwork is used to transfer a "work" object from bitcoind (or -qt) to a miner
412 2013-08-15 15:42:51 <jgarzik> Miner modifies to suit.
413 2013-08-15 15:42:59 <handle> when gen=1, it's bitcoind that's "generating"
414 2013-08-15 15:44:05 <jgarzik> michagogo, gen=1 uses the wallet + internal CPU miner
415 2013-08-15 15:45:00 <michagogo> Ah, I see -- so this patch adds a new parameter to the definitions for the RPC commands, "reqWallet"
416 2013-08-15 15:45:47 <michagogo> I guess validate address always returns false for ismine?
417 2013-08-15 15:46:06 <jgarzik> it's a bit sloppy -- some of the RPCs need to test !pwalletMain and alter behavior accordingly
418 2013-08-15 15:46:23 <michagogo> Why does verifymessage need a wallet?
419 2013-08-15 15:46:32 <jgarzik> this first test just proves that pwalletMain==NULL actually functions as a node on the network
420 2013-08-15 15:46:51 <jgarzik> michagogo, dude, I set true/false by holding down a macro key on my keyboard, don't read too much into it ;p
421 2013-08-15 15:47:01 <michagogo> A macro key?
422 2013-08-15 15:47:23 <jgarzik> My vi binds <Alt-1> to whatever macro is recorded into buffer 'a'
423 2013-08-15 15:47:39 <jgarzik> easy way to modify a lot of similar lines at once
424 2013-08-15 15:47:58 <michagogo> Looking over the list, it mostly seems fine
425 2013-08-15 15:48:09 <michagogo> except for +    { "verifymessage",          &verifymessage,          false,     false,      true },
426 2013-08-15 15:48:40 <jgarzik> other examples:  getmininginfo and getinfo report some things are that OK for no-wallet, but others must be excised
427 2013-08-15 15:48:49 <jgarzik> GBT needs minor tweaking
428 2013-08-15 15:49:06 <jgarzik> signrawtransaction obviously wants updating
429 2013-08-15 15:49:40 <michagogo> Yeah, there's plenty to tweak
430 2013-08-15 15:49:47 <jgarzik> but overall...  minimal changes in the grand scheme of things
431 2013-08-15 15:50:15 <michagogo> It's just that this one line is just wrong, unless for some reason I don't understand verifying a signature actually does require a wallet.
432 2013-08-15 15:50:25 <michagogo> Brb
433 2013-08-15 15:50:31 <jgarzik> let me look
434 2013-08-15 15:51:52 <jgarzik> michagogo, yes, verifymessage works just fine without a wallet
435 2013-08-15 15:57:37 <jgarzik> luke-jr:
436 2013-08-15 15:57:42 <jgarzik> pblocktemplate = CreateNewBlock(*pMiningKey);
437 2013-08-15 15:57:54 <jgarzik> Luke-Jr, GBT does that.  pMiningKey is from local wallet.
438 2013-08-15 16:03:32 <michagogo> jgarzik: that's what I thought. So that PR should be amended to allow it to work without one.
439 2013-08-15 16:07:30 <jgarzik> michagogo, pushed out :)
440 2013-08-15 16:07:45 <michagogo> Where in the code is the `help` RPC command handled?
441 2013-08-15 16:07:58 <michagogo> There's something I'm interested in checking
442 2013-08-15 16:12:10 <jgarzik> michagogo, bitcoinrpc.cpp
443 2013-08-15 16:15:29 <michagogo> Hmm, is github down?
444 2013-08-15 16:15:33 <michagogo> It's timing out for me
445 2013-08-15 16:15:49 <marcusw> more or less, yes
446 2013-08-15 16:20:24 <petertodd> github is ok for me
447 2013-08-15 16:35:59 <turboroot> michagogo: github was being ddosed
448 2013-08-15 16:36:44 <petertodd> turboroot: anyone know what the motive is? seems to be happening a lot
449 2013-08-15 16:37:28 <Ry4an> usually it's extortion, but github seems to savvy to pay
450 2013-08-15 16:37:33 <Ry4an> +o
451 2013-08-15 16:38:09 <turboroot> extortion in bitcoins, maybe
452 2013-08-15 16:38:42 <turboroot> petertodd: i don't know, but I like to think botnet owners do it for the "lulz"
453 2013-08-15 16:41:02 <petertodd> turboroot: could very well be a sales tactic: "My botnet strong! Look! github go down! You rent botnet? 1 million"
454 2013-08-15 16:41:42 <super3> lol. probably best to use that botnet for cpu mining
455 2013-08-15 16:41:43 <marcusw> *meeryung
456 2013-08-15 16:42:18 <super3> finally about to submit my pull request: https://github.com/bitcoin/bitcoin/pull/2902
457 2013-08-15 16:42:39 <turboroot> today is attack {freenode/github} day!
458 2013-08-15 16:42:53 <petertodd> super3: about to? I think you just did :)
459 2013-08-15 16:43:17 <petertodd> turboroot: "Please attack Bitcoin! We're important too!"
460 2013-08-15 16:43:21 <super3> able*
461 2013-08-15 16:43:39 <marcusw> "bitcoin ddos'd, nothing happens"
462 2013-08-15 16:43:54 <super3> ha ha. network it too big now. espically with asics
463 2013-08-15 16:43:59 <super3> is*
464 2013-08-15 16:44:04 <gmaxwell> super3: if only that were true.
465 2013-08-15 16:44:16 <super3> meanwhile on the other hand terracoin is getting its ass handed to it big time
466 2013-08-15 16:44:27 <gmaxwell> In actuality bitcoin itself would be rather easy to DOS, lots of it would stay up, but lots could easily be taken down.
467 2013-08-15 16:44:41 <c0rw1n> what are the points of failure?
468 2013-08-15 16:44:50 <super3> i mean you really would just have to ddos the major exchanges
469 2013-08-15 16:45:09 <super3> as well as the places where people usally spend their coins
470 2013-08-15 16:45:53 <c0rw1n> that's still a lot of places to simultaneously ddos and keep ddosed
471 2013-08-15 16:46:30 <super3> true. which is why a rolling ddos would work better
472 2013-08-15 16:47:12 <marcusw> no no, forget those, what about the network?
473 2013-08-15 16:47:20 <marcusw> one could simply kill the irc net, right?
474 2013-08-15 16:47:22 <petertodd> c0rw1n: It's really easy: there are ~5000 nodes on the network, and all you have to do is fill up their maximum incoming connections slots.
475 2013-08-15 16:47:38 <petertodd> marcusw: bitcoin doesn't use IRC anymore
476 2013-08-15 16:47:40 <c0rw1n> what 5k nodes that's all?
477 2013-08-15 16:47:51 <marcusw> haha, blockchain.info already takes up one of them
478 2013-08-15 16:48:08 <petertodd> c0rw1n: yup, 5k nodes that listen to incoming connections and are reasonably stable
479 2013-08-15 16:50:24 <c0rw1n> is there a way to do something about the probably orders of magnitude more nodes that are behind NATs and bullshit connections?
480 2013-08-15 16:51:12 <petertodd> c0rw1n: we already support UPNP to punch holes in NAT firewalls, not that much you can do beyond that
481 2013-08-15 16:51:36 <marcusw> everyone just wait for ipv6
482 2013-08-15 16:51:42 <marcusw> come back in 10 years and everything will work
483 2013-08-15 16:52:14 <petertodd> heh, good luck... I predict IPv6 will result in ISP's implementing stateful firewalls for incoming connections for the "safety" of their customers...
484 2013-08-15 16:52:32 <petertodd> though I agree it will help
485 2013-08-15 16:52:56 <marcusw> For Your Protection
486 2013-08-15 16:53:32 <petertodd> note how even Google Fiber forbids running servers in the EULA
487 2013-08-15 16:53:41 <marcusw> every ISP does that
488 2013-08-15 16:53:56 <petertodd> nope, mine doesn't (teksavvy canada)
489 2013-08-15 16:54:12 <marcusw> blocking port 25 is reverse mafia protection money
490 2013-08-15 16:54:25 <marcusw> "we'll protect you from spam unless you pay us to upgrade to business class"
491 2013-08-15 16:54:45 <petertodd> marcusw: Some ISP's are actually nice enough to only block outgoing port 25, incoming still works
492 2013-08-15 16:56:01 <marcusw> petertodd: not mine
493 2013-08-15 16:56:03 <marcusw> :(
494 2013-08-15 16:56:09 <marcusw> they block incoming port 80 actually
495 2013-08-15 16:56:13 <marcusw> "to protect from spam"
496 2013-08-15 16:56:18 <marcusw> lol idiots
497 2013-08-15 16:56:31 <Diapolo> e-mail providers should encourage use of secure smtp anyway so 587 is the one to block ^^
498 2013-08-15 17:04:23 <michagogo> super3: I made a few line comments in your PR
499 2013-08-15 17:04:39 <super3> michagogo, thanks! i replied.
500 2013-08-15 17:04:53 <super3> haven't got feedback this fast ever
501 2013-08-15 17:05:48 <michagogo> Hmm, I guess a few examples on usage for some of the more-used flags could be good
502 2013-08-15 17:06:08 <michagogo> It's just another piece of text that may eventually be outdated, is all
503 2013-08-15 17:06:15 <petertodd> super3: You familiar with the term bikeshedding? :P
504 2013-08-15 17:06:35 <michagogo> super3: And, see the 4 specific lines I commented on in the commit
505 2013-08-15 17:08:44 <super3> petertodd, wikipedia brought be up to speed
506 2013-08-15 17:08:51 <super3> me*
507 2013-08-15 17:15:54 <petertodd> FWIW killerstorm of inputs.io just told me the past 1.5 months have seen 44k BTC were transferred on the blockchain and 38k BTC transfereed off-chain, that's a lot of off-chain transactions
508 2013-08-15 17:19:54 <Ry4an> petertodd: how do they count off blockchain transactions?
509 2013-08-15 17:20:40 <petertodd> Ry4an: probably just by adding them up in their system?
510 2013-08-15 17:21:44 <marcusw> petertodd: so that's 38k on just their site, not including SR or other account-based sites?
511 2013-08-15 17:21:50 <Ry4an> ah, I didn't understand they did transactions.  I was thinking they were a reporting site.
512 2013-08-15 17:23:54 <marcusw> I don't know whether they do or not
513 2013-08-15 17:24:06 <marcusw> but if they have numbers, I assume they do
514 2013-08-15 17:25:27 <jgarzik> https://bitcointalk.org/index.php?topic=274344.0
515 2013-08-15 17:25:55 <jgarzik> I question that this is an "important announcement", especially when forum moderators did not consider the house/senate news important
516 2013-08-15 17:25:57 <jgarzik> but whatever
517 2013-08-15 17:26:17 <jgarzik> 
518 2013-08-15 17:26:17 <jgarzik> [ANN] Inputs.io transferred over 82,000 BTC
519 2013-08-15 17:26:43 <petertodd> doesn't TradeFortress get to post there by virtue of being a VIP?
520 2013-08-15 17:34:48 <K1773R> why does bitcoind save txs into the mempool which are below the mintxfee setting?
521 2013-08-15 17:37:19 <Goonie> saivann_: ping
522 2013-08-15 17:41:28 <michagogo> K1773R: In some cases transactions can be made with no fee
523 2013-08-15 17:41:50 <michagogo> Those cases are explained in the wiki's article about transaction fees
524 2013-08-15 17:42:14 <michagogo> jgarzik: I'm thinking it may be good to mark disabled commands in the output of help somehow
525 2013-08-15 17:43:02 <K1773R> michagogo: so mintxfee dosnt apply for all txs? sucks :S
526 2013-08-15 17:45:10 <michagogo> K1773R: A transaction doesn't need a fee if: a) it's smaller than 10 kB, b) all outputs are 0.01 BTC or larger, and c) sum(input_value_in_base_units * input_age)/size_in_bytes is greatet than 57,600,000
527 2013-08-15 17:45:35 <K1773R> michagogo: i know that rule, but i wonder why it bypasses the mintxfee option
528 2013-08-15 17:45:48 <michagogo> ...because there *is* no required tx fee
529 2013-08-15 17:46:05 <michagogo> mintxfee is for transactions that require fees
530 2013-08-15 17:46:11 <K1773R> michagogo: ACK
531 2013-08-15 17:46:23 <K1773R> i thougd it applys to all txs
532 2013-08-15 17:46:34 <michagogo> If you don't like that, feel free to patch the source and build your own binary
533 2013-08-15 17:46:49 <K1773R> sure, il have to ;)
534 2013-08-15 17:48:45 <K1773R> something funny about it, if you set mintxfee to 0.1 for example, GBT only spits out the tx of 0.1 or above, so saving the tx in the mempool is kinda a waste
535 2013-08-15 17:48:55 <K1773R> well, on a miners view "a waste"
536 2013-08-15 17:50:34 <saivann> Goonie: pong
537 2013-08-15 17:51:30 <Goonie> saivann: Hi, I wonder if we need a "trust required" warning for the clients page for apps that don't follow the zero-trust-model.
538 2013-08-15 17:52:43 <Goonie> saivann: Some apps like blockchain.info, Bitcoin Spinner (I think) and Mycelium require trust in a propriety server (black box, no source availble)
539 2013-08-15 17:53:17 <Goonie> saivann: So it's very similar to the web wallets.
540 2013-08-15 17:53:35 <saivann> Goonie: What kind of attacks does a remote storage of the block-chain could allow and are they really a concern in your opinion?
541 2013-08-15 17:54:46 <saivann> Blockchain.info (and hybrid web wallets) already have a warning
542 2013-08-15 17:54:55 <Goonie> saivann: Faking receiving tx for example, or blocking transactions or they could simply go out of service.
543 2013-08-15 17:55:40 <Goonie> saivann: Yes I know, but there are wallets that have the same trust model but are not webapps
544 2013-08-15 17:56:34 <saivann> As long as the user can backup their private keys, that seemed reasonable to me. I was concerned however about the risk that the developer of an app on Android can issue updates very quickly and thus can be considered like a central point of failure
545 2013-08-15 17:57:20 <saivann> Mmh, the biggest concern so far about web wallets is not that they can fake a transaction, but that they can easily steal or lose funds.
546 2013-08-15 17:57:58 <saivann> That is a delicate subject of course
547 2013-08-15 17:58:34 <marcusw> wasn't there a web wallet that actually did that a few months/years ago?
548 2013-08-15 17:59:21 <Goonie> saivann: Right, you always need to trust the developer of the app, be that webapp or native app. But that's very every wallet, including bitcoin-qt.
549 2013-08-15 17:59:44 <Goonie> saivann: The nice thing about Bitcoin is that beyond that, you don't need to trust anyone.
550 2013-08-15 17:59:58 <saivann> Bitcoin-Qt and software wallets in general don't have an efficient update mecanism for that reason
551 2013-08-15 18:00:41 <Goonie> saivann: Ok I see what you mean. Yes that's a concern. It can also be a plus like with the recent RNG issues.
552 2013-08-15 18:00:51 <saivann> Absolutely
553 2013-08-15 18:01:08 <saivann> I am uncertain about what is best, but that is a legitimate question
554 2013-08-15 18:01:25 <ahmedbodi> hey guys
555 2013-08-15 18:03:32 <Goonie> saivann: In an ideal world, everyone audits the source of the apps he likes to use (or trusts a friend to do that) and be safe. But only apps that follow the zero-trust model allow that.
556 2013-08-15 18:04:24 <Goonie> saivann: Because if your app depends on a remote server you inherit security from there. (Especially if the remote server is closed source.)
557 2013-08-15 18:06:49 <saivann> Goonie: I am actually trying to figure how a central server storing the block chain could succesfully cause anything that could be of any strong severity. In the event that they only block certain transactions or fake receiving transactions, the user can switch to a different app without loosing any funds. Unless I'm missing something, at a first glance that sounds like this doesn't need to be reported as a red bold warning.
558 2013-08-15 18:08:08 <Goonie> saivann: Well for one, fake a tx so that you hand over the car you just sold. You'll find out later the tx was fake.
559 2013-08-15 18:09:02 <Goonie> saivann: Also, if the server goes out of service and your app isn't updated, you effectively lose your private keys. Of course, a backup prevents that.
560 2013-08-15 18:09:53 <Goonie> saivann: If you can't reach the server you probably can't see your balance, send or receive coins (depends on the implementation, but still its an issue).
561 2013-08-15 18:10:05 <saivann> The last case scenario applies to hybrid wallets that indeed have a warning. But to my knowledge, this doesn't apply to mycelium and electrum, right?
562 2013-08-15 18:10:28 <Goonie> which scenario?
563 2013-08-15 18:10:44 <saivann> Losing private keys when the central server goes out of service
564 2013-08-15 18:11:08 <jgarzik> OK, disable-wallet mode appears to be working
565 2013-08-15 18:11:10 <Goonie> electrum allows you to set up your own server because that's open source, right.
566 2013-08-15 18:11:13 <ahmedbodi> hey guys
567 2013-08-15 18:11:15 <ahmedbodi> would this be the best place to ask about getting stratum for setting up a pool
568 2013-08-15 18:11:20 <Goonie> Mycelium is closed source however (server side)
569 2013-08-15 18:11:21 <jgarzik> reviewed all RPCs, go/no-go for launch
570 2013-08-15 18:11:24 <michagogo> ahmedbodi: #bitcoin-mining
571 2013-08-15 18:11:44 <ahmedbodi> for actual setting up a pool right^
572 2013-08-15 18:12:21 <marcusw> ahmedbodi: in-ground or above-ground?
573 2013-08-15 18:12:30 <saivann> Mmh
574 2013-08-15 18:12:48 <ahmedbodi> aboce ground :P
575 2013-08-15 18:14:06 <saivann> Goonie: Perhaps that we should have a "orange" (middle severity) warning for closed source servers/wallets? The current "web wallet" warning clearly is not appropriate for this specific case.
576 2013-08-15 18:14:44 <Goonie> saivann: Yes, that'll be appropriate I think.
577 2013-08-15 18:14:54 <saivann> Goonie: Also concretely, I suppose that most people are using Electrum central server and not their own, even though it is a very good practice to allow users to build their own servers by disclosing the source code.
578 2013-08-15 18:15:25 <Goonie> saivann: Yes, and at least they can switch if they want to, later.
579 2013-08-15 18:17:03 <saivann> Goonie: I'll look to write something and make a pull request probably later today.
580 2013-08-15 18:17:21 <Goonie> saivann: cool
581 2013-08-15 18:37:37 <gmaxwell> saivann: a centeral server giving you the blockchain can conduct theft against someone who will take an irreversable action based on payments bounded only by the actions they'll take.
582 2013-08-15 18:37:59 <gmaxwell> saivann: e.g. you use my server, I buy a car from you, now I give you fake payments.
583 2013-08-15 18:38:30 <gmaxwell> If the nodes don't do SPV validation of tx inputs, I could also lie to you about the value of real payments to you, causing you to convert all your coins to fees.
584 2013-08-15 18:39:14 <gmaxwell> neither of these are just DOS attacks.
585 2013-08-15 18:39:50 <gmaxwell> Existing webwallets have the same risks, plus potentially being able to replace the client software.
586 2013-08-15 18:47:24 <jgarzik> Alas, disable-wallet mode saves next to no memory (but then, that was not its goal).  It saves a little.
587 2013-08-15 18:49:35 <gmaxwell> jgarzik: hm. are you still loading BDB?
588 2013-08-15 18:49:43 <gmaxwell> IIRC there is at least a few megabytes lost there.
589 2013-08-15 18:53:59 <jgarzik> gmaxwell, probably yes; good point
590 2013-08-15 18:54:39 <jgarzik> gmaxwell, I think the BDB env init is done pre-main(), in C++ constructor land
591 2013-08-15 18:54:48 <jgarzik> ACTION goes to check
592 2013-08-15 18:56:23 <gmaxwell> other than loading the wallet itself (which is only a lot for bloated wallets) and bdb the wallet code uses very little memory.
593 2013-08-15 19:01:47 <jgarzik> gmaxwell, tested and pushed out that change to the branch
594 2013-08-15 19:03:45 <jgarzik> gmaxwell, heh, that shaved almost 40MB off my startup RSS
595 2013-08-15 19:04:16 <gmaxwell> jgarzik: good, yea, not shocked there.
596 2013-08-15 19:08:12 <michagogo> Hmm
597 2013-08-15 19:08:26 <michagogo> The help entry for listsinceblock is a bit unclear
598 2013-08-15 19:23:34 <michagogo> https://github.com/bitcoin/bitcoin/pull/2903 fixes it
599 2013-08-15 19:35:00 <aceat64> anyone else have bitcoin-qt adding "-000" to the end of the txid when you click on "Copy transaction id"?
600 2013-08-15 19:35:39 <michagogo> aceat64: I believe that's which vout it is
601 2013-08-15 19:37:24 <aceat64> michagogo: why would we want to append that to the txid?
602 2013-08-15 19:37:31 <michagogo> I have no idea
603 2013-08-15 19:37:53 <michagogo> I find it very annoying :-/
604 2013-08-15 19:38:16 <sipa> perhaps that's the vout index?
605 2013-08-15 19:38:20 <sipa> oh
606 2013-08-15 19:38:22 <sipa> ACTION is late
607 2013-08-15 19:38:49 <sipa> if you want to identify the txout crediting you (which is useful in case you want to construct a raw transaction), you need that vout index
608 2013-08-15 19:40:13 <michagogo> sipa: The annoying part is that, with -### appended, the string as-is doesn't work for pasting into getrawtransaction, createrawtransaction, etc
609 2013-08-15 19:40:27 <TalkSoup> hey does anyone have any ideas as to where i can get a working stratum software for a pool?
610 2013-08-15 19:40:44 <k9quaint> gmaxwell: I can't believe you deleted my linkspam :(
611 2013-08-15 19:40:59 <warren> hmm, do you need approval to edit translations on transifex?
612 2013-08-15 19:41:16 <sipa> never done so, but i don't think so
613 2013-08-15 19:41:41 <warren> i don't see any edit optoin
614 2013-08-15 19:42:49 <FaucetBot> meh im talking to myself here
615 2013-08-15 19:44:04 <aceat64> I still think it makes no sense to include the vout index (if that's what it is) in this context. Heck, it isn't included in the txn details window!
616 2013-08-15 19:44:55 <sipa> pull requests welcome, i guess
617 2013-08-15 19:46:55 <aceat64> ya, now I just need to figure out how stuff works in qt... lol
618 2013-08-15 19:48:16 <helo> aceat64: it's for creating raw transactions
619 2013-08-15 20:07:25 <michagogo> helo: That's when you need it, yes
620 2013-08-15 20:07:51 <michagogo> helo: But appending it as -000 to the txid when you select "copy txid" doesn't really make sense
621 2013-08-15 20:11:51 <helo> troof
622 2013-08-15 20:28:56 <gmaxwell> sipa: I could have sworn I commented on the BIP32 test vectors.  Have we heard from a second implementation that they were able to use the vectors and get agreement?  If so, ACK.
623 2013-08-15 20:29:47 <sipa> gmaxwell: yes, several
624 2013-08-15 20:29:49 <gribble> The operation succeeded.
625 2013-08-15 20:29:49 <michagogo> ;;later tell BlueMatt Feature request/suggestion for pulltester: Only bother testing on pull requests that, ya know, actually modify code...
626 2013-08-15 20:30:04 <sipa> gmaxwell: they caught a bug in bitsofproof's BIP32 implementation even
627 2013-08-15 20:31:53 <sipa> gmaxwell: also, the test vectors were produced by an ad-hoc implementation, predating the pull request
628 2013-08-15 20:32:27 <gmaxwell> sipa: Right, mostly I was looking for "not implemented by you"
629 2013-08-15 20:34:02 <sipa> good point
630 2013-08-15 20:34:13 <sipa> well, technically *this* implementation didn't catch any bugs
631 2013-08-15 20:51:21 <Diablo-D3> hey guys
632 2013-08-15 20:51:24 <Diablo-D3> remember when I said SMS
633 2013-08-15 20:51:25 <Diablo-D3> http://blog.coinbase.com/post/58354652059/you-can-now-perform-all-basic-actions-in-bitcoin
634 2013-08-15 20:51:37 <Diablo-D3> requires to have your bitcoins at coinbase
635 2013-08-15 20:51:50 <Diablo-D3> but this really does make bitcoin africa-able now