1 2013-11-07 00:17:51 <Zarutian> 
ACTION finally goes and updates to version 0.8.5

  2 2013-11-07 00:18:27 <Zarutian> how long does reindexing usually take?
  3 2013-11-07 00:27:40 <sipa> Zarutian: depends on cpu, database cache size, disk speed
  4 2013-11-07 00:28:09 <Zarutian> I only need a very rough gestimate
  5 2013-11-07 00:28:16 <Zarutian> guestimate*
  6 2013-11-07 00:28:17 <sipa> if you have spare ram, passing -dbcache=1000 helps a lot
  7 2013-11-07 00:28:20 <berndj> on my laptop it took about a whole day
  8 2013-11-07 00:28:54 <Zarutian> berndj: thank you.
  9 2013-11-07 00:29:02 <sipa> that sounds lomg
 10 2013-11-07 00:29:05 <berndj> 3GB RAM, so it was hitting the disk hard
 11 2013-11-07 00:29:22 <sipa> berndj: it won't use extra ram unless you tell it to
 12 2013-11-07 00:29:54 <berndj> sipa, i always assumed that unless you have ram > ~15GB, it wouldn't matter much anyway?
 13 2013-11-07 00:30:12 <berndj> i thought it's basically a hash table access pattern - random accesses all over
 14 2013-11-07 00:30:31 <berndj> is this slightly / moderately / completely wrong?
 15 2013-11-07 00:31:52 <sipa> huh
 16 2013-11-07 00:32:09 <sipa> even addimg a few hundred MiB helps a lot
 17 2013-11-07 00:32:12 <BlueMatt> the entire statedb doesnt take that much space
 18 2013-11-07 00:32:25 <sipa> the database is only 250 MiB on disk
 19 2013-11-07 00:32:31 <BlueMatt> 274M
 20 2013-11-07 00:33:03 <berndj> doesn't it have to read through the entire blockchain on a reindex?
 21 2013-11-07 00:33:09 <sipa> berndj: yes, sequentially
 22 2013-11-07 00:33:23 <berndj> and the tx are all over, no?
 23 2013-11-07 00:33:28 <BlueMatt> reading 15GB sequentially is no where near the limiting factor once you get up into later blocks
 24 2013-11-07 00:33:39 <sipa> berndj: no, sequentially
 25 2013-11-07 00:33:46 <sipa> you read one block, process it
 26 2013-11-07 00:33:52 <sipa> read the next block, process it
 27 2013-11-07 00:34:03 <berndj> sipa, i mean, each block contains a bunch of tx, those tx: aren't they all over the disk?
 28 2013-11-07 00:34:10 <sipa> no
 29 2013-11-07 00:34:24 <BlueMatt> why would they be? you're iterating over each block linearly
 30 2013-11-07 00:34:24 <sipa> the blocks are stored sequentially on disk
 31 2013-11-07 00:34:34 <berndj> hmm, then i've been enduring a lot of pain unnecessarily
 32 2013-11-07 00:35:00 <berndj> BlueMatt, iterating over the block, but... but... oooh, right, the entire tx is included in the block
 33 2013-11-07 00:35:00 <gavinandresen> looking up transaction inputs is random unless you do it smartly
 34 2013-11-07 00:35:08 <berndj> am i right so far?
 35 2013-11-07 00:35:11 <sipa> berndj: yes
 36 2013-11-07 00:35:31 <BlueMatt> and that 200MB database contains all the unspent transaction outputs
 37 2013-11-07 00:35:39 <sipa> berndj: what you're probably missimg is that we keep a separate, much smaller, database with only the unspemt transaction outputs
 38 2013-11-07 00:35:45 <berndj> but... *checking* the tx - doesn't that require chasing random pointers all over?
 39 2013-11-07 00:36:01 <gavinandresen> no, just that little database.
 40 2013-11-07 00:36:03 <BlueMatt> gavinandresen: any pointers on who might spare a ec2 instance or two for relay nodes?
 41 2013-11-07 00:36:08 <sipa> and this database is what gets updated all the time throughout the processimg
 42 2013-11-07 00:36:13 <BlueMatt> just need two more to hit the 4 regions I want for initial bootstrap
 43 2013-11-07 00:36:15 <berndj> sipa, i was vaguely aware of that, but hadn't connected it to the present discussion
 44 2013-11-07 00:36:28 <sipa> berndj: so up to 0.7 you were right
 45 2013-11-07 00:36:36 <gavinandresen> BlueMatt: we've got leftover dev team budget that has deflated, that seems like a really good use for it
 46 2013-11-07 00:36:57 <sipa> we looked up every transaction's input directly in the block chain
 47 2013-11-07 00:37:13 <BlueMatt> gavinandresen: well, disk and cpu doesnt matter, so its really just 2 micro instances at this point
 48 2013-11-07 00:37:24 <BlueMatt> or any bitcoin-accepting vps provider, probably
 49 2013-11-07 00:37:32 <berndj> and... on a reindex, the only tx you're (hopefully) looking up are unspent ones, which are in the utxo database?
 50 2013-11-07 00:37:36 <BlueMatt> as long as they have presence in asia and us-west
 51 2013-11-07 00:37:44 <berndj> is that what i was overlooking?
 52 2013-11-07 00:37:54 <sipa> berndj: you never ever need anything but what is in the utxo set
 53 2013-11-07 00:38:08 <sipa> berndj: except when you're processimg history of course
 54 2013-11-07 00:38:16 <sipa> or server history to another node
 55 2013-11-07 00:38:24 <gavinandresen> BlueMatt: put together a little budget and I'll send you the coin, unless sipa jgarzik gmaxwell veto that use of dev team funds
 56 2013-11-07 00:38:34 <berndj> we were talking about reindexing, i think
 57 2013-11-07 00:38:41 <sipa> i shall veto such veto :)
 58 2013-11-07 00:38:45 <berndj> (oh and my reindex that took a day was for txindex=1)
 59 2013-11-07 00:38:45 <MC1984> so this relay network gets big, gets relied upon then gets flattened with a ddos
 60 2013-11-07 00:38:55 <BlueMatt> gavinandresen: sgtm, Ill see if I can find btc-accepting vps providers that are reasonable and otherwise just see what ec2 would cost
 61 2013-11-07 00:38:55 <MC1984> doesnt that exacerbate partitioning risk
 62 2013-11-07 00:39:33 <sipa> berndj: when building a txindex, it matters even more to increase the dbcache
 63 2013-11-07 00:39:37 <berndj> what regions do you need to cover?
 64 2013-11-07 00:39:58 <BlueMatt> MC1984: the relay network comes with disclaimers everywhere that it is in no way designed to replace the p2p network, and if you rely on only it you will possibly miss blocks/txn
 65 2013-11-07 00:40:10 <berndj> sipa, i shall study that dbsize thing right now, thanks :)
 66 2013-11-07 00:40:19 <MC1984> no one reads disclaimers
 67 2013-11-07 00:40:19 <sipa> -dbcache=number
 68 2013-11-07 00:40:25 <sipa> where number is in megabytes
 69 2013-11-07 00:40:38 <BlueMatt> MC1984: (and the relay network is designed to be partition-able into public/private parts if the public parts get hit with ddos)
 70 2013-11-07 00:40:41 <sipa> BlueMatt: you should have it randomly drop 1% of blocls
 71 2013-11-07 00:40:43 <sipa> blocks
 72 2013-11-07 00:40:53 <BlueMatt> MC1984: well when you miss a block and cant mine anymore....
 73 2013-11-07 00:40:58 <BlueMatt> sipa: hmm, yes, maybe I should
 74 2013-11-07 00:41:16 <BlueMatt> (currently, if you get disconnected and then reconnect you will miss a block, but always doing that may be nice)
 75 2013-11-07 00:41:26 <MC1984> i dont like it
 76 2013-11-07 00:41:31 <MC1984> temporary measures are never temporary
 77 2013-11-07 00:41:41 <BlueMatt> its not designed to be temporary
 78 2013-11-07 00:41:54 <MC1984> my opinion counts for shit, but there it is
 79 2013-11-07 00:42:02 <BlueMatt> this is something me/jgarzik/others have been talking about putting together for years
 80 2013-11-07 00:42:11 <gavinandresen> MC1984: so create another fast relay network….
 81 2013-11-07 00:42:20 <BlueMatt> do you disagree for any reason other than centralization?
 82 2013-11-07 00:42:29 <gavinandresen> Two is better than one.  Eleven would be best.
 83 2013-11-07 00:42:52 <MC1984> gavinandresen my instinct would just be to make the amorphous fuzzball network we have now more efficient
 84 2013-11-07 00:43:03 <gavinandresen> MC1984: okey dokey, then do that.
 85 2013-11-07 00:43:13 <MC1984> i cant
 86 2013-11-07 00:43:16 <berndj> BlueMatt, which are the regions you still want to cover?
 87 2013-11-07 00:43:36 <BlueMatt> berndj: something in asia/australia and something in us-west
 88 2013-11-07 00:43:52 <berndj> ah, i was almost going to offer africa
 89 2013-11-07 00:44:02 <BlueMatt> do we have miners in africa?
 90 2013-11-07 00:44:18 <berndj> i believe there's a guy with asic gear here in south africa
 91 2013-11-07 00:44:27 <berndj> can't be the only one
 92 2013-11-07 00:44:49 <BlueMatt> hmm...well if there is demand I can throw one up there
 93 2013-11-07 00:45:05 <berndj> see if you can rouse fluffypony, although i think he's moved his gpu farm to litecoin
 94 2013-11-07 00:46:12 <MC1984> i also get the feeling this backbone works somehow to entrench the pooled mining model even more than it is
 95 2013-11-07 00:46:27 <BlueMatt> MC1984: agreed, if there weren't public peering nodes
 96 2013-11-07 00:46:44 <BlueMatt> and any individual miners who have reasonable hashrate should absolutely fill out the private-peering form
 97 2013-11-07 00:47:05 <MC1984> fill out a form to fucking mine, are you serious
 98 2013-11-07 00:47:50 <BlueMatt> umm...no? to mine you can do nothing, or addnode the public nodes, or get on the private nodes if you have a ton of mining power and are considered to be vital to the continued operation of the network
 99 2013-11-07 00:48:03 <BlueMatt> ie if things go to shit, gotta make sure you're still connected
100 2013-11-07 00:48:27 <MC1984> i know what the objective is and i see the logic
101 2013-11-07 00:49:30 <MC1984> i just fear scope creep
102 2013-11-07 00:49:52 <BlueMatt> I think dropping 1% of blocks is probably not a bad idea
103 2013-11-07 00:49:56 <BlueMatt> to discourage scope creep
104 2013-11-07 00:50:41 <MC1984> sigh
105 2013-11-07 00:50:56 <sipa> i know, i know! you take the double-sha256 hash of the block header, and if it is less than 0x02, you drop it!
106 2013-11-07 00:51:13 <sipa> *the last byte
107 2013-11-07 00:51:18 <BlueMatt> yea, I was thinking that
108 2013-11-07 00:51:35 <BlueMatt> though I prefer dropping if its either BE or EF
109 2013-11-07 00:51:40 <MC1984> inelegant. i dont want spinners and a wing on muh bitcoin :(
110 2013-11-07 00:52:21 <sipa> beef is good
111 2013-11-07 00:52:52 <BlueMatt> MC1984: also, I would like to encourage someone to setup a bitcoin block relay service that relays over arbitrary other protocols
112 2013-11-07 00:53:03 <BlueMatt> eg relay blocks over twitter and make a client that listens and pushes them to a bitcoind
113 2013-11-07 00:53:07 <BlueMatt> or over ham radio
114 2013-11-07 00:53:08 <BlueMatt> or...
115 2013-11-07 00:53:11 <berndj> i was thinking that just today! blocks over nntp!
116 2013-11-07 00:53:16 <MC1984> headers?
117 2013-11-07 00:53:17 <Beef> sipa: Thanks... you're good too. :P
118 2013-11-07 00:53:17 <berndj> and yes, radio
119 2013-11-07 00:53:20 <BlueMatt> its all about ensuring reliable block delivery everywhere
120 2013-11-07 00:53:32 <BlueMatt> no, full blocks
121 2013-11-07 00:53:35 <Zarutian> BlueMatt: over Irridium dataservice/pager ?
122 2013-11-07 00:53:37 <BlueMatt> headers are nice, but you need full blocks to mine
123 2013-11-07 00:53:42 <BlueMatt> Zarutian: sure, why not
124 2013-11-07 00:53:53 <MC1984> headers over a broadcast medium i dont disagree with
125 2013-11-07 00:54:09 <BlueMatt> I happened to pick the existing p2p protocol for ease-of-use, but its no different
126 2013-11-07 00:54:16 <MC1984> but i dont see how it could be kept cheap with full blocks. thats choudl be kept for p2p prob
127 2013-11-07 00:55:21 <BlueMatt> depends on the service
128 2013-11-07 00:55:47 <MC1984> i woundlt disagree with fullbox over packet radio or somthing either
129 2013-11-07 00:56:08 <berndj> dunno if it falls in the rules for ham radio though?
130 2013-11-07 00:56:09 <MC1984> but that wont happen either if the uncap all the blocks people get thier way
131 2013-11-07 00:56:45 <BlueMatt> maybe twitter would be too high-volume, but its just avg 1MB/10minutes
132 2013-11-07 00:56:49 <BlueMatt> so its really not all that much data
133 2013-11-07 00:57:12 <MC1984> id rather just get headers uplinked to a microsat covering a continent, even if the things only stay up for a few months before reentry
134 2013-11-07 00:57:18 <MC1984> that would be swish
135 2013-11-07 00:57:48 <BlueMatt> anyway, this is all very theoretical, y'all should totally build your own block relay network and come back and show something awesome
136 2013-11-07 00:58:00 <BlueMatt> you cant mine on headers
137 2013-11-07 00:58:08 <BlueMatt> broadcasting headers to everyone really only has limited use
138 2013-11-07 00:58:19 <MC1984> headers for security
139 2013-11-07 00:58:37 <BlueMatt> yea, but even an spv node cant rely on only headers, they have to find their transactions somewhere
140 2013-11-07 00:59:09 <MC1984> well its in addition to p2p
141 2013-11-07 00:59:10 <BlueMatt> it provides some level of increased anti-sybil protection, but its not useful
142 2013-11-07 01:00:21 <MC1984> pff, everyone was popping off about a bitcoin sat a few months ago
143 2013-11-07 01:01:04 <berndj> what sort of data rate do you need for headers only / full blocks?
144 2013-11-07 01:01:09 <BlueMatt> broadcasting full blocks (which, obv, include headers) is the way to go, if you can do it
145 2013-11-07 01:02:06 <MC1984> consider how much bandwidth GPS downlinks
146 2013-11-07 01:02:21 <MC1984> its like bytes per second
147 2013-11-07 01:03:02 <berndj> but really 10Mbps to get the accuracy
148 2013-11-07 01:03:20 <BlueMatt> if you can fit 10Mbps you can very easily get full blocks
149 2013-11-07 01:03:29 <BlueMatt> blocks max out at 1MB right now
150 2013-11-07 01:04:07 <berndj> MC1984, the ephemeris you get from the GPS sat is really just riding on a side channel
151 2013-11-07 01:04:16 <berndj> it's the timing info that's everything
152 2013-11-07 01:04:16 <Zarutian> 1.748 KiloBytes per sec is less than most audio channels of DVB-S iirc
153 2013-11-07 01:04:51 <Zarutian> that is stuffing one block through over the whole ten minute interval
154 2013-11-07 01:05:10 <MC1984> doesnt work like that
155 2013-11-07 01:05:39 <Zarutian> good for confirmations but not mining
156 2013-11-07 01:05:46 <MC1984> if that was true wed have to build+
157 2013-11-07 01:05:55 <MC1984>  a bitcoin orphanage
158 2013-11-07 01:10:58 <Zarutian> but bursts of 1 MeBiByte every ten minutes is well within the ability of an satelite television station to provide without affecting the quality of their audiovisual content. (Spread it over 5-20 secs or so)
159 2013-11-07 01:11:57 <phantomcircuit> BlueMatt, why not headers + merkle tree + transactions not previously broadcast
160 2013-11-07 01:13:58 <BlueMatt> phantomcircuit: a) requires processing overhead per node, b) its expected that many/most nodes will only connect to the blocks-only port
161 2013-11-07 01:14:28 <phantomcircuit> BlueMatt, then full blocks on blocks only
162 2013-11-07 01:14:53 <phantomcircuit> actually i guess whatever
163 2013-11-07 01:16:17 <berndj> MC1984, you can do speculative execution of mining. send the header first; assume it's valid (no double spends etc) and start mining; over 10 minutes the full block comes in and you can check it when it's all arrived
164 2013-11-07 01:16:33 <berndj> how often do you expect to see blocks that aren't valid?
165 2013-11-07 01:17:56 <MC1984> i was told it was a bad idea
166 2013-11-07 01:22:55 <sipa> berndj: you can't accept any transactions in that case
167 2013-11-07 01:22:58 <BlueMatt> if it takes 2 seconds to receive the full block, sure, you can spv-validate the header and speculatively mine on the next block (but, when you do that, the next block you mine has to have no transactions, so you lose fees, and you cant release the next block until you've validated the block you just got)
168 2013-11-07 01:23:11 <BlueMatt> so its not ideal, but if you just have to wait a second or so, you can do it
169 2013-11-07 01:23:14 <BlueMatt> (p2pool does, iirc)
170 2013-11-07 01:23:31 <BlueMatt> actually, not even sure p2pool does full spv-validation, it may just check hash target
171 2013-11-07 01:30:44 <berndj> you could accept new tx that arrive after the previous block header-carrying pigeon arrives
172 2013-11-07 01:30:59 <BlueMatt> no
173 2013-11-07 01:31:08 <BlueMatt> may be a double-spend against a now-confirmed tx
174 2013-11-07 01:31:21 <berndj> you'll find that out by the time you have the full header
175 2013-11-07 01:31:34 <berndj> yes, in which case your effort is wasted, but that's pragmatics
176 2013-11-07 01:32:11 <BlueMatt> well you might as well not waste effort and include no txn instead of potentially waste effort (and probably not be able to claim fees on those txn anyway)
177 2013-11-07 01:33:30 <berndj> anyway, what sort of dystopian world is this where it takes 10 minutes to transfer a megabyte!
178 2013-11-07 01:34:14 <berndj> 19200bps dialup :)
179 2013-11-07 01:36:18 <sipa> berndj: even if it is a few seconds, the chance of producing an invalid block during that period may be significant
180 2013-11-07 01:38:18 <gulli> Im trying to figure one thing out here about armory's cold and hot wallets. If I am understanding this correctly, the hot wallet does not know the starting seed value (if it would, then it woulnt be that secure at all), so how can it generate new addresses?
181 2013-11-07 01:39:01 <BlueMatt> magical math
182 2013-11-07 01:41:10 <gulli> how?
183 2013-11-07 01:42:10 <BlueMatt> bip 32
184 2013-11-07 01:42:20 <BlueMatt> https://en.bitcoin.it/wiki/BIP_0032
185 2013-11-07 01:43:14 <gulli> yeah I just found it
186 2013-11-07 01:45:11 <shamoon> what's a vOneShots?
187 2013-11-07 01:45:25 <shamoon>         AddOneShot(strDest);
188 2013-11-07 01:45:25 <shamoon>     BOOST_FOREACH(string strDest, mapMultiArgs["-seednode"])
189 2013-11-07 01:45:29 <shamoon> is that where it first finds peers?
190 2013-11-07 01:46:18 <berndj> is there a place to send random 1-line patches to bitcoind?
191 2013-11-07 01:46:53 <BlueMatt> shamoon: that is an optional way to first fine peers
192 2013-11-07 01:47:00 <BlueMatt> berndj: github, really...
193 2013-11-07 01:47:12 <shamoon> in the source, where's the FIRST way to find peers?
194 2013-11-07 01:47:14 <berndj> forking seems a bit heavyweight for a 1-liner, but ok
195 2013-11-07 01:47:23 <BlueMatt> shamoon: dnsseeds
196 2013-11-07 01:47:43 <BlueMatt> berndj: if you really want you could just open a bug with the ticket, but gavinandresen might not be happy about that
197 2013-11-07 01:47:43 <shamoon> strMainNetDNSSeed
198 2013-11-07 01:48:12 <Luke-Jr> shamoon: first in what sense?
199 2013-11-07 01:48:27 <shamoon> so i start the client, standalone, not connected to a network
200 2013-11-07 01:48:32 <shamoon> it'll jsut kinda sit there and wait
201 2013-11-07 01:48:36 <Luke-Jr> shamoon: it will check your own IP database first; but if it's a first-time user who doesn't have that, dns seeds
202 2013-11-07 01:48:52 <shamoon> what info does it get from the dns seed?
203 2013-11-07 01:49:01 <sipa> IP addresses of potential peers
204 2013-11-07 01:49:03 <shamoon> {"bitcoin.sipa.be", "seed.bitcoin.sipa.be"}
205 2013-11-07 01:49:06 <sipa> which go into the address database
206 2013-11-07 01:49:20 <sipa> and the connection logic fetches addresses from that database to connect to
207 2013-11-07 01:49:32 <shamoon> if i go to it on port 80, it goes to network graphs
208 2013-11-07 01:49:43 <shamoon> what port does it grab the IP's from?
209 2013-11-07 01:49:58 <BlueMatt> lol, TD[away]'s G+ post has now made it all the way to the verge
210 2013-11-07 01:50:06 <sipa> shamoon: it grabs them from DNS
211 2013-11-07 01:50:10 <sipa> it doesn't connect to it
212 2013-11-07 01:50:31 <gavinandresen> TD says bad things about the NSA, and is now [away] … hmmm,coincidence?
213 2013-11-07 01:50:31 <shamoon> A record?
214 2013-11-07 01:50:35 <sipa> it just looks up seed.bitcoin.sipa.be, which resolves to some random bitcoin node's IP addresses
215 2013-11-07 01:50:39 <BlueMatt> gavinandresen: heh
216 2013-11-07 01:50:45 <shamoon> http://mxtoolbox.com/SuperTool.aspx?action=a%3abitcoin.sipa.be&run=toolpage
217 2013-11-07 01:51:13 <gavinandresen> I'm wearing my tinfoil beanie today.
218 2013-11-07 01:51:15 <sipa> shamoon: not bitcoin.sipa.be
219 2013-11-07 01:51:21 <sipa> shamoon: seed.bitcoin.sipa.be
220 2013-11-07 01:51:25 <sipa> the first is just the site that owns it
221 2013-11-07 01:51:45 <shamoon> so http://mxtoolbox.com/SuperTool.aspx?action=a%3abitcoin.sipa.be&run=toolpage#t
222 2013-11-07 01:51:52 <shamoon> these are the peers it tries
223 2013-11-07 01:52:06 <sipa> well you get a different list every time
224 2013-11-07 01:52:16 <shamoon> and if those seeds don't work, then it uses pnSeed?
225 2013-11-07 01:52:23 <sipa> no
226 2013-11-07 01:52:28 <shamoon> then?
227 2013-11-07 01:52:32 <sipa> all that happens is that these go into your local database
228 2013-11-07 01:52:46 <sipa> together with IP addresses it gets from other peers
229 2013-11-07 01:52:51 <sipa> or that get -addnode'd
230 2013-11-07 01:52:54 <shamoon> what if the DNS seeds are down
231 2013-11-07 01:53:06 <shamoon> pnSeed is hardcoded peers, correct?
232 2013-11-07 01:53:09 <gavinandresen> sipa: can I throw some wallet-dealing-with-double-spends-better ideas off you?  You have time?
233 2013-11-07 01:53:36 <sipa> shamoon: if after N time (i forgot how long), nothing useful appears in the local database, it adds some from pnSeed
234 2013-11-07 01:53:42 <sipa> gavinandresen: not now, about to head to bed
235 2013-11-07 01:53:54 <gavinandresen> sipa: ok, good night!
236 2013-11-07 01:54:01 <shamoon> so if iw ant to create my own private bitcoin network, i can disable the dns seeds and hardcode a pnSeed or 2
237 2013-11-07 01:54:02 <shamoon> ?
238 2013-11-07 01:54:10 <sipa> just run testnet
239 2013-11-07 01:54:21 <BlueMatt> sipa: damn you, I wanted to be here for that
240 2013-11-07 01:54:24 <sipa> you can use -nodnsseed i think
241 2013-11-07 01:54:25 <shamoon> i'm testing network stuffs
242 2013-11-07 01:54:30 <shamoon> not bitcoin stuffs
243 2013-11-07 01:54:35 <gavinandresen> or, probably even better -regtest network (easier to create new blocks)
244 2013-11-07 01:54:46 <BlueMatt> shamoon: -connect=... means dont listen, dont make any connections except to ...
245 2013-11-07 01:54:56 <BlueMatt> it may still do dnsseed lookups, but it doesnt use those addresses
246 2013-11-07 01:55:02 <BlueMatt> and use -regtest
247 2013-11-07 01:55:09 <sipa> listen to BlueMatt
248 2013-11-07 01:55:12 <shamoon> so i can hardcode, int he code, the -connect
249 2013-11-07 01:55:14 <sipa> he's more awake than i am
250 2013-11-07 01:55:18 <sipa> cya!
251 2013-11-07 01:55:24 <shamoon> i can run 2 instances, each that connect to each other
252 2013-11-07 01:55:31 <shamoon> then i'll have my own private 2 node bitcoin network?
253 2013-11-07 01:55:37 <BlueMatt> why hardcode? just put it in your bitcoin.conf
254 2013-11-07 01:55:39 <BlueMatt> but, yes
255 2013-11-07 01:55:45 <shamoon> well, to make a specialized client
256 2013-11-07 01:55:48 <shamoon> for another purpose
257 2013-11-07 01:55:51 <shamoon> other than bitcoin
258 2013-11-07 01:55:52 <BlueMatt> one with -listen -connect=0.0.0.0, one with -connect=127.0.0.1:...
259 2013-11-07 01:56:43 <gavinandresen> my tinfoil hat is ringing with ideas on what your mysterious "other purpose" might be....
260 2013-11-07 01:57:01 <shamoon> gavinandresen: ha, wish i could tell you
261 2013-11-07 01:57:02 <shamoon> but not yet
262 2013-11-07 01:57:18 <shamoon> BlueMatt: i assuem 127 is the ip of the one that i -listen on?
263 2013-11-07 01:57:23 <BlueMatt> yea
264 2013-11-07 01:58:04 <shamoon> so now i set them both to setgenerate=true
265 2013-11-07 01:58:13 <shamoon> so i should see blocks rolling in soon
266 2013-11-07 01:58:38 <BlueMatt> if you have shittons of cpu, sure
267 2013-11-07 01:58:45 <shamoon> why?
268 2013-11-07 01:58:51 <shamoon> it's a fresh start where they connec tot each other
269 2013-11-07 01:58:53 <shamoon> 0 blocks
270 2013-11-07 01:58:55 <BlueMatt> even diff 1 isnt particularly easy
271 2013-11-07 01:59:02 <BlueMatt> but, yes, you will eventually see blocks
272 2013-11-07 01:59:06 <BlueMatt> hence, -regtest
273 2013-11-07 01:59:11 <BlueMatt> which sets a different min diff
274 2013-11-07 01:59:15 <shamoon> why do i have 0 blocks?
275 2013-11-07 01:59:17 <shamoon> shouldn't i have 1?
276 2013-11-07 01:59:19 <shamoon> the genesis
277 2013-11-07 01:59:21 <BlueMatt> (which is insanely ridiculously easy)
278 2013-11-07 01:59:24 <sipa> genesis is block 0
279 2013-11-07 01:59:26 <BlueMatt> genesis == block 0
280 2013-11-07 01:59:31 <sipa> and you'll need -nocheckpoints
281 2013-11-07 01:59:38 <shamoon> ohh
282 2013-11-07 01:59:38 <shamoon> right
283 2013-11-07 01:59:48 <sipa> and there may be other random things failing, as it's not really designed for this
284 2013-11-07 02:00:04 <BlueMatt> hence, use -regtest
285 2013-11-07 02:00:07 <BlueMatt> which is designed for this
286 2013-11-07 02:00:10 <shamoon> what is regtest?
287 2013-11-07 02:03:55 <Bkil> I was working on getting s testnet setup for s project I was going go do and couldn't find anything that said use -regtest
288 2013-11-07 02:04:10 <Bkil> Found all the testnet stuff though
289 2013-11-07 02:05:43 <shamoon> thanks sipa and BlueMatt
290 2013-11-07 02:05:46 <shamoon> you guys rock
291 2013-11-07 02:09:47 <shamoon> i changed to: static const int64 nTargetSpacing = 1 * 60;
292 2013-11-07 02:09:50 <shamoon> to get 1 minute blocks
293 2013-11-07 02:09:52 <shamoon> still nothing
294 2013-11-07 02:14:39 <shamoon> BlueMatt: sipa gavinandresen - any thoughts?
295 2013-11-07 02:15:09 <gavinandresen> sipa is asleep. I'm thinking about other things, you're on your own....
296 2013-11-07 02:15:12 <BlueMatt> shamoon: use regtest, it sets the meaning of diff 1 to mean 1 in 2 shot at getting a block
297 2013-11-07 02:15:26 <BlueMatt> vs the mainnet meaning of quite hard
298 2013-11-07 02:15:33 <shamoon> just add -regtest?
299 2013-11-07 02:15:36 <BlueMatt> yea
300 2013-11-07 02:15:39 <BlueMatt> on all nodes
301 2013-11-07 02:15:41 <gavinandresen> BlueMatt: I can't remember was -regtest in 0.8.5?  If it was, I should update the testnet-in-a-box README
302 2013-11-07 02:15:48 <BlueMatt> yes, it was
303 2013-11-07 02:15:49 <shamoon> that explains it
304 2013-11-07 02:15:54 <shamoon> i'm on .8.2.2
305 2013-11-07 02:15:58 <BlueMatt> gavinandresen: yes, you should
306 2013-11-07 02:16:00 <shamoon> that's why i don't have regtest
307 2013-11-07 02:16:05 <BlueMatt> I thought it was before then?
308 2013-11-07 02:16:11 <BlueMatt> well, I may be wrong
309 2013-11-07 02:16:14 <BlueMatt> maybe its only 0.9
310 2013-11-07 02:16:26 <gavinandresen> Yeah, I think it was added very soon after 0.8.mumble shipped
311 2013-11-07 02:16:29 <BlueMatt> 
ACTION -> paper writing

312 2013-11-07 02:16:54 <shamoon> found a block =)
313 2013-11-07 02:16:55 <shamoon> yaya!
314 2013-11-07 03:30:49 <BlueMatt> gavinandresen: ok, budget sent...sadly I didnt see any btc-accepting vps providers that were in cities with known-good peering and had good peering themselves, so I think ec2 is the way to go
315 2013-11-07 03:31:03 <BlueMatt> plus it has the advantage that existing ec2 customers get cheaper bw to/from it (I think?)
316 2013-11-07 03:31:22 <BlueMatt> well, and its cheaper on ec2
317 2013-11-07 03:32:33 <gavinandresen> BlueMatt: http://aws.amazon.com/ec2/pricing/#DataTransfer
318 2013-11-07 03:36:01 <BlueMatt> well, ok, cheaper than internet rate in any case
319 2013-11-07 03:36:31 <gavinandresen> yup
320 2013-11-07 03:36:54 <BlueMatt> anyway, should probably have cc'd the rest of the dev team on that email, if you want to forward
321 2013-11-07 03:37:12 <gavinandresen> Can you tweak it with an estimate of bandwidth costs?
322 2013-11-07 03:40:33 <BlueMatt> ehh, oops, Im too used to vps providers that dont charge for bw (or at least not hitting the caps)
323 2013-11-07 03:40:40 <BlueMatt> f'ing amazon is so expensive
324 2013-11-07 03:41:13 <gavinandresen> mmm.  Expensive but reliable.
325 2013-11-07 03:45:00 <BlueMatt> gavinandresen: there, better
326 2013-11-07 03:45:13 <gavinandresen> BlueMatt: awesome, thanks
327 2013-11-07 03:54:14 <phantomcircuit> BlueMatt, for the relay mesh?
328 2013-11-07 03:54:24 <BlueMatt> yea
329 2013-11-07 03:56:02 <Eneerge> test
330 2013-11-07 03:56:13 <Eneerge> heh if your nick contains a _, you're banned
331 2013-11-07 04:23:53 <radiator> Hi everyone. this question is for anybody interested. given that BTC guild recently mined 6 blocks in a row, could BTC guild insert their own fraudulent transactions into a block ?
332 2013-11-07 04:24:30 <Luke-Jr> of course
333 2013-11-07 04:25:29 <radiator> isn't this a problem for bitcoin ?
334 2013-11-07 04:25:37 <berndj> who would accept those blocks?
335 2013-11-07 04:25:55 <Luke-Jr> radiator: yes, encourage people to use pools that support decentralised mining
336 2013-11-07 04:27:56 <radiator> berndj when a client parses a block, does it verify every transaction in the block? i thought the veririfcation of transactions was only done by miners. please correct if i'm wrong. in any case, even if BTC Guild wasn't going to create new transactions, it could possible modify existing ones - right? including changing the tx value , timestamps , etc.
337 2013-11-07 04:28:21 <berndj> IANABD but yes i thought every (full) node should verify each transaction
338 2013-11-07 04:29:16 <berndj> i thought the transaction would be signed, and any change to the amount would invalidate the signature
339 2013-11-07 04:29:56 <radiator> hell the more i think about it…. if they can change the blockchain, they can really do anything. change inputs , outputs etc. it doesnt matter about the verification. waiting to be corrected by someone
340 2013-11-07 04:30:21 <Luke-Jr> well yeah, miners can't do totally bogus transactions
341 2013-11-07 04:30:29 <Luke-Jr> but they could double-spend
342 2013-11-07 04:30:40 <berndj> isn't that totally bogus?
343 2013-11-07 04:31:01 <berndj> or do you mean: confirm a double-spend wrt a tx stuck in the mempool
344 2013-11-07 04:46:36 <radiator> mining pools are bitcoins biggest weakness
345 2013-11-07 04:59:53 <BlueMatt> nice, despite all 4 relay nodes getting an inv from the same peer at the same time, three of them ended up getting the block faster from the first relay peer than from the node that sent the inv
346 2013-11-07 05:00:36 <BlueMatt> which is really just a race, but shows that the relay nodes are well-connected between each other
347 2013-11-07 05:03:52 <Luke-Jr> it would help if nodes sent blocks to multiple peers at the same time
348 2013-11-07 05:04:14 <Luke-Jr> last I checked, everything waited for Peer A (whoever requested it first) to get it entirely before anything else started
349 2013-11-07 05:04:20 <Luke-Jr> (and continued one by one)
350 2013-11-07 05:08:23 <BlueMatt> hmm? do we not send the invs sequentially? I mean its pretty much all net latency
351 2013-11-07 05:19:17 <Luke-Jr> BlueMatt: I mean we *could* be uploading the blocks to multiple peers at once for fast connections
352 2013-11-07 05:21:10 <BlueMatt> we essentially are
353 2013-11-07 05:21:22 <BlueMatt> we're filling net buffers sequentially, but...meh
354 2013-11-07 07:39:41 <topi`> does anyone have any insight into why intersango is not sending my BTC withdrawal request? and the status page says "Delayed".
355 2013-11-07 07:45:07 <topi`> maybe their bitcoind has suffered from corrupt blockchain and has to resync
356 2013-11-07 08:19:15 <radiator> topi`:  yeah intersango is dead . it is used as collateral for the bitcoinica creditors , your deposits there could be seized at any time - stay clear
357 2013-11-07 08:23:24 <gribble> There are currently 7272.7521 bitcoins offered at or under 400.0 USD, worth 2368309.60934 USD in total. | Data vintage: 187.8903 seconds
358 2013-11-07 08:23:24 <melvster> ;;asks 400
359 2013-11-07 08:23:31 <melvster> ;;asks 500
360 2013-11-07 08:23:32 <gribble> There are currently 8390.2046 bitcoins offered at or under 500.0 USD, worth 2882685.55728 USD in total. | Data vintage: 195.5697 seconds
361 2013-11-07 08:28:53 <melvster> ;;asks 500
362 2013-11-07 08:28:54 <gribble> There are currently 6875.768 bitcoins offered at or under 500.0 USD, worth 2431588.44893 USD in total. | Data vintage: 214.9100 seconds
363 2013-11-07 08:47:12 <gmaxwell> ;;ticker --high
364 2013-11-07 08:47:13 <gribble> 309.68000
365 2013-11-07 09:23:55 <HaltingState> I am starting work on my open source 32 bit arm hardware wallet https://dl.dropboxusercontent.com/u/21517274/img/IMG_4218.JPG
366 2013-11-07 09:24:01 <HaltingState> sipa, did you figure out the segfault?
367 2013-11-07 09:26:50 <HaltingState> i am going to try to compile your library for 32 bit arm now
368 2013-11-07 09:52:13 <t7> how big is that lip balm?
369 2013-11-07 09:55:22 <HaltingState> t7, like 2"
370 2013-11-07 09:55:24 <HaltingState> or 1.5"
371 2013-11-07 10:18:14 <HaltingState> gmaxwell, will you audit my hardware wallet when its done? https://dl.dropboxusercontent.com/u/21517274/img/IMG_4220.JPG
372 2013-11-07 10:23:48 <HaltingState> sipa, i am getting likesecp256k1 to compile for 32 bit arm
373 2013-11-07 10:36:02 <TD> HaltingState: ooh, you are?
374 2013-11-07 10:36:09 <TD> HaltingState: can you keep me informed as to how you get on?
375 2013-11-07 10:36:12 <TD> i'm very interested in such work
376 2013-11-07 10:41:30 <HaltingState> TD, ya; creating github repo
377 2013-11-07 10:41:44 <HaltingState> first thing is to get sha256 compiling and AES working on this microchip
378 2013-11-07 10:41:45 <TD> thanks. i'd like to get a version on android
379 2013-11-07 10:41:57 <TD> it shouldn't be that hard to compile, surely?
380 2013-11-07 10:42:01 <TD> it has pure C versions for everything
381 2013-11-07 10:42:07 <HaltingState> and then libsecp256k1 and then i am doing the dongle for the 2 factor auth and then setting up crypo
382 2013-11-07 10:42:21 <CodeShark> the sample code for sha256 in C works pretty much out the box
383 2013-11-07 10:42:38 <HaltingState> i would not do android; its insecure; this does not have kernel or OS that can be hacked
384 2013-11-07 10:42:48 <HaltingState> but you could do 2 factor auth as android app
385 2013-11-07 10:42:52 <CodeShark> dedicated hardware signing devices is the way to go
386 2013-11-07 10:43:08 <CodeShark> the rest of account administration can be implemented on devices running android or whatever
387 2013-11-07 10:43:13 <CodeShark> but signing should be a separate dedicated component
388 2013-11-07 10:43:18 <HaltingState> the point of this is that if your computer has trojan; no one can steal your bitcoin; the private keys never leave these device and it only commnucates over a serial cable
389 2013-11-07 10:43:32 <TD> like the trezor, ok
390 2013-11-07 10:43:36 <HaltingState> and its going to have ECC and AES cryto
391 2013-11-07 10:43:36 <TD> i just want faster signing on android :)
392 2013-11-07 10:44:04 <CodeShark> why do you need AES?
393 2013-11-07 10:44:14 <HaltingState> the difference between the trezor is that this is 2 factor auth; if someone steals your trezor they can get the bitcoin out; this the bitcoin is on server in a secure location and there is a dongle with keypad adn you have to put in pin to auth transaction
394 2013-11-07 10:44:35 <HaltingState> and even if dongle is stolen, your bitcoin are safe; even if dongle is stolen and your computer is rootkitted; no one is getting the bitcoins
395 2013-11-07 10:45:01 <HaltingState> and the server is "physically secure" its in a box and will nuke the keys if anyone opens the box
396 2013-11-07 10:45:35 <HaltingState> and its intiated using deterministic wallet so if you know master phrase you can recover the wallet even if it nukes itself to prevent someone from gaining physical access
397 2013-11-07 10:46:15 <HaltingState> CodeShark, the private keys and key data is AES encrypted on flash and the AES keys are in RAM; if anyone tries gaining access to server, its going to forget the AES keys so no one can steal the bitcoin
398 2013-11-07 10:46:33 <CodeShark> ok
399 2013-11-07 10:47:05 <HaltingState> i am expoxying board before it goes into box so no one can access the electrical contacts and its going into a faraday cage and the serial inputs/outputs are going to  be optically isolated to prevent side channel attacks
400 2013-11-07 10:47:40 <HaltingState> and i am using constant time cryto implementation whenever possible
401 2013-11-07 10:48:35 <CodeShark> sounds cool - please let me know the github url when you have it up
402 2013-11-07 10:48:35 <HaltingState> this is aimed at BCT-E and blochain.info and people that need military level security for their bitcoin private keys
403 2013-11-07 10:49:19 <HaltingState> i am wondering if should do trezor/kickstarter type thing once i get it working; beacuse i think alot of people need this, to keep their bitcoin safe
404 2013-11-07 10:50:45 <HaltingState> i need a cool name too, like "coin vault" or something that sounds secure
405 2013-11-07 11:01:09 <cazalla> bitcoinagotchi
406 2013-11-07 11:03:21 <t7> feed it or it dies... again
407 2013-11-07 11:03:55 <HaltingState> lol
408 2013-11-07 11:23:03 <HaltingState> blinking LED!! w00t https://dl.dropboxusercontent.com/u/21517274/img/IMG_4222.JPG
409 2013-11-07 11:25:05 <HaltingState> o0o0 its making a 1 Khz tone now; lol i can make it sing your bitcoin addresses
410 2013-11-07 11:26:00 <t7> sweet, and receive over micc
411 2013-11-07 11:27:10 <bitnumus> android bitcoin wallet doesn't support bitcoin URI ?
412 2013-11-07 11:27:20 <HaltingState> there is program for the mic thing, for linux you can apptget
413 2013-11-07 11:27:22 <t7> HaltingState: if you wanted to produce these you would have to buy these arduino due boards at £40 each time?
414 2013-11-07 11:27:28 <HaltingState> and it will take a file and sing it over the speakers
415 2013-11-07 11:27:42 <wumpus> bitnumus: sure it does, it was the first client to support them AFAIK
416 2013-11-07 11:28:11 <HaltingState> t7, i can put a  1 GB memory stick, or 8 GB microSSD stick and have multiple users on the wallet with different keys and it could be cheap as hell ($10 /month?)
417 2013-11-07 11:28:16 <HaltingState> each user needs a dongle
418 2013-11-07 11:28:22 <bitnumus> wumpus, so when i send a bitcoi URI over NFC, why doesn't it look for it ?
419 2013-11-07 11:28:23 <HaltingState> and for high security some users might want their own server
420 2013-11-07 11:28:59 <HaltingState> and its not just the board; there is power equipment to electrical isolate it and epoxy on board and physical security/hosting
421 2013-11-07 11:29:06 <wumpus> bitnumus: I don't know -- NFC should certainly be supported. With bitcoin wallet you mean Schildbach's I suppose?
422 2013-11-07 11:29:28 <bitnumus> yea ^
423 2013-11-07 11:29:32 <HaltingState> NFC would be something the dongle could support, but this is something that would sit in a cage in a vault
424 2013-11-07 11:29:39 <bitnumus> i thought it should give me the option to open it
425 2013-11-07 11:29:50 <HaltingState> and then the dongle is needed to authenicate the transactions but would never touch the keys
426 2013-11-07 11:30:02 <bitnumus> HaltingState, not sure what you are talking about or if its related to what i am
427 2013-11-07 11:30:02 <wumpus> bitnumus: I'd think so too
428 2013-11-07 11:30:38 <bitnumus> i'm beaming a link
429 2013-11-07 11:30:39 <TD> that should work
430 2013-11-07 11:30:43 <bitnumus> bitcoin:address
431 2013-11-07 11:30:47 <HaltingState> bitnumus, answering t7
432 2013-11-07 11:30:49 <TD> i've used nfc a bunch of times
433 2013-11-07 11:30:59 <TD> you have to make sure that your NFC tag is exposing the URI in the right way though
434 2013-11-07 11:31:02 <TD> tag writer apps do the trick
435 2013-11-07 11:31:12 <bitnumus> i'm using a SCL3711
436 2013-11-07 11:31:14 <bitnumus> and nfcpy
437 2013-11-07 11:31:47 <TD> ok, then you'll have to debug it. the android app responds to the tags when they have the right mime type, nfc tag type etc
438 2013-11-07 11:31:53 <TD> so look at the source code to see what it's looking for
439 2013-11-07 11:32:07 <bitnumus> its popping up with NFC tag app
440 2013-11-07 11:32:41 <bitnumus> hmm, ok i'll look into it a bit more
441 2013-11-07 11:34:58 <TD> great. if there's a bug in the android app we should just get it fixed
442 2013-11-07 11:39:40 <bitnumus> TD any ideas to debug
443 2013-11-07 11:39:42 <bitnumus> ?
444 2013-11-07 11:39:47 <bitnumus> URLs etc work fine
445 2013-11-07 11:39:49 <bitnumus> bitcoin: doesn't work
446 2013-11-07 11:39:49 <TD> look at adb logcat on your phone
447 2013-11-07 11:39:54 <TD> so you can see debug output from the apps
448 2013-11-07 11:40:03 <bitnumus> i don't know what you mean
449 2013-11-07 11:40:15 <bitnumus> no app is recognising it, thats the point
450 2013-11-07 11:41:41 <bitnumus> i have a tag reader, if i open with that it says 'unknown tag type'
451 2013-11-07 11:46:51 <TD> hmm
452 2013-11-07 11:46:59 <TD> then i guess there's some issue with nfcpy or the way you're using it ?
453 2013-11-07 11:47:03 <bitnumus> its an NFC issue for sure
454 2013-11-07 12:44:46 <ikbenwouter> anyone know what's going on with the conf time spike?
455 2013-11-07 12:44:48 <ikbenwouter> http://blockchain.info/charts/avg-confirmation-time
456 2013-11-07 12:45:20 <lianj> retarget?
457 2013-11-07 12:46:33 <ikbenwouter> I hear people compaining about slow first confs for their tx'es and found the spike
458 2013-11-07 13:13:18 <TD> ikbenwouter: not sure what's up with that. seems like it's coming down now though
459 2013-11-07 13:13:24 <TD> we really really need better monitoring
460 2013-11-07 13:14:04 <TD> but yeah seems to be retarget related
461 2013-11-07 13:18:15 <phantomcircuit> TD, gox had a ton of txs they had to dump
462 2013-11-07 13:18:29 <TD> hm?
463 2013-11-07 13:18:41 <phantomcircuit> the avg confirmation time
464 2013-11-07 13:18:43 <TD> ah
465 2013-11-07 13:18:47 <TD> you think they evicted everyone
466 2013-11-07 13:18:53 <phantomcircuit> they had a bunch of txs that didn't make it to the network
467 2013-11-07 13:19:05 <phantomcircuit> and then all of a sudden thousands of them
468 2013-11-07 13:19:16 <TD> i see
469 2013-11-07 13:19:25 <TD> possibly they fixed the maturity bug or something
470 2013-11-07 13:19:34 <TD> i really wish we had a long-term graph of size per block
471 2013-11-07 13:19:41 <TD> long+short term
472 2013-11-07 13:19:46 <gulli> hmm, to me it seems that Bitstamp is not using a cold storage
473 2013-11-07 13:20:04 <gulli> if you withdraw from the exchange it comes straight away
474 2013-11-07 13:20:38 <TD> cold storage just means they minimize the size of their hot wallet
475 2013-11-07 13:20:40 <K1773R> gulli: so? that dosnt mean that the spare funds arent in cold storage...
476 2013-11-07 13:20:41 <TD> it doesn't mean all coins are offline
477 2013-11-07 13:23:01 <ikbenwouter> phantomcircuit, makes sense, thanks for this explanation
478 2013-11-07 13:24:17 <gulli> spare funds mean nothing, if everyones private keys are in the hot wallet and it gets compramised they are never going to be able to pay everyone off
479 2013-11-07 13:24:46 <gulli> i.e. https://news.ycombinator.com/item?id=6687795
480 2013-11-07 13:27:49 <sipa> gulli: the point is that there is no "someone's private key"
481 2013-11-07 13:28:04 <sipa> gulli: they just maintain a hot wallet with some keys, and a cold wallet with other keys
482 2013-11-07 13:28:14 <sipa> and track how much belongs to each customer
483 2013-11-07 13:28:23 <sipa> rather than keeping specific keys for each customer
484 2013-11-07 13:29:13 <gulli> hmm ok
485 2013-11-07 13:30:38 <gulli> im trying to figure out which is a better approach, make specific addresses tied to a user or not.
486 2013-11-07 13:31:26 <sipa> you have specific addresses, for which spends TO them credit a specific customer
487 2013-11-07 13:32:15 <sipa> but you don't use the amount of coins assigned to those addresses to track balances
488 2013-11-07 13:32:29 <sipa> just keep a database entry that gets incremented when a payment to a particular user confirms
489 2013-11-07 13:32:51 <sipa> then you're free to move funds between cold and hot wallets as needed, without impacting balances
490 2013-11-07 13:32:52 <gulli> I didnt get the first sentence, they generate specific addresses for the user to send them bitcoin
491 2013-11-07 13:33:02 <sipa> "they" ?
492 2013-11-07 13:33:10 <gulli> bitstamp
493 2013-11-07 13:33:26 <sipa> yes
494 2013-11-07 13:33:42 <sipa> so they tie that address to a particular user
495 2013-11-07 13:33:53 <sipa> and whenever coins arrive at that address, they credit that user's account
496 2013-11-07 13:34:03 <sipa> but afterwards, the coins can move
497 2013-11-07 13:34:11 <sipa> inside their system
498 2013-11-07 13:34:21 <sipa> (at least, that's what i'd hope they do)
499 2013-11-07 13:34:28 <gulli> ok thanks, it makes sence
500 2013-11-07 13:53:52 <gulli> Bitstamp is most likely using armory, right?
501 2013-11-07 13:57:18 <petertodd> re: inputs.io - got 1.16BTC back on ~1.7BTC deposit. Not half bad - seems that the current batch of off-chain guys are learning their lessons re: user-auth and cold storage. I wonder how long it'll take until they finally start getting into trusted computing w/ remote attestation?
502 2013-11-07 13:57:23 <petertodd> That's what it's going to take...
503 2013-11-07 13:59:12 <Happzz> in order to use the testnet, i need the same bitcoind, right?
504 2013-11-07 14:03:18 <stonecoldpat0> they need typrwriters
505 2013-11-07 14:03:22 <stonecoldpat0> best protection you can have
506 2013-11-07 14:21:56 <TD> petertodd: or just not existing ....
507 2013-11-07 14:28:36 <helo> figuring out the security practices that actually work for these services would benefit everyone
508 2013-11-07 14:29:44 <helo> as much as it sucks for the people whose funds are stolen
509 2013-11-07 14:35:21 <TD> the best security practice is to not give your bitcoins to other people
510 2013-11-07 14:35:23 <TD> local wallets all the way
511 2013-11-07 14:36:30 <diki> TD:Yes, let's all hoard our bitcoins and die without ever using them.
512 2013-11-07 14:36:45 <TD> you know what i meant :)
513 2013-11-07 14:46:15 <Eliel> interesting... bitcoind made a 5kb transaction with no fee at all. I thought all transactions above certain size limit would get a fee no matter what.
514 2013-11-07 14:46:46 <sipa> Eliel: really? what version?
515 2013-11-07 14:47:03 <Eliel>     "version" : 80500,
516 2013-11-07 14:47:12 <sipa> can i have the txid?
517 2013-11-07 14:47:28 <Eliel> I /msgd you the txid
518 2013-11-07 14:49:32 <sipa> Eliel: up to 26 kB can be free, apparently
519 2013-11-07 14:50:33 <Eliel> I guess the limit's been increased. I'd better configure bitcoind to always include a fee.
520 2013-11-07 14:51:07 <Eliel> earlier I figured it wouldn't be necessary since we only make rather big ones
521 2013-11-07 14:51:49 <sipa> TD: i remember we tried to figure out what bitcoind versions c' decker's paper used data from for their propagation speed measurements
522 2013-11-07 14:51:52 <sipa> TD: do you?
523 2013-11-07 14:52:01 <TD> no, but you said it was pre-0.8
524 2013-11-07 14:52:21 <diki> estimat
525 2013-11-07 14:52:22 <diki> estimate
526 2013-11-07 14:52:34 <diki> come on faster gribble
527 2013-11-07 14:52:48 <diki> bc,estimate
528 2013-11-07 14:52:51 <sipa> TD: apparently block 180000-190000
529 2013-11-07 14:53:19 <sipa> so until juli 2012
530 2013-11-07 14:53:52 <sipa> which means at most 0.6.3
531 2013-11-07 14:54:08 <TD> yes
532 2013-11-07 15:00:05 <HaltingState> bitcoin hardware wallet progress https://dl.dropboxusercontent.com/u/21517274/img/IMG_4226.JPG
533 2013-11-07 15:01:19 <Eliel> sipa: did 0.8.5 support adding a fee to a pre-existing transaction in any way yet?
534 2013-11-07 15:03:49 <sipa> Eliel: no, that's impossible
535 2013-11-07 15:04:10 <sipa> the best you can do is create a conflicting transaction that double-spends the first
536 2013-11-07 15:05:23 <sipa> transaction replacement under certain conditions could allow that
537 2013-11-07 15:05:47 <sipa> but that's disabled for now
538 2013-11-07 15:05:51 <HaltingState> sipa, ^^
539 2013-11-07 15:05:57 <HaltingState> i am getting your library to compile on arm
540 2013-11-07 15:06:05 <HaltingState> for my hardware wallet
541 2013-11-07 15:06:36 <sipa> cool
542 2013-11-07 15:06:44 <sipa> HaltingState: haven't looked at the segfault
543 2013-11-07 15:06:51 <HaltingState> sipa, https://dl.dropboxusercontent.com/u/21517274/img/IMG_4226.JPG
544 2013-11-07 15:12:34 <Eliel> sipa: aren't there some pools already that prioritize transactions also based on the fees of transactions that depend on them?
545 2013-11-07 15:13:21 <sipa> Eliel: yes, but that's not relevant
546 2013-11-07 15:13:31 <sipa> you still need to be able to replace an older transaction
547 2013-11-07 15:13:42 <sipa> prioritization is about what enters a block
548 2013-11-07 15:13:46 <sipa> not what enters the mempool
549 2013-11-07 15:14:41 <sipa> petertodd's been working on a mempool that does allow that, under certain conditions
550 2013-11-07 15:15:34 <Eliel> sipa: what I mean is, if I figure out which of the outputs is the change output and spend that with big enough fee for both itself and this 0-fee transaction, aren't there some pools that would then prioritize this first transactions due to the big fee in the followup tx?
551 2013-11-07 15:15:52 <sipa> Eliel: oh, yes
552 2013-11-07 15:15:57 <sipa> Eliel: sorry, i didn't make the connection
553 2013-11-07 15:16:04 <sipa> i believe eligius does that indeed
554 2013-11-07 15:16:50 <Eliel> only eligius? rather slim hope in that case but I guess still worth trying.
555 2013-11-07 15:19:03 <imton> hi guys
556 2013-11-07 15:19:04 <petertodd> Eliel: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03126.html <- tx-replacement to bump fees
557 2013-11-07 15:19:16 <imton> I am trying to compile bitcoin in ubuntu 13
558 2013-11-07 15:19:25 <firedrops> who has the best gold for btc service?
559 2013-11-07 15:19:48 <petertodd> Eliel: eligius and one other pool, I forget which, do "child-pays-for-parent" fee evaluation. However we need to also change the way transactions are relayed to really make it useful.
560 2013-11-07 15:19:50 <imton> I getting Berkeley DB and Boost lib probelms
561 2013-11-07 15:19:53 <imton> *problems
562 2013-11-07 15:33:06 <firedrops> GOLD - DO YOU SELL IT!
563 2013-11-07 15:33:08 <firedrops> ?
564 2013-11-07 15:33:12 <firedrops> for btc?
565 2013-11-07 15:33:29 <sipa> firedrops: see #bitcoin or #bitcoin-otc, not here
566 2013-11-07 15:33:35 <pigeons> firedrops: the is -dev, try #bitcoin-otc
567 2013-11-07 15:33:44 <firedrops> crappers, wrong chan, my bad guys.
568 2013-11-07 15:33:50 <firedrops> 
ACTION smacks himself.

569 2013-11-07 15:34:15 <imton> guys, any idea how can I compile under Ubuntu 13 without getting BDB and Boost lib errors?
570 2013-11-07 15:34:35 <sipa> imton: by installing the dependencies
571 2013-11-07 15:34:53 <imton> sipa: yeah, I did that :)
572 2013-11-07 15:34:54 <imton> didn't work
573 2013-11-07 15:35:14 <sipa> which version of the client, and which ubuntu version?
574 2013-11-07 15:35:26 <sipa> there is known issues with git head under 13.10
575 2013-11-07 15:36:07 <sipa> bdb should be fine if you either install a 4.8 backport, or use --with-incompatible-bdb
576 2013-11-07 15:36:17 <sipa> boost needs a manual install of 1.53 or 1.54
577 2013-11-07 15:36:23 <imton> sipa: I am trying to merge current master bitcoin with your watch only branch and compile it
578 2013-11-07 15:36:55 <imton> I can't get to install boost properly.
579 2013-11-07 15:37:16 <imton> checking whether the Boost::System library is available... yes
580 2013-11-07 15:37:16 <imton> this is the boost error
581 2013-11-07 15:37:17 <imton> configure: error: Could not find a version of the library!
582 2013-11-07 15:38:28 <imton> I have libboost1.53-dev
583 2013-11-07 15:38:29 <imton> installed
584 2013-11-07 15:43:18 <sipa> imton: you'll need to install the specific boost libraries
585 2013-11-07 15:43:51 <imton> sipa: may i know how? I even tried to manually compile boost and it failed
586 2013-11-07 15:43:58 <sipa> no need for that
587 2013-11-07 15:44:29 <sipa> just install libboost-system1.53-dev for example
588 2013-11-07 15:44:43 <MiningBuddy> test
589 2013-11-07 15:44:50 <sipa> but you'll need more than just that one
590 2013-11-07 15:46:13 <imton> sipa: should boost install libraries in /usr/lib ?
591 2013-11-07 15:46:20 <imton> because it doesn't add anything there to me
592 2013-11-07 15:46:20 <sipa> yes
593 2013-11-07 15:46:37 <sipa> use dpkg -L <package> to see what it installs
594 2013-11-07 15:47:00 <imton> sipa: ok
595 2013-11-07 15:47:41 <Eliel> ok, I've got a rawtransaction made that should have enough fee. The only problem is, how do I check that? Are there any tools for checking how big of a fee a transaction has before broadcasting it?
596 2013-11-07 15:48:16 <sipa> Eliel: i don't think so, and that does sound useful
597 2013-11-07 15:48:34 <sipa> i wonder whether a checkrawtransaction rpc would make sense to query such things
598 2013-11-07 15:49:08 <Eliel> if you ask me, decoderawtransaction should do it.
599 2013-11-07 15:49:21 <sipa> i don't think so
600 2013-11-07 15:49:25 <sipa> it's not a decoding issue
601 2013-11-07 15:49:33 <sipa> as it requires checking against the UTXO set
602 2013-11-07 15:49:49 <sipa> which will only work for unsubmitted transactions
603 2013-11-07 15:50:32 <sipa> i'd prefer decoderawtransaction to remain a pure rpc call, which doesn't depend on a functional node
604 2013-11-07 15:52:17 <Eliel> maybe something like analyzerawtransaction then.
605 2013-11-07 15:52:31 <Eliel> check is a bit vague
606 2013-11-07 15:52:52 <imton> sipa: let's start by asking, is this error only shown for boost?  "configure: error: Could not find a version of the library!"
607 2013-11-07 15:53:09 <imton> sipa: may be it is not boost what is going on wrong with me
608 2013-11-07 15:53:21 <sipa> are you on 13.10?
609 2013-11-07 15:54:19 <imton> sipa: yes
610 2013-11-07 15:54:31 <sipa> then it's likely a boost issue
611 2013-11-07 15:54:54 <imton> ok, which version should I downgrade to/
612 2013-11-07 15:54:56 <imton> ?
613 2013-11-07 15:54:56 <sipa> i don't know the details, but someone figured out that you need to install some extra boost packages on 13.10 to make it work
614 2013-11-07 15:55:00 <sipa> sorry, no idea
615 2013-11-07 15:55:09 <imton> 13.04? 12?
616 2013-11-07 15:55:18 <sipa> oh, ubuntu
617 2013-11-07 15:55:20 <sipa> 13.04 will work
618 2013-11-07 15:55:23 <imton> :)
619 2013-11-07 15:55:30 <sipa> 13.10 also works if you install the right packages
620 2013-11-07 15:55:38 <sipa> if you search through the issues list, you may find it
621 2013-11-07 15:55:56 <imton> sipa: great. will find out now
622 2013-11-07 15:56:54 <sipa>  libboost-{system,filesystem,chrono,program-options,thread,test}1.54{-dev,.0}
623 2013-11-07 15:57:01 <sipa> you need to install those
624 2013-11-07 15:57:05 <sipa> on 13.10
625 2013-11-07 15:58:36 <imton> 1.53 will work?
626 2013-11-07 15:59:05 <sipa> i don't know
627 2013-11-07 15:59:12 <sipa> i'm just reporting what someone else found out
628 2013-11-07 15:59:24 <imton> ok. "libboost-all-dev" is installing me 1.53
629 2013-11-07 15:59:44 <sipa> then that's probably not going to work
630 2013-11-07 15:59:52 <imton> may i know here you find this info? i didn't find anything
631 2013-11-07 15:59:59 <sipa> in irc logs
632 2013-11-07 16:00:05 <imton> oh :) smart
633 2013-11-07 16:09:08 <Eliel> hmmh, local bitcoind appears to have accepted the transaction but it's not showing up on blockchain.info. Looks like I managed to get the fee right though.
634 2013-11-07 16:10:04 <Eliel> hopefully the transaction get broadcasted and isn't just stuck in the local bitcoind only.
635 2013-11-07 16:10:51 <imton> sipa: that line made it work! now it read boost. It seems by default is installing 1.53 which isn't compatible with ubuntu 13.10, 1.54 seems fine
636 2013-11-07 16:11:18 <imton> sipa: thank yuo
637 2013-11-07 16:11:20 <imton> *you
638 2013-11-07 16:14:45 <gulli> SO do you think bitstamp and mtgox use Armory or some inhouse solution?
639 2013-11-07 16:15:03 <sipa> imton: https://github.com/bitcoin/bitcoin/issues/3219
640 2013-11-07 16:16:29 <imton> sipa: awesome!
641 2013-11-07 16:20:42 <dooglus_> I have a strange issue
642 2013-11-07 16:21:16 <dooglus_> I sent a transaction using bitcoind, got a txid back, the transaction confirmed, but 'getrawtransaction' tells me error: {"code":-5,"message":"No information available about transaction"}
643 2013-11-07 16:21:40 <Eliel> it worked! :)
644 2013-11-07 16:21:44 <dooglus_> $ bitcoind getrawtransaction 4e558bcab9977ec9e049a24b3c3f27a76882488ec5b24866939a7463200ebb48
645 2013-11-07 16:21:47 <dooglus_> error: {"code":-5,"message":"No information available about transaction"}
646 2013-11-07 16:22:27 <dooglus_> but http://blockchain.info/block-index/438480/0000000000000001e3d17a69bfdc1f3a8451ec48652aa7561156f0b22a16fc13 shows the tx
647 2013-11-07 16:22:49 <dooglus_> and my bitcoind has that block!:
648 2013-11-07 16:22:50 <dooglus_> $ bitcoind getblockhash 268416
649 2013-11-07 16:22:52 <dooglus_> 0000000000000001e3d17a69bfdc1f3a8451ec48652aa7561156f0b22a16fc13
650 2013-11-07 16:22:57 <dooglus_> so wtf?
651 2013-11-07 16:24:47 <sipa> dooglus_: do you have a transaction index enabled?
652 2013-11-07 16:28:09 <dooglus_> sipa: I didn't explicitly do so - but the bitcoind that can't find the tx created the tx...
653 2013-11-07 16:28:25 <sipa> dooglus_: gettransaction queries the wallet, and will find it
654 2013-11-07 16:28:39 <sipa> getrawtransaction queries the blockchain database, and without txindex, it won't find anything
655 2013-11-07 16:28:48 <dooglus_> I've never had getrawtransaction fail before
656 2013-11-07 16:29:16 <sipa> it works for transactions whose outputs aren't spent yet (they can be found in the UTXO set, which always exists)
657 2013-11-07 16:30:13 <dooglus_> aah
658 2013-11-07 16:30:30 <dooglus_> funny that I've never seen this issue before - I've run getrawtransaction hundreds of times
659 2013-11-07 16:30:35 <sipa> dooglus_: https://github.com/bitcoin/bitcoin/issues/3220
660 2013-11-07 16:31:00 <dooglus_> so can I get the raw transaction somehow without turning on the tx index?
661 2013-11-07 16:31:31 <dooglus_> sipa: https://github.com/bitcoin/bitcoin/issues/3221
662 2013-11-07 16:31:42 <dooglus_> maybe close it, or link to 3220?
663 2013-11-07 16:32:25 <sipa> dooglus_: there is no way to query the wallet for a raw transaction afaik; i've added that as an extra goal to 3220
664 2013-11-07 16:32:33 <sipa> i agree that should be possible, and without txindex
665 2013-11-07 16:33:13 <dooglus_> is it expensive to turn the txindex on?
666 2013-11-07 16:33:39 <sipa> turning it on is expensive (you need to reindex)
667 2013-11-07 16:33:51 <sipa> maintaining it not so much (it adds a database of about 1 GB)
668 2013-11-07 16:34:17 <dooglus_> ok.  I guess the reason I never saw this before is because I usually only want the rawtx for unconfirmed transactions
669 2013-11-07 16:34:25 <dooglus_> which will have unspent outputs
670 2013-11-07 16:35:37 <dooglus_> thanks for your help - I was worried there for a minute