1 2013-03-03 00:00:05 <HM> Hmm
2 2013-03-03 00:02:40 <fatAgnes> i will google
3 2013-03-03 00:06:02 <Quazgaa> is there a webpage or something for the ignorant layman that describes what the info bfgminer displays actually means
4 2013-03-03 00:18:19 <fatAgnes> lol
5 2013-03-03 00:18:50 <fatAgnes> how do i feed bfgminer data?
6 2013-03-03 00:21:48 <sipa> what data do you want to feed it?
7 2013-03-03 00:22:19 <HM> reading that hardfork wishlist is great
8 2013-03-03 00:32:25 <aethero> Question: How are the devs planning to handle the hardfork that is going to be required to change the block size limit?
9 2013-03-03 00:33:20 <HM> from what i'm gleaning, the idea will be to break it hard
10 2013-03-03 00:33:37 <HM> e.g. make several invasive changes at once
11 2013-03-03 00:34:06 <HM> https://en.bitcoin.it/wiki/Hardfork_Wishlist
12 2013-03-03 00:34:11 <Luke-Jr> aethero: by doing it at least 2 years before it takes effect
13 2013-03-03 00:34:24 <aethero> Luke-Jr can you clarify that statement?
14 2013-03-03 00:34:25 <Luke-Jr> and yes, ideally with as many improvements at once as possible
15 2013-03-03 00:34:44 <Luke-Jr> aethero: eg, if we released 0.9.0 with a hardfork tomorrow, it wouldn't be active until 2 years from now
16 2013-03-03 00:34:52 <aethero> Ahh
17 2013-03-03 00:34:56 <aethero> So everyone can switch over seamlessly
18 2013-03-03 00:35:04 <sipa> a hardfork requires every full node in the network to upgrade
19 2013-03-03 00:35:10 <Luke-Jr> the assumption being everyone is using 0.9.0 or newer in 2 years
20 2013-03-03 00:35:34 <sipa> so it requires both widespread consensus, and a lot of time for deployment and safety
21 2013-03-03 00:36:01 <Luke-Jr> I'm not sure we have the manpower to pull off a successful hardfork right now, considering present adoption
22 2013-03-03 00:36:52 <aethero> How far away do you envision a hardfork to be?
23 2013-03-03 00:37:05 <aethero> Given the practically exponential growth in adoption lately.
24 2013-03-03 00:37:05 <HM> it's an interesting problem
25 2013-03-03 00:37:23 <HM> during periods of relative stability people tend to let their software get old and forget about it
26 2013-03-03 00:37:26 <sipa> exponential growth in microtransactions that can easily happen off chain
27 2013-03-03 00:37:47 <phantomcircuit> " Navel gazing / Protocol housekeeping"
28 2013-03-03 00:37:48 <phantomcircuit> lold
29 2013-03-03 00:38:07 <Luke-Jr> aethero: nobody's even started working on one, so probably at least a year (before the 2 year wait)
30 2013-03-03 00:38:36 <aethero> Luke-Jr Can you explain timejacking?
31 2013-03-03 00:38:42 <Luke-Jr> aethero: plus, there's no real need anytime soon
32 2013-03-03 00:38:43 <aethero> I've never heard that before reading the wishlist
33 2013-03-03 00:38:51 <Luke-Jr> aethero: it's not easy to explain
34 2013-03-03 00:39:22 <sipa> aethero: it's a particular and mostly theoretic weakness in how bitcoin calculates the difficulty
35 2013-03-03 00:39:38 <sipa> that could be exploited by a very expensive attack to keep difficupty down
36 2013-03-03 00:40:15 <sipa> it's trivial to fix, but can't be done without hardfork
37 2013-03-03 00:40:59 <gmaxwell> sipa: it can be soft-fork patched.
38 2013-03-03 00:41:10 <sipa> oh, ok
39 2013-03-03 00:43:39 <HM> ACTION is reading about Chaum tokens
40 2013-03-03 00:53:28 <HM> the coin flip behind the menu thing is genius
41 2013-03-03 00:53:48 <HM> so simple
42 2013-03-03 00:54:51 <phantomcircuit> sipa, it's mostly just a minor nuisance
43 2013-03-03 00:54:55 <phantomcircuit> get it
44 2013-03-03 00:54:57 <phantomcircuit> minor
45 2013-03-03 00:55:01 <phantomcircuit> ACTION lols
46 2013-03-03 00:55:49 <sipa> bitcoin: mining our own business since 2009
47 2013-03-03 00:58:57 <etotheipi_> hey, if Bitcoin-Qt no longer keeps an arbitrary txid->tx lookup (by default), then how does it know the transaction fees of incoming tx?
48 2013-03-03 01:00:08 <gmaxwell> etotheipi_: incoming transactions spend unspent coins???
49 2013-03-03 01:00:19 <etotheipi_> ooh, UTXO set
50 2013-03-03 01:00:54 <etotheipi_> duh
51 2013-03-03 01:02:18 <etotheipi_> so if a peer requests a tx, and it's not available... we just ignore the request?
52 2013-03-03 01:02:41 <etotheipi_> but we still know where the blocks are on disk, so we can still serve blocks... correct?
53 2013-03-03 01:02:54 <gmaxwell> sipa: though I've never figured out _which_ soft forking rule blocks the timewarp with a minimum of impact on non-timewarp sequences.
54 2013-03-03 01:03:03 <gmaxwell> etotheipi_: sure.
55 2013-03-03 01:03:56 <etotheipi_> gmaxwell: I'm wondering what Bitcoin-Qt does for gettx and getblock requests... am I right that it will ignore gettx requests for most tx (since it doesn't store the index anymore), but it can still handle any getblocks request...?
56 2013-03-03 01:04:25 <gmaxwell> etotheipi_: we never servered random historical txn. IIRC.
57 2013-03-03 01:04:29 <etotheipi_> err... I shouldn't say "most tx", if it's not a tx with a UTXO
58 2013-03-03 01:04:30 <gmaxwell> er served.
59 2013-03-03 01:04:43 <sipa> indeed
60 2013-03-03 01:05:03 <etotheipi_> gmaxwell: so the client did/does just ignore gettx requests that are ... not... ?
61 2013-03-03 01:05:09 <gmaxwell> etotheipi_: the changes in 0.8 are not externally visible. IIRC.
62 2013-03-03 01:05:12 <gmaxwell> etotheipi_: in the mempool.
63 2013-03-03 01:05:44 <etotheipi_> oh, if it's not in the mempool, it's because it made it into a block, and then we will serve the block instead
64 2013-03-03 01:06:08 <gmaxwell> Instead?
65 2013-03-03 01:06:16 <etotheipi_> (I mean, will serve it if requested...)
66 2013-03-03 01:06:22 <gmaxwell> Right.
67 2013-03-03 01:06:44 <sipa> etotheipi_: up to recent versions, you could only request transactions from the relay pool
68 2013-03-03 01:06:46 <etotheipi_> I'm just clarifying, if you send an inv for a tx in the mempool, then it ends up in a block, someone sends gettx, bitcoind ignores it
69 2013-03-03 01:07:02 <etotheipi_> but that node will then be notified of the new block and just request that later
70 2013-03-03 01:07:02 <sipa> since the mempool command, also those from the mempool
71 2013-03-03 01:07:31 <sipa> the relay pool always contains all recently relayed transactions
72 2013-03-03 01:07:41 <sipa> whether they are already in a block or not
73 2013-03-03 01:07:46 <etotheipi_> sipa: thanks
74 2013-03-03 01:08:01 <sipa> and indeed, never from historical blocks
75 2013-03-03 01:08:04 <etotheipi_> but through RPC I can request anything that's available
76 2013-03-03 01:08:08 <etotheipi_> ?
77 2013-03-03 01:08:08 <sipa> i think intentionally
78 2013-03-03 01:08:24 <sipa> if you have a txindex, you can request any tx
79 2013-03-03 01:08:36 <sipa> otherwise only those not yet fully spent
80 2013-03-03 01:08:43 <etotheipi_> gotcha, thanks
81 2013-03-03 01:08:50 <fatAgnes> bitcoind is a miner?
82 2013-03-03 01:08:54 <sipa> no
83 2013-03-03 01:10:08 <fatAgnes> what is it?
84 2013-03-03 01:11:01 <sipa> it is the reference client
85 2013-03-03 01:11:10 <sipa> a fully verifying bitcoun node
86 2013-03-03 01:11:23 <fatAgnes> ah
87 2013-03-03 01:11:26 <sipa> the same as Bitcoun-Qt, but without the GUI
88 2013-03-03 01:11:35 <sipa> *coIn
89 2013-03-03 01:11:46 <fatAgnes> i do i get a miner up and running?
90 2013-03-03 01:12:04 <sipa> what hardware do you have to mine with?
91 2013-03-03 01:13:17 <fatAgnes> gpu nvidea
92 2013-03-03 01:13:31 <fatAgnes> dualcore p4
93 2013-03-03 01:13:31 <sipa> then don't
94 2013-03-03 01:14:06 <fatAgnes> why?
95 2013-03-03 01:14:16 <sipa> it'll cost you more in electricity and hardware damage than it will gain you
96 2013-03-03 01:14:42 <fatAgnes> thats not an answer to my question
97 2013-03-03 01:14:53 <sipa> and for further questions: #bitcoin and #bitcoin-mining
98 2013-03-03 01:15:05 <fatAgnes> ah good
99 2013-03-03 02:16:31 <muhoo> ;;ticker
100 2013-03-03 02:16:32 <gribble> BTCUSD ticker | Best bid: 34.00001, Best ask: 34.19672, Bid-ask spread: 0.19671, Last trade: 34.15438, 24 hour volume: 13206.70894839, 24 hour low: 33.57100, 24 hour high: 34.59880, 24 hour vwap: 34.04977
101 2013-03-03 03:24:46 <etotheipi_> ugh... anyone know how to do a direct-download of Bitcoin-Qt from the sourceforge site? all links I can take you to the download page that downloads it after 5 seconds
102 2013-03-03 03:35:36 <etotheipi_> gmaxwell, Luke-Jr: do you have a recommendation for downloading the installer and running it for the user? I want to have a thing that says "You need Bitcoin-Qt, here's a link or download it, or click here to download and install automatically"
103 2013-03-03 03:38:09 <etotheipi_> first of all, I need a direct download to do that... Luke-Jr gave me the RSS feed, but I don't think I should be trusting an RSS feed for the correct links... should I?
104 2013-03-03 03:38:48 <gmaxwell> you should check the signatures, perhaps.
105 2013-03-03 03:38:59 <etotheipi_> gmaxwell: I was going to do that
106 2013-03-03 03:38:59 <Luke-Jr> etotheipi_: check for at least 3 known signatures
107 2013-03-03 03:39:09 <etotheipi_> oh well that answers the question then
108 2013-03-03 03:39:11 <Luke-Jr> or maybe at least 2
109 2013-03-03 03:39:25 <etotheipi_> duh, that's what the signatures are for
110 2013-03-03 03:39:42 <Luke-Jr> etotheipi_: or 2 + your own, and add your sig to them ;O)
111 2013-03-03 03:40:08 <etotheipi_> nah, I don't want to be tied in anyway to the Bitcoin-Qt/bitcoind release schedule
112 2013-03-03 03:40:39 <etotheipi_> if there's a security update, I don't want to have to be rushing to do <whatever> in order for my users to get the new version
113 2013-03-03 03:40:47 <etotheipi_> it's also why I don't want to just bundle it with Armory
114 2013-03-03 03:44:24 <etotheipi_> gah... looks like it's going to be complicated to verify the signatures in Windows... I assume they are GPG signatures?
115 2013-03-03 03:45:25 <etotheipi_> any reasonable way to do it without having the user install GPG4Win (or whatever the available options are for Windows)?
116 2013-03-03 04:26:47 <DarkGhost`> Hello, I'm using bitcoind and I'm trying to send money to an address using sendtoaddress <address> .0001 but it tells me I need a txfee of .005 even when I change it to .00001 or .000001 it still sends
117 2013-03-03 05:01:05 <DarkGhost`> Hello, I'm using bitcoind and I'm trying to send money to an address using sendtoaddress <address> .0001 but it tells me I need a txfee of .005 even when I change it to .00001 or .000001 it still sends
118 2013-03-03 05:16:22 <weex> DarkGhost`: it has some fee rules hard coded
119 2013-03-03 05:21:24 <Luke-Jr> DarkGhost`: we already answered you on this
120 2013-03-03 06:18:43 <muhoo> wow, the ping interval, at least on bitcoinj, looks like about 200ms
121 2013-03-03 06:51:22 <DarkGhost`> Luke-Jr but I need to know how to bypass the rules so I can send without a tx fee
122 2013-03-03 06:51:55 <Luke-Jr> DarkGhost`: why?
123 2013-03-03 06:52:15 <DarkGhost`> so I can send .001 if needed
124 2013-03-03 06:52:22 <Luke-Jr> pay a fee then
125 2013-03-03 06:52:31 <DarkGhost`> the fee is more than the .001 i want to send!
126 2013-03-03 06:52:45 <Luke-Jr> yepyep
127 2013-03-03 06:52:57 <Luke-Jr> cuz you're not supposed to send .001 BTC ;)
128 2013-03-03 06:53:02 <Luke-Jr> that's less than 5 cents
129 2013-03-03 06:53:26 <Luke-Jr> and unless your wallet is ridiculous, the fee would only be .0005 BTC
130 2013-03-03 06:55:08 <DarkGhost`> well some places do it, like satoshidice if you loose it sends you back a small amount to let you know
131 2013-03-03 06:55:35 <Luke-Jr> SatoshiDice is a DDoS attack on Bitcoin, and forces other people to pay fees for it
132 2013-03-03 06:55:47 <DarkGhost`> how does that work
133 2013-03-03 06:55:52 <Luke-Jr> social engineering
134 2013-03-03 06:55:57 <Luke-Jr> it takes advantage of gamblers
135 2013-03-03 06:56:08 <DarkGhost`> but it doesn't actually pay the fee
136 2013-03-03 06:56:14 <Luke-Jr> nope, it makes the gamblers do that
137 2013-03-03 06:56:20 <Luke-Jr> but there IS a fee
138 2013-03-03 06:56:28 <DarkGhost`> the gamblers have to pay a fee when they send one to satoshi
139 2013-03-03 06:56:33 <DarkGhost`> satoshi doesnt pay one when it sends it back
140 2013-03-03 06:56:45 <DarkGhost`> what about this: https://en.bitcoin.it/wiki/Free_transaction_relay_policy
141 2013-03-03 06:56:53 <Luke-Jr> it takes it out of the gamblers' return amount
142 2013-03-03 06:56:59 <Luke-Jr> that's just for relaying, not accepting
143 2013-03-03 06:57:51 <DarkGhost`> so lost :(
144 2013-03-03 06:57:54 <DarkGhost`> ugh
145 2013-03-03 06:58:11 <DarkGhost`> so i have .0001 im stuck with it?
146 2013-03-03 06:59:45 <Luke-Jr> DarkGhost`: if you just want to get rid of it, I can help you surrender it to a miner
147 2013-03-03 07:00:30 <Luke-Jr> actually
148 2013-03-03 07:00:34 <Luke-Jr> paste me an address in here
149 2013-03-03 07:00:41 <Luke-Jr> how much is the fee to send it?
150 2013-03-03 07:00:46 <Luke-Jr> I'll just send you that
151 2013-03-03 07:00:47 <DarkGhost`> .0005
152 2013-03-03 07:00:54 <DarkGhost`> why would you do that though? lol
153 2013-03-03 07:01:05 <Luke-Jr> it's just a penny
154 2013-03-03 07:01:21 <DarkGhost`> lol well no need its really just an experiment on how to move around bitcoins using bitcoind and such
155 2013-03-03 07:01:23 <DarkGhost`> I do appreciate it though.
156 2013-03-03 07:02:33 <Luke-Jr> well, I'd rather the coin not be destroyed completely (= never spent, file/PC deleted)
157 2013-03-03 07:03:27 <DarkGhost`> whats the "relaying' mean
158 2013-03-03 07:03:52 <DarkGhost`> okay i have a great example Luke-Jr!!
159 2013-03-03 07:03:54 <Luke-Jr> bitcoin.pdf may be useful to read
160 2013-03-03 07:04:01 <DarkGhost`> http://dailybitcoins.org/ how do websites like this, send out such small ammounts
161 2013-03-03 07:04:05 <DarkGhost`> there obviously not paying a .005 fee
162 2013-03-03 07:05:01 <weex> 0.0005 is more common, plus they put lots of outputs in one transaction
163 2013-03-03 07:05:17 <weex> sending out once per day or a few times only
164 2013-03-03 07:05:45 <DarkGhost`> thats what I meant sorry .0005, so they send out multiple coins to different addresses in one tx?
165 2013-03-03 07:16:09 <Luke-Jr> DarkGhost`: correct
166 2013-03-03 07:18:15 <DarkGhost`> do they use createrawtransaction
167 2013-03-03 07:18:18 <DarkGhost`> to acheive that?
168 2013-03-03 07:18:47 <Luke-Jr> no, sendmany
169 2013-03-03 07:19:37 <DarkGhost`> {address:amount,...}
170 2013-03-03 07:20:08 <DarkGhost`> does that mean I literally put like ./bitcoind sendmany accountname {addresshere:.0001} or?
171 2013-03-03 07:20:28 <Luke-Jr> bitcoind isn't really meant to be used from the command line
172 2013-03-03 07:20:38 <Luke-Jr> ./bitcoind sendmany accountname '{"addresshere": 0.0001}'
173 2013-03-03 07:20:41 <Luke-Jr> that will work
174 2013-03-03 07:20:45 <DarkGhost`> okay thnak you
175 2013-03-03 07:21:31 <DarkGhost`> ugh
176 2013-03-03 07:21:43 <DarkGhost`> insufficient funds, probably still trying to use tx fee
177 2013-03-03 07:21:45 <DarkGhost`> rawr
178 2013-03-03 07:21:47 <Luke-Jr> of course
179 2013-03-03 07:22:01 <DarkGhost`> I need to have more than like 5 addresses to remoe the tx fe??
180 2013-03-03 07:22:36 <DarkGhost`> i give up,
181 2013-03-03 07:23:10 <Luke-Jr> you can't remove the fee
182 2013-03-03 07:23:33 <DarkGhost`> lmao
183 2013-03-03 07:23:33 <DarkGhost`> satoshi dice sends back minimal amounts and I just want to do it like them
184 2013-03-03 07:23:38 <DarkGhost`> sorry know I'm being stubborn
185 2013-03-03 07:24:16 <Luke-Jr> sorry, I'm not going to encourage people to setup another DDoS like SD
186 2013-03-03 07:24:34 <Luke-Jr> and 100% of the transactions SD sends have fees, even though it's not paid by SD
187 2013-03-03 07:24:53 <DarkGhost`> so are you saying that when people send money to SD they send double the fee?
188 2013-03-03 07:24:59 <DarkGhost`> one to send it and one for SD to send it back?
189 2013-03-03 07:25:13 <Luke-Jr> DarkGhost`: no, SD takes it out of what it's sending back
190 2013-03-03 07:25:21 <DarkGhost`> have you ever played SD?
191 2013-03-03 07:25:40 <Luke-Jr> so if you win 0.50 BTC, SD sends you 0.4995 BTC and puts 0.0005 BTC of your winnings in the fee
192 2013-03-03 07:25:52 <DarkGhost`> lets say you bet .50 BTC and lose it.
193 2013-03-03 07:25:55 <Luke-Jr> no, I support Bitcoin, so I will not enable attacks against Bitcoin
194 2013-03-03 07:25:59 <DarkGhost`> they still send you back like .000001 so you know that you lost
195 2013-03-03 08:34:21 <sturles> DarkGhost`: That's evil! You will end up payin more fees to spend that dust than it is worth.
196 2013-03-03 08:48:03 <jouke> /window 14
197 2013-03-03 08:48:06 <jouke> >_<
198 2013-03-03 08:51:24 <Quazgaa> i prefer to hit alt-j 14
199 2013-03-03 08:51:26 <Quazgaa> ;)
200 2013-03-03 10:13:58 <BTCOxygen> Hi
201 2013-03-03 10:15:11 <Quazgaa> buns
202 2013-03-03 12:25:13 <Goonie> bitcoinj 0.7.1 and Bitcoin Wallet 2.42 have been released, mainly fixing bugs.
203 2013-03-03 12:45:23 <TD> thanks Goonie
204 2013-03-03 12:45:26 <TD> ACTION -> out for a while
205 2013-03-03 13:33:39 <kritCoin> how many mining programs are out there?
206 2013-03-03 13:34:45 <SomeoneWeird> quite a few
207 2013-03-03 13:34:47 <kritCoin> is there a reference mining implementationj?
208 2013-03-03 13:35:05 <SomeoneWeird> theres cpu mining code built into bitcoind
209 2013-03-03 13:35:09 <SomeoneWeird> but it's disabled
210 2013-03-03 13:35:30 <kritCoin> does it work?
211 2013-03-03 13:35:43 <SomeoneWeird> yes
212 2013-03-03 13:35:46 <kritCoin> that one is the reference?
213 2013-03-03 13:35:47 <SomeoneWeird> but it's a cpu miner
214 2013-03-03 13:35:54 <SomeoneWeird> and it's very inefficient
215 2013-03-03 13:36:02 <SomeoneWeird> depends what you mean by "reference"
216 2013-03-03 13:36:56 <kritCoin> is there a list of mining software somewhere?
217 2013-03-03 13:37:41 <kritCoin> is there a list of mining software somewhere?
218 2013-03-03 13:39:28 <SomeoneWeird> don't spam
219 2013-03-03 13:40:15 <Quazgaa> heh
220 2013-03-03 13:40:28 <Quazgaa> i bet google knows
221 2013-03-03 13:43:59 <kritCoin> what is the differencce between a gpu miner and a FPGA miner
222 2013-03-03 13:45:08 <HM> a gpu miner uses your computers graphics processor
223 2013-03-03 13:45:14 <Raccoon> FPGA can be optomized for a very specific task.
224 2013-03-03 13:45:24 <HM> a fpga miner uses a fpga, which is a programmable generic device you can buy
225 2013-03-03 13:47:29 <Raccoon> a lot lower power, too
226 2013-03-03 13:48:13 <Raccoon> hmm
227 2013-03-03 13:49:18 <Raccoon> at 800 mhash, how long to earn 33 bitcoins?
228 2013-03-03 13:50:14 <HM> well the network is up to something like 35 TH/s
229 2013-03-03 13:50:46 <HM> there's a bot command for that calculation
230 2013-03-03 13:51:14 <denisx> Raccoon: http://www.alloscomp.com/bitcoin/calculator
231 2013-03-03 13:51:36 <Raccoon> oh jesus, 35 TH/s already
232 2013-03-03 13:51:54 <HM> 800 MH/s is only 0.002% of the network
233 2013-03-03 13:54:01 <Scrat> so how can I quantify "connect to well connected nodes" now that b.i doesn't have a list of them
234 2013-03-03 13:58:37 <SomeoneWeird> <HM> a fpga miner uses a fpga, which is a programmable generic device you can buy < not generic, VERY specific
235 2013-03-03 14:00:07 <OneMiner> Good suggestion from #bitcoin-mining, allow user to specify alternative dirrectory for blockchain files on install of client. Example, if C:\\ is a SSD then I may want to put the blockchain on D:\\.
236 2013-03-03 14:00:44 <HM> SomeoneWeird: in what way specific? I meant generic in the sense it's not made for a specific purpose like a GPU
237 2013-03-03 14:00:44 <Scrat> D:\\. looks like a smiley with a mental deficiency
238 2013-03-03 14:01:34 <OneMiner> Same with C:
239 2013-03-03 14:01:56 <OneMiner> That smile aint natural. Botox or something....
240 2013-03-03 14:02:13 <Diablo-D3> OneMiner: rem, I'd rather have the chain on an ssd
241 2013-03-03 14:02:16 <Diablo-D3> *erm
242 2013-03-03 14:02:32 <Diablo-D3> the whole "writing SSDs to death" thing was debunked years ago
243 2013-03-03 14:03:02 <OneMiner> Diablo-D3 But what if I have other things that I'd give higher SSD priority to. Such as games and porn?
244 2013-03-03 14:03:02 <Scrat> Diablo-D3: i dont think that's what he asked
245 2013-03-03 14:03:06 <Scrat> but you're right about that
246 2013-03-03 14:03:33 <Diablo-D3> OneMiner: porn is cold storage, it doesn't require a high IO device
247 2013-03-03 14:03:54 <Diablo-D3> and games don't need high IO either just high throughput, which can be done on mechanical drives fine
248 2013-03-03 14:04:07 <Diablo-D3> bitcoin is a database load, thus needs high IO over high throughput
249 2013-03-03 14:04:11 <OneMiner> Or it's full or something... I dunno, I'm kidding about the porn. :P I don't even have an SSD. I just think this is a worthwhile feature. It would cost one page on the installer.
250 2013-03-03 14:05:09 <Diablo-D3> thats probably a bad idea
251 2013-03-03 14:05:33 <Diablo-D3> it'd lead to dumbfucks trying to network host the chain and trying to use it across multiple instances of the client
252 2013-03-03 14:05:53 <Diablo-D3> plus, wallets would still need to be in per user dirs
253 2013-03-03 14:06:02 <Diablo-D3> and its better to just keep the files in one place
254 2013-03-03 14:06:27 <Scrat> so, guise, is there a list of well connected nodes?
255 2013-03-03 14:08:16 <OneMiner> With GB/s LAN and everything, would that even be a bad idea? Diablo-D3
256 2013-03-03 14:08:54 <Diablo-D3> OneMiner: er? its not meant to be accessed by multiple clients at once
257 2013-03-03 14:09:00 <Diablo-D3> it'd get corrupted quickly
258 2013-03-03 14:09:48 <Diablo-D3> databases over raw IO network protocols also generally lead to data corruption through user stupidity
259 2013-03-03 14:09:52 <OneMiner> Ok, I see. But I maintain that an alternate install dir for the blockchain could be useful. Example, C:\\ is a HDD and D:\\ is a SDD where you want the blockchain.
260 2013-03-03 14:10:11 <Diablo-D3> OneMiner: no.
261 2013-03-03 14:10:20 <Diablo-D3> they'd be better off switching to a filesystem that can use both drives
262 2013-03-03 14:11:23 <OneMiner> Well, we don't want to be talking filesystems and stuff. This needs to be a user friendly install.
263 2013-03-03 14:12:20 <OneMiner> ACTION has SSDs on the mind and browses the stores
264 2013-03-03 14:13:31 <Diablo-D3> you're solving the problem at the wrong layer
265 2013-03-03 14:13:40 <Diablo-D3> computers should function properly first
266 2013-03-03 14:13:46 <Diablo-D3> you can worry about bitcoin later.
267 2013-03-03 14:28:30 <Raccoon> is there any way to push a transaction through before the client is finished syncing?
268 2013-03-03 14:28:47 <Raccoon> there's no way this laptop will ever finish.
269 2013-03-03 14:29:21 <sipa> Raccoon: what version and what hardware?
270 2013-03-03 14:29:44 <Raccoon> 0.6.3
271 2013-03-03 14:29:52 <sipa> install 0.8.0
272 2013-03-03 14:30:04 <Raccoon> a 2004 single core 1.7 with a pATA hdd
273 2013-03-03 14:30:32 <Raccoon> when I do, then what
274 2013-03-03 14:30:36 <sipa> hmm, it may still take a while to sync on 0.8.0, but it shouldn't be more than a few hours
275 2013-03-03 14:30:50 <Raccoon> so what's the key cobo to push the tx through
276 2013-03-03 14:31:26 <sipa> is the transaction shown in the client?
277 2013-03-03 14:31:36 <Raccoon> yes
278 2013-03-03 14:31:42 <sipa> with confirmations?
279 2013-03-03 14:31:46 <Raccoon> no.
280 2013-03-03 14:31:53 <Raccoon> it wont confirm till synced
281 2013-03-03 14:31:59 <sipa> then it should already be pushing it to the network
282 2013-03-03 14:32:03 <Raccoon> the money is old
283 2013-03-03 14:32:32 <Raccoon> but the client is 200 days from syncing, and hasn't budged
284 2013-03-03 14:32:42 <sipa> "budged" ?
285 2013-03-03 14:33:03 <Raccoon> budged.
286 2013-03-03 14:33:14 <sipa> ok
287 2013-03-03 14:33:34 <sipa> but what is the problem? that the tx isn't being sent to the network, or that it isn't shown as confirmed?
288 2013-03-03 14:33:45 <Raccoon> both?
289 2013-03-03 14:33:55 <sipa> because afaik, it should be pushing it to the network every now and then automatically, until it sees it confirmed
290 2013-03-03 14:34:11 <sipa> and the slow syncing should be significantly better in 0.8.0
291 2013-03-03 14:34:15 <Raccoon> even if the client is still downloading 200 days fo blocks?
292 2013-03-03 14:34:30 <Raccoon> i don't even want to try syncing
293 2013-03-03 14:34:34 <Raccoon> i want to delete it
294 2013-03-03 14:34:48 <Raccoon> and format
295 2013-03-03 14:34:49 <sipa> can you tell me the txid?
296 2013-03-03 14:35:09 <sipa> make a backup of wallet.dat, format, install 0.8.0, but wallet backup back
297 2013-03-03 14:36:34 <sipa> but just installing 0.8.0 will be faster, as it will reuse the block data you already have instead of re-downloading it
298 2013-03-03 14:38:15 <kritCoin> FPGA seems to be like ASIC,
299 2013-03-03 14:38:24 <kritCoin> are there FPGA mining boards?
300 2013-03-03 14:38:28 <sipa> yes
301 2013-03-03 14:38:57 <kritCoin> mmm
302 2013-03-03 14:41:45 <OneMiner> FPGA is like ASIC as CPU is like GPU.
303 2013-03-03 14:42:05 <OneMiner> For our purposes.
304 2013-03-03 14:45:23 <sipa> an FPGA is essentially a programmable FPGA
305 2013-03-03 14:45:25 <sipa> eh ASIC
306 2013-03-03 14:45:29 <sipa> an FPGA is essentially a programmable ASIC
307 2013-03-03 14:46:34 <OneMiner> FPGA is maybe more like a hardware programmable CPU. Same idea though.
308 2013-03-03 14:46:37 <BlueMatt> gmaxwell: trying to debug this lcov thing where all pulls are considered testless...any guesses why lcov would miss lines in one run, but find them in another?
309 2013-03-03 14:48:02 <sipa> BlueMatt: can you give an example of such a line?
310 2013-03-03 14:48:33 <BlueMatt> sipa: alert.cpp:161
311 2013-03-03 14:48:44 <BlueMatt> its identified as a line in the jenkins/master build: http://jenkins.bluematt.me/job/Bitcoin/lastSuccessfulBuild/artifact/src/total.coverage/mnt/jenkins/jobs/Bitcoin/workspace/src/alert.cpp.gcov.html
312 2013-03-03 14:48:50 <BlueMatt> but not in a pull: http://jenkins.bluematt.me/pull-tester/091f18419011bfee6242270e52237f524ca23c8e/bitcoin/src/total.coverage/mnt/bitcoin/src/alert.cpp.gcov.html
313 2013-03-03 14:49:11 <BlueMatt> and there are lots of such lines, and some are identified in the pull but not jenkins/master, some the other way around
314 2013-03-03 14:50:15 <sipa> same build options?
315 2013-03-03 14:50:19 <sipa> same compiler, ...
316 2013-03-03 14:50:25 <BlueMatt> same script, same compiler, etc
317 2013-03-03 14:50:30 <sipa> hmm, weird
318 2013-03-03 14:50:37 <BlueMatt> same everything, one just happens to be in a chroot
319 2013-03-03 14:50:45 <Scrat> is there a list of well connected nodes somewhere?
320 2013-03-03 14:51:12 <BlueMatt> the fallback nodes list tends to not be bad...but the dnsseed-accepted nodes are probably just fine
321 2013-03-03 14:51:29 <BlueMatt> unless you know what you're doing, you probably dont need to use anything but the dnsseeds
322 2013-03-03 14:51:34 <Scrat> BlueMatt: but they are kinda random
323 2013-03-03 14:51:40 <BlueMatt> thats the point
324 2013-03-03 14:51:45 <jurov> Scrat, bitcoincharts has a list of where most blocks appeared first from
325 2013-03-03 14:52:01 <jurov> *er, no blockchain.info
326 2013-03-03 14:52:48 <BlueMatt> Scrat: I know, at a minimum, my dnsseed checks for block height and download-ability when accepting nodes, so use that
327 2013-03-03 14:52:55 <BlueMatt> Id think sipa's does too
328 2013-03-03 14:55:53 <sipa> no, it doesn't
329 2013-03-03 14:56:00 <Scrat> ok so edit net.cpp and rebuild
330 2013-03-03 14:56:17 <sipa> ??
331 2013-03-03 14:56:51 <Scrat> hello sipa
332 2013-03-03 14:56:55 <BlueMatt> Scrat: what? no just run
333 2013-03-03 14:57:12 <sipa> Scrat: to do what?
334 2013-03-03 14:57:16 <BlueMatt> Scrat: finding isolated nodes is an incredibly rare issue...like an unheard of issue, for the most part
335 2013-03-03 14:59:31 <sipa> Scrat: you can use -addnode or -connect to specify which nodes to (try to) connect to manually
336 2013-03-03 14:59:39 <sipa> Scrat: you can use -nodnsseed to disable DNS seeding
337 2013-03-03 15:00:31 <Scrat> sipa: I know, just want to connect to popular nodes in order to reduce the chance of double spends (yes yes I know, dont receive unconfirmed tx and yadda yadda)
338 2013-03-03 15:00:59 <sipa> ok, so use -addnode ?
339 2013-03-03 15:01:08 <BlueMatt> Scrat: that actually won't help
340 2013-03-03 15:01:36 <BlueMatt> Scrat: in order to address double spends you need to modify the code to warn about them, not just connect to more nodes
341 2013-03-03 15:02:29 <Scrat> sipa: don't know which ones to add
342 2013-03-03 15:02:31 <Scrat> BlueMatt: ok
343 2013-03-03 15:02:41 <sipa> Scrat: well what would you modify in net.cpp then?
344 2013-03-03 15:03:11 <Scrat> sipa: this: [17:52] <BlueMatt> Scrat: I know, at a minimum, my dnsseed checks for block height and download-ability when accepting nodes, so use that
345 2013-03-03 15:03:34 <Scrat> comment out the other seeds
346 2013-03-03 15:03:35 <BlueMatt> Scrat: it already does, you dont have to change anything
347 2013-03-03 15:03:36 <Scrat> but its fine
348 2013-03-03 15:03:38 <BlueMatt> Scrat: no
349 2013-03-03 15:03:42 <BlueMatt> there is no reason to do that
350 2013-03-03 15:03:49 <BlueMatt> (it wont do what you are apparently thinking)
351 2013-03-03 15:03:52 <Scrat> alright calm down :p
352 2013-03-03 15:04:27 <BlueMatt> sorry, Ive been awake for like 20 hours at this point...
353 2013-03-03 15:07:44 <Scrat> sipa: was kinda wondering what are good practices for a merchant oriented bitcoind, like turning off or firewalling listening
354 2013-03-03 15:09:52 <BlueMatt> proxy listening, probably
355 2013-03-03 15:10:05 <BlueMatt> and (obviously) most of the coins in cold storage
356 2013-03-03 15:10:36 <BTCOxygen> Warning: Warning: error reading wallet.dat! All keys read correctly, but transac tion data or address book entries might be missing or incorrect.
357 2013-03-03 15:10:47 <Scrat> BlueMatt: true that
358 2013-03-03 15:10:50 <BTCOxygen> ************************
359 2013-03-03 15:11:02 <BTCOxygen> EXCEPTION: St13runtime_error
360 2013-03-03 15:11:10 <BTCOxygen> CWalletTx::IsSpent() : nOut out of range
361 2013-03-03 15:11:18 <BTCOxygen> bitcoin in AppInit()
362 2013-03-03 15:11:21 <BTCOxygen> ^^^^^^^^^^^^^^^^
363 2013-03-03 15:11:26 <BTCOxygen> And bitcoind crashes
364 2013-03-03 15:12:09 <BTCOxygen> Any help?
365 2013-03-03 15:12:44 <sipa> BTCOxygen: i haven't seen that error, ever
366 2013-03-03 15:12:48 <sipa> what did you do?
367 2013-03-03 15:14:40 <BTCOxygen> sipa: ./bitcoind stop
368 2013-03-03 15:14:43 <BTCOxygen> then
369 2013-03-03 15:14:47 <BTCOxygen> sipa: ./bitcoind
370 2013-03-03 15:14:51 <BTCOxygen> Got that error
371 2013-03-03 15:15:01 <sipa> which version?
372 2013-03-03 15:15:06 <BTCOxygen> sipa: 0.7
373 2013-03-03 15:15:16 <BTCOxygen> Upgraded to 0.8 still same error
374 2013-03-03 15:15:29 <sipa> i'd suggest making a backup of wallet.dat, and running with -salvagewallet
375 2013-03-03 15:15:45 <sipa> but i don't understand how that error is possible in the first place
376 2013-03-03 15:15:56 <BTCOxygen> sipa: What does that parameter do?
377 2013-03-03 15:16:06 <sipa> BTCOxygen: it tries to recover the wallet
378 2013-03-03 15:16:19 <sipa> by just reading the private keys in it, and creating a new one with those keys
379 2013-03-03 15:17:06 <ProfMac> what all is in a wallet?
380 2013-03-03 15:17:21 <lottoBTC> TO PLAY LOTTO BTC: http://www.lottobtc.com/
381 2013-03-03 15:17:42 <sipa> ProfMac: http://bitcoin.stackexchange.com/questions/3173/what-information-does-a-wallet-contain
382 2013-03-03 15:18:24 <BTCOxygen> sipa: What is wallet defragmentation ?
383 2013-03-03 15:18:40 <sipa> BTCOxygen: where do you read that?
384 2013-03-03 15:18:58 <sipa> ProfMac: keys, transactions, account information, list of unused keys, encryption info (if encrypted), pointer to the last seen best block, ...
385 2013-03-03 15:19:12 <BTCOxygen> I heard slush saying that
386 2013-03-03 15:19:25 <BTCOxygen> Just curious to know what it means
387 2013-03-03 15:19:25 <Scrat> BTCOxygen: smartctl -a yourdrive, also check dmesg for i/o errors
388 2013-03-03 15:19:43 <sipa> BTCOxygen: it may refer to combining small coins in your wallet into larger ones
389 2013-03-03 15:20:55 <slush> BTCOxygen: I had tens of thousands transactions in one wallet, with tens of thousands keys, so I created new wallet and moved all coins there.
390 2013-03-03 15:21:00 <slush> Nothing magical
391 2013-03-03 15:21:34 <BTCOxygen> slush: Oh, So its just reducing the size of the wallet
392 2013-03-03 15:21:43 <BTCOxygen> My wallet is currently 20MB
393 2013-03-03 15:22:03 <slush> yes
394 2013-03-03 15:23:42 <BTCOxygen> sipa: -salvagewallet is re-scanning the blockchain, Is that OK?
395 2013-03-03 15:23:56 <sipa> it will inevitably cause a rescan yes
396 2013-03-03 15:24:05 <sipa> to find your transactions
397 2013-03-03 15:24:44 <etotheipi_> sipa, gmaxwell, Luke-Jr, anyone else: any reasonable suggestions for how to securely/verifiably download bitcoin-qt installer in Windows without installing gpg4win to directly verify the download?
398 2013-03-03 15:24:45 <kritCoin> are there any fpga open source solution for bitcoin?
399 2013-03-03 15:25:07 <etotheipi_> the context is, I want the user's computer to automatically grab and execute the installer, but of course also know it got the right one
400 2013-03-03 15:25:40 <sipa> etotheipi_: i personally wouldn't bother with that - just tell them they need to install bitcoind or bitcoin-qt?
401 2013-03-03 15:26:06 <etotheipi_> sipa: well I would personally bother with it
402 2013-03-03 15:26:10 <sipa> (i suppose i'm not helping)
403 2013-03-03 15:26:12 <etotheipi_> haha
404 2013-03-03 15:26:29 <etotheipi_> it's not only improving usability quite a bit, I can add some security by doing the checks for them
405 2013-03-03 15:26:36 <etotheipi_> which most users don't do
406 2013-03-03 15:27:28 <sipa> etotheipi_: true, but that just moves the problem to users having a secure and verifiable version of armory
407 2013-03-03 15:27:52 <etotheipi_> sipa: sure... there's one point of failure instead of 2
408 2013-03-03 15:28:14 <etotheipi_> a compromised Armory OR Bitcoin-Qt is a compromise for them
409 2013-03-03 15:28:40 <sipa> etotheipi_: or a malicious Armory developer :p
410 2013-03-03 15:28:49 <etotheipi_> but that's not the primary reason for doing this
411 2013-03-03 15:29:03 <etotheipi_> Armory is never going to get wider attention unless I can make it [appear to be] standalone
412 2013-03-03 15:29:08 <etotheipi_> (and also bring down RAM requirements)
413 2013-03-03 15:29:28 <etotheipi_> both are in the works, I just want to make sure I'm not reducing security instead of adding it
414 2013-03-03 15:30:21 <BTCOxygen> etotheipi_: Are you the seveloper of Armory?
415 2013-03-03 15:30:24 <BTCOxygen> *developer
416 2013-03-03 15:30:41 <etotheipi_> hmm...maybe I can actually verify the sigs after all using Crypto++
417 2013-03-03 15:30:47 <etotheipi_> BTCOxygen: yes, I am
418 2013-03-03 15:31:23 <TD> muhoo: hey
419 2013-03-03 15:31:37 <sipa> etotheipi_: wait, do you mean reimplementing gpg from scratch? :S
420 2013-03-03 15:31:49 <etotheipi_> sipa: haha no
421 2013-03-03 15:31:57 <sipa> etotheipi_: if you do, i'd consider you both crazy and incompetent
422 2013-03-03 15:32:02 <etotheipi_> sipa: but I just realized that crypto++ may already have what's needed to do this
423 2013-03-03 15:32:05 <etotheipi_> i.e. gpg integrated already
424 2013-03-03 15:32:10 <sipa> oh
425 2013-03-03 15:32:29 <sipa> in that case, i may have to consider the crypto++ authors crazy and incompetent :p
426 2013-03-03 15:32:42 <TD> etotheipi_: if it becomes standalone, how will it be different to bitcoin-qt or multibit?
427 2013-03-03 15:32:54 <etotheipi_> TD: have you ever used Armory?
428 2013-03-03 15:33:05 <TD> i know it has some features that the other two lack for sure
429 2013-03-03 15:33:36 <etotheipi_> multiple, deterministic wallets, easy importing exporting of private keys, *offline wallet interface*... I think that makes it pretty significantly different
430 2013-03-03 15:33:39 <TD> but i mean, given the effort of changing armory to be standalone, would it be easier to reimplement those features in another client
431 2013-03-03 15:33:54 <TD> as it means either writing full verification code which is very hard, or spv mode
432 2013-03-03 15:34:04 <BTCOxygen> etotheipi_: I would like to see Armory working without depending on bitcoins
433 2013-03-03 15:34:06 <BTCOxygen> etotheipi_: I would like to see Armory working without depending on bitcoind
434 2013-03-03 15:34:08 <BTCOxygen> lol
435 2013-03-03 15:34:19 <etotheipi_> BTCOxygen, TD: that's what bitcoind is for
436 2013-03-03 15:34:41 <etotheipi_> t odo that verification without having to reimplement my own crappy, buggy version of it that will reduce securty
437 2013-03-03 15:35:02 <PRab> etotheipi_: I have no problem with Armory depending on bitcoind!
438 2013-03-03 15:35:05 <BTCOxygen> etotheipi_: Is there a way you could merge bitcoind into Armory
439 2013-03-03 15:35:15 <etotheipi_> BTCOxygen: that's basically what I'm talking about right now
440 2013-03-03 15:35:38 <etotheipi_> I'm not merging the codebases, I'm just managing the bitcoind instance in a separate process in the background so the user doesn't even realize it's there
441 2013-03-03 15:36:00 <etotheipi_> anything that requires re-releasing Armory if there's a critical update to Bitcoin-Qt is a no-go for me
442 2013-03-03 15:36:02 <BTCOxygen> I mean if its possible to merge the code
443 2013-03-03 15:36:10 <TD> oh, ok
444 2013-03-03 15:36:19 <TD> i misunderstood what you meant by making it standalone
445 2013-03-03 15:36:26 <kritCoin> how nany ppl here use icarus?
446 2013-03-03 15:36:56 <etotheipi_> so at the moment, I am just trying to figure out how to make sure I download the correct (secure) version of bitcoind/-qt for the user
447 2013-03-03 15:37:17 <etotheipi_> since I can't execute any GPG commands on Windows
448 2013-03-03 15:37:17 <sipa> etotheipi_: oh, you may need to know: 0.8.1 will do pre-allocating of block files slightly differently: when a block file is full, its unused padding will be dropped
449 2013-03-03 15:37:27 <etotheipi_> sipa: that's fine
450 2013-03-03 15:37:36 <etotheipi_> my code will ignore that
451 2013-03-03 15:37:39 <sipa> ok
452 2013-03-03 15:37:46 <etotheipi_> and soon I'll be switching off of using the blk files...
453 2013-03-03 15:37:53 <etotheipi_> (at least, I won't be using them as much)
454 2013-03-03 15:37:54 <sipa> then what will you use?
455 2013-03-03 15:38:03 <etotheipi_> I'll do an initial scan of the blk files
456 2013-03-03 15:38:10 <etotheipi_> then manage everything else through getblocks
457 2013-03-03 15:38:15 <etotheipi_> and store the data myself
458 2013-03-03 15:38:30 <sipa> duplicating the block data?
459 2013-03-03 15:38:33 <etotheipi_> at the very beginning I will be creating (duplicating) a full tx index...
460 2013-03-03 15:38:41 <etotheipi_> but then paring it down to only store relevant tx
461 2013-03-03 15:38:57 <sipa> just an index, or the actual data itself?
462 2013-03-03 15:39:11 <etotheipi_> I have gone through the code and realized Armory GUI doesn't really need the whole tx index
463 2013-03-03 15:39:26 <etotheipi_> but I want to have the capability to have a full index if I want
464 2013-03-03 15:39:32 <etotheipi_> sipa: the actual data
465 2013-03-03 15:39:42 <sipa> that sounds bad
466 2013-03-03 15:39:51 <etotheipi_> allowing me, in the future, to use non-localhost connections
467 2013-03-03 15:39:55 <etotheipi_> sipa: what do you mean?
468 2013-03-03 15:40:04 <sipa> people already complain loudly about the storage requirements
469 2013-03-03 15:40:16 <etotheipi_> sipa: trust me, they complain much more loudly about Armory's RAM requirement
470 2013-03-03 15:40:32 <etotheipi_> :)
471 2013-03-03 15:40:38 <sipa> and as it seems you're mostly doing thing to improve wallet funcionality, i think you should focus on your wallet instead
472 2013-03-03 15:41:07 <etotheipi_> sipa: (1) I have a ton of problems having to do with asynchronously reading the blockfiles while bitcoind is writing to them
473 2013-03-03 15:41:07 <sipa> people who understand the need for full nodes on the network may be willing to store the full chain
474 2013-03-03 15:41:28 <etotheipi_> (2) I won't be duplicating the full blockchain, shortly afterwards
475 2013-03-03 15:41:31 <sipa> etotheipi_: i'm actually suggesting not depending on the full data at all
476 2013-03-03 15:41:38 <sipa> neither in bitcoind or your own
477 2013-03-03 15:41:40 <etotheipi_> I'll be switching to duplicating only the wallet-relevant tx
478 2013-03-03 15:42:16 <kritCoin> what is the wallet binary storage format
479 2013-03-03 15:42:21 <TD> Goonie: odd
480 2013-03-03 15:42:26 <kritCoin> is this somewhere descriobed?
481 2013-03-03 15:42:30 <etotheipi_> I just want the capability for the library to maintain a full index (and it's easiest for me right now)... then immediately afterwards I'll upgrade it to find and duplicate only wallet-relevant tx
482 2013-03-03 15:42:31 <TD> Goonie: i just opened bitcoin wallet and it was 20 months behind
483 2013-03-03 15:42:33 <kritCoin> is this somewhere described?
484 2013-03-03 15:42:33 <sipa> kritCoin: which client?
485 2013-03-03 15:42:35 <TD> Goonie: i'm sure it was synced previously
486 2013-03-03 15:42:51 <TD> oh
487 2013-03-03 15:42:52 <TD> crap
488 2013-03-03 15:42:53 <kritCoin> the qt client
489 2013-03-03 15:42:55 <TD> it went back to the market version
490 2013-03-03 15:42:59 <TD> that's annoying
491 2013-03-03 15:43:00 <Goonie> TD: is this the SPVStore version?
492 2013-03-03 15:43:09 <sipa> kritCoin: it's a BDB 4.8 database file
493 2013-03-03 15:43:18 <Goonie> TD: ah ok, that explains
494 2013-03-03 15:43:18 <TD> Goonie: no never mind. i didn't spot the update notification in my notifybar
495 2013-03-03 15:43:28 <TD> Goonie: i'll re-upgrade to the version you emailed me
496 2013-03-03 15:43:31 <sipa> kritCoin: with these keys in it: http://bitcoin.stackexchange.com/questions/3173/what-information-does-a-wallet-contain
497 2013-03-03 15:43:39 <TD> Goonie: the latest version is the one based on 0.7.1 right?
498 2013-03-03 15:43:47 <Goonie> TD: yes
499 2013-03-03 15:44:00 <etotheipi_> sipa: so I know this seems asanine, but I don't see a simpler way to do it: put the SHA256SUMS.asc text on my webserver, and sign it with one of my offline *bitcoin* keys ... obviously Armory can verify Bitcoin signatures
500 2013-03-03 15:44:05 <Goonie> TD: I can mail you a new version soon, so you don't get bothered by update notifications
501 2013-03-03 15:44:05 <TD> ok. btw during replay the tx list kept scrolling to the top
502 2013-03-03 15:44:11 <etotheipi_> (after I manually verify gavin's signatures)
503 2013-03-03 15:44:32 <TD> Goonie: it seems it forgot my address labels :(
504 2013-03-03 15:44:44 <etotheipi_> then when new versions of bitcoinqt are released, I only have to update that file, not release a whole new version of Armory
505 2013-03-03 15:44:48 <TD> oh wait
506 2013-03-03 15:44:54 <TD> because i restored my keys from backup. i forgot about that too :)
507 2013-03-03 15:45:02 <etotheipi_> (assuming Gavin doesn't change his signing key)
508 2013-03-03 15:45:21 <Goonie> TD: the scrolling to top is a known issue. I wonder what's the plan for the Wallet.getTransactions() API...
509 2013-03-03 15:45:24 <TD> Goonie: i think jim is right. backups should just be regular wallet backups. i'm not sure exports of just keys really make sense in future, as wallets will hold more and more useful stuff beyond keys
510 2013-03-03 15:45:51 <sipa> etotheipi_: so your failure points are: 1) your webserver gets hacked 2) sf download servers gets hacked 3) you don't properly do the checking in the client 4) your client download itself gets compromised ...
511 2013-03-03 15:46:06 <TD> Goonie: what's the issue with the current one? you mean the issue you filed about it getting too big?
512 2013-03-03 15:46:51 <sipa> wait not true
513 2013-03-03 15:46:59 <sipa> 1) isn't an issue
514 2013-03-03 15:47:57 <etotheipi_> sipa: (2) isn't an issue
515 2013-03-03 15:48:21 <sipa> right, as long as you do the validation yourself properly
516 2013-03-03 15:48:22 <etotheipi_> and (4) is always an issue (rather, it's a given)
517 2013-03-03 15:48:40 <Goonie> TD: the current one does not make it easy to see what changed. and this might be necessary for avoiding the scrolling to top
518 2013-03-03 15:48:53 <sipa> etotheipi_: but right now, 4 will not cause people to get a corrupted bitcoind, so they won't accept invalid transactions
519 2013-03-03 15:49:04 <etotheipi_> sipa: true
520 2013-03-03 15:49:14 <Goonie> TD: currently, I just replace the whole list in the adapter on each change
521 2013-03-03 15:49:28 <etotheipi_> sipa: but this is only done if thye don't have Bitcoin-Qt installed already
522 2013-03-03 15:49:40 <etotheipi_> which is basically users new to Bitcoin
523 2013-03-03 15:50:24 <etotheipi_> most people downloading will already have Bitcoin-Qt on their machine and (4) is a very minor concern (plus there will be a link for them if they want to go do it themselves)
524 2013-03-03 15:50:45 <sipa> ok
525 2013-03-03 15:50:50 <TD> Goonie: seems like a simple fix would be to update the list based on the individual callbacks ??? when a new tx is received, add an element, and register confidence listeners for the rest.
526 2013-03-03 15:50:52 <Goonie> TD: I mean, I can probably improve this with some effort. I just wanted to ask if there are any plans for changing the API, like sending "DB transactions (INSERT/DELETE/UPDATE) of Bitcoin transactions" with the events?
527 2013-03-03 15:51:10 <sipa> etotheipi_: still, i think it will cause a ton of work for you, and i'm not convinced about the security
528 2013-03-03 15:51:11 <TD> the event listeners already give you deltas, more or less
529 2013-03-03 15:51:13 <etotheipi_> sipa: do I sound crazy? I really don't like this... I'd much rather just have GPG available
530 2013-03-03 15:51:26 <etotheipi_> but Windows isn't making it easy for me
531 2013-03-03 15:51:37 <Goonie> TD: I think its not complete, this is why we introduced the onChanged()
532 2013-03-03 15:51:40 <TD> Goonie: onCoinsReceived gives you the transaction
533 2013-03-03 15:51:48 <sipa> etotheipi_: oh, then first tell them to install an operating system? ;)
534 2013-03-03 15:51:54 <sipa> *ducks*
535 2013-03-03 15:51:57 <etotheipi_> sipa: haha
536 2013-03-03 15:52:27 <TD> Goonie: you can just have a flag. if onCoinsReceived/Sent decides to take action by updating the list, set a flag and then have onChange do nothing except reset the flag, when it's set
537 2013-03-03 15:52:43 <PRab> etotheipi_: Why can't you use the windows signature (from the Bitcoin Foundation) instead of GPG?
538 2013-03-03 15:53:21 <etotheipi_> PRab: how do I enforce that?
539 2013-03-03 15:53:23 <TD> Goonie: same for onTransactionConfidenceChanged
540 2013-03-03 15:53:42 <etotheipi_> or rather, how can I check that from inside a python script in Windows?
541 2013-03-03 15:54:03 <TD> Goonie: we added onWalletChanged() for efficiency during block replay/catchup
542 2013-03-03 15:54:04 <etotheipi_> that is actually a reasonable solution, I forgot the installers with code-signed
543 2013-03-03 15:54:05 <PRab> In python can you call arbitrary windows DLL's?
544 2013-03-03 15:54:14 <Goonie> TD: that sounds more like a kludge. I'm interested in the long term plan.
545 2013-03-03 15:54:28 <TD> Goonie: it's called once per block rather than once per transaction
546 2013-03-03 15:54:42 <etotheipi_> PRab: yeah, I should be able to call anything on their system that doesn't require admin
547 2013-03-03 15:54:52 <TD> Goonie: i don't understand. you're asking for an API that tells you what changed, but there already is one. you just aren't using it because doing a full refresh when anything changes is simpler.
548 2013-03-03 15:54:57 <etotheipi_> preferably if it's in an entirely deterministic location
549 2013-03-03 15:55:12 <PRab> I would need to look up the API, but I did something similar to this before.
550 2013-03-03 15:55:23 <PRab> Just a few seconds let me look at MSDN.
551 2013-03-03 15:56:57 <Goonie> TD: I will look into it again. Probably you are right. But in my memory I cannot get the complete delta from the other callbacks
552 2013-03-03 15:57:21 <Goonie> Maybe things have changed since last summer
553 2013-03-03 15:57:50 <TD> Goonie: the way it evolved was this - you have code that converts getTransactions() into the ui objects. now the issue is when replaying the block chain, every time a transaction changed its confidence (because there was a new block on top of it, for instance), the entire ui would refresh, which was very slow.
554 2013-03-03 15:57:53 <PRab> etotheipi_: http://msdn.microsoft.com/en-us/library/windows/desktop/aa370121(v=vs.85).aspx
555 2013-03-03 15:58:26 <TD> Goonie: so I added an onWalletChanged() event that would be invoked only once per block, and could encompass multiple changes, so obviously, it does not tell you what changed. the existing events were still there. so your refresh code can be invoked from onWalletChanged and now it's efficient again.
556 2013-03-03 15:58:51 <TD> Goonie: the other callbacks give you all the data you need to adjust the UI objects but it means more code, to examine what changed and update only the part of the ui that changed, instead of rebuilding it from scratch
557 2013-03-03 15:59:13 <PRab> etotheipi_: Looks like the installer is currently an exe so I don't know if that would work directly, but thats the general idea.
558 2013-03-03 15:59:13 <TD> it may not be worthwhile. but then again, if you want to support very long transaction histories, it will become necessary
559 2013-03-03 15:59:24 <etotheipi_> PRab: thanks, I'll look into it
560 2013-03-03 15:59:47 <etotheipi_> this may be a bit of work...
561 2013-03-03 16:00:06 <PRab> everything worthwhile is...
562 2013-03-03 16:00:33 <etotheipi_> well sure... but I like things that aren't super-windows specfiic
563 2013-03-03 16:00:40 <Goonie> TD: ok then, some questions. If I call getTransactions() to get the initial state, how should I attach listeners so that I don't get a new transaction I already have and I also don't miss a tx?
564 2013-03-03 16:00:45 <etotheipi_> but yeah, I
565 2013-03-03 16:01:01 <etotheipi_> I'll look into it ... I don't pass up a solution that is exactly what I want
566 2013-03-03 16:01:10 <Goonie> TD: when a reorg is done, I don't get any changes I guess.
567 2013-03-03 16:01:31 <PRab> agreed, Windows lives out in its own little island.
568 2013-03-03 16:01:31 <TD> Goonie: there is an onReorganize() event. it's probably easiest to just rebuild everything then. re-orgs are rare.
569 2013-03-03 16:01:56 <lottoBTC> TO PLAY LOTTO BTC: http://www.lottobtc.com/
570 2013-03-03 16:02:09 <etotheipi_> I especially hate working with those damned "LPCTSTR" types, etc
571 2013-03-03 16:02:25 <TD> Goonie: if you use onCoinsReceived/onCoinsSent() then you get Transaction objects. you can add a listener to their confidence objects until they reach a point where the ui won't change anymore (like the circle is full). once that happens, the listener can just unregister itself.
572 2013-03-03 16:02:58 <TD> Goonie: if it helps, I can add a way to attach user-provided objects to Transaction objects. but it may be simpler for you to just have a HashMap<Transaction, ListRow> or whatever android uses
573 2013-03-03 16:03:26 <Goonie> TD: Android uses ListAdapters
574 2013-03-03 16:03:49 <etotheipi_> I already dealt with it once when trying to use the equivalent of mmap() in windows... it was a mess
575 2013-03-03 16:04:56 <Goonie> TD: I'll look into it, it might be worth it. The current code is really inefficient
576 2013-03-03 16:05:40 <PRab> I'm a windows developer, and even I don't like to mess with those things. I tend to try to stay in the comfort of the .Net framework.
577 2013-03-03 16:05:41 <etotheipi_> oh cool, I finally found an example of using MsiGetFileSignatureInformation ... from 1999
578 2013-03-03 16:08:22 <PRab> wow, I didn't even realize MSIs were that old. I never used them until late into XP (probably 2004-2005).
579 2013-03-03 16:08:35 <TD> Goonie: yeah. so I suppose what you need is to define your own adapter which contains a reference inside it to a Transaction, and when it's first created, it checks the confidence and if it thinks that tx will change, register a confidence listener. then when asked to provide a view it just examines the confidence object to do so. or it can copy the data it needs out so there's no chance of blocking.
580 2013-03-03 16:09:28 <TD> Goonie: sorry, I meant an ArrayAdapter, I guess
581 2013-03-03 16:09:47 <TD> Goonie: some events like a re-organize or loading a wallet would have to use getTransactions() and the rest would just update the list based on the callbacks.
582 2013-03-03 16:11:25 <TD> Goonie: longer term, the bitcoinj API is going to add another layer on top of transaction objects, it'll gain a notion of payments
583 2013-03-03 16:11:33 <TD> Goonie: where a payment may contain multiple transactions and other data.
584 2013-03-03 16:12:14 <TD> Goonie: but the API will probably be similar-ish
585 2013-03-03 16:13:06 <Goonie> TD: interesting
586 2013-03-03 16:13:11 <Goonie> TD: thanks for your input
587 2013-03-03 16:13:25 <TD> np
588 2013-03-03 16:14:06 <etotheipi_> PRab: all I see is references to calling it from C++... you think there's an executable that will do the same thing for me?
589 2013-03-03 16:14:43 <etotheipi_> I could make a simple C++ function that does it... and imports all the windows libraries
590 2013-03-03 16:14:58 <TD> http://www.ft.com/intl/cms/s/0/ca90f1b4-83ff-11e2-b700-00144feabdc0.html#axzz2MUvaXcOM
591 2013-03-03 16:15:04 <TD> interesting
592 2013-03-03 16:15:17 <etotheipi_> meh, I might as well just do the C++ thing... I have a 10k lines of C++ already, what's a few more? :)
593 2013-03-03 16:15:35 <PRab> Executable, I haven't heard of one, but that doesn't mean it doesn't exist.
594 2013-03-03 16:16:05 <etotheipi_> ahhh... so much to do, so little time...
595 2013-03-03 16:16:15 <PRab> I would tend to wrap the call you want into a DLL and then use that/
596 2013-03-03 16:16:33 <lottoBTC> TO PLAY LOTTO BTC: http://www.lottobtc.com/
597 2013-03-03 16:16:57 <etotheipi_> PRab: I'll just make some separate C++ calls and conditionally include them (via preprocessor)
598 2013-03-03 16:17:12 <etotheipi_> it's all going into a DLL
599 2013-03-03 16:17:18 <PRab> Sounds good to me.
600 2013-03-03 16:17:28 <etotheipi_> i mean, all 10k lines of code end up in a DLL, called from python anyway, I'll just add this
601 2013-03-03 16:18:20 <etotheipi_> oh crap, I missed the part where you mentioned it was an exe
602 2013-03-03 16:18:54 <PRab> Oh...
603 2013-03-03 16:19:22 <etotheipi_> oh, I bet it's just a zip file...
604 2013-03-03 16:19:40 <PRab> I was able to open it with 7-zip.
605 2013-03-03 16:20:12 <etotheipi_> gah, regular unzip does not work
606 2013-03-03 16:20:19 <lottoBTC> mimosa
607 2013-03-03 16:21:49 <kritCoin> is there a description of the blockchain fileformat?
608 2013-03-03 16:22:17 <etotheipi_> PRab: yeah, 7zip opens it, but I can't tell what algo it used
609 2013-03-03 16:23:11 <PRab> etotheipi_: click the "info" button
610 2013-03-03 16:23:19 <PRab> Looks like it is LZMA:23
611 2013-03-03 16:25:07 <etotheipi_> kritCoin: https://bitcointalk.org/index.php?topic=88208.msg1408092#msg1408092
612 2013-03-03 16:25:42 <etotheipi_> the files just repeat like that, each one starting with the magic bytes
613 2013-03-03 16:26:00 <PRab> etotheipi_: http://msdn.microsoft.com/en-us/library/aa382384%28VS.85%29.aspx
614 2013-03-03 16:26:20 <sipa> kritCoin: https://en.bitcoin.it/wiki/Protocol_Specification
615 2013-03-03 16:26:21 <etotheipi_> PRab: thanks!
616 2013-03-03 16:26:49 <sipa> kritCoin: the block files consist of the 4-byte network magic, a 4-byte length descriptor, and then a block in network serialized form
617 2013-03-03 16:53:27 <Scrat> Goonie: just converting a float to string and/or cutting off zeros in the end. if you're reading float after float then an integer all of a sudden throws you off, so 1 btc becomes 1.00
618 2013-03-03 16:53:35 <Scrat> Goonie: your client had the correct behavior last I checked
619 2013-03-03 16:53:41 <Scrat> was a few months ago tho
620 2013-03-03 16:55:46 <muhoo> ;;ticker
621 2013-03-03 16:55:47 <gribble> BTCUSD ticker | Best bid: 34.01767, Best ask: 34.24698, Bid-ask spread: 0.22931, Last trade: 34.01767, 24 hour volume: 11656.09846742, 24 hour low: 33.80000, 24 hour high: 34.37000, 24 hour vwap: 34.06139
622 2013-03-03 16:56:13 <muhoo> oh, that's kind of nice. the price has stabilized, but the volume looks like it's going through the roof. nice.
623 2013-03-03 16:59:15 <TD> muhoo: wealth being redistributed, it seems
624 2013-03-03 16:59:41 <muhoo> mtgox/coinbase merger?
625 2013-03-03 16:59:59 <TD> nah, things were taking off before that too
626 2013-03-03 17:00:33 <TD> i don't see a big volume spike, though, looking at the homepage graphs
627 2013-03-03 17:00:34 <etotheipi_> PRab: you think there's a way to to adapt that code to expect a given signer? it seems that it will check whether there is *a* valid sig traceable to a root CA, but it would pass if it was replaced with any other sig traceable to a root CA
628 2013-03-03 17:02:23 <muhoo> oic, the volume isn't a spike, i just haven't noticed in a while.
629 2013-03-03 17:03:20 <etotheipi_> PRab: actually, the first thing the app does when you try to install it is pop up a UAC window saying "Verified publisher: The Bitcoin Foundation, Inc"... perhaps that's enough in and of itself, to tell the user to verify that before continuing
630 2013-03-03 17:04:35 <etotheipi_> if UAC is compromised, then there's not much I could do to save that user
631 2013-03-03 17:32:51 <PRab> etotheipi_: I don't know if I would trust UAC for that purpose. It would tell the user that they are running a signed exe, but the user wouldn't know/care who was supposed to sign the exe (attacker could just sign malicious exe).
632 2013-03-03 17:33:17 <etotheipi_> PRab: I guess the question is, is it any worse than the user doing it themselves?
633 2013-03-03 17:33:53 <etotheipi_> would malicious attacker be able to get a CA-signed cert with a name very close to "The Bitcoin Foundation, Inc"?
634 2013-03-03 17:34:28 <PRab> If you are trusting the user to do it themselves, I would just provide a link to the download.
635 2013-03-03 17:34:29 <sipa> i wouldn't depend on it not being able to do so
636 2013-03-03 17:34:34 <etotheipi_> I guess it would be idea for me to hard-code the cert
637 2013-03-03 17:34:38 <etotheipi_> *ideal*
638 2013-03-03 17:35:00 <PRab> Thats what I was assuming you would do.
639 2013-03-03 17:35:18 <etotheipi_> PRab: yeah, I'm just overwhelmed by all the windows-ness
640 2013-03-03 17:35:27 <etotheipi_> looking for excuses to not do it :)
641 2013-03-03 17:35:55 <etotheipi_> but you're right, asking the user to do anything here is not good
642 2013-03-03 17:35:56 <ThomasV> hi etotheipi_ ; any news concerning bip32 approval?
643 2013-03-03 17:35:59 <PRab> This is all 100% windows exclusive.
644 2013-03-03 17:36:15 <sipa> ThomasV: no
645 2013-03-03 17:36:28 <sipa> sorry for the delay, i've been busy
646 2013-03-03 17:36:44 <ThomasV> sipa: no problem.
647 2013-03-03 17:37:59 <kritCoin> bfgminer was made soly for eligius?
648 2013-03-03 17:38:54 <PRab> etotheipi_: You can always count on users just clicking "Next" without regard for security implications. IMO, it either needs to be truly secure (validate sigs, etc.) or just provide recommended directions on how to preform an action (provide a link to to bitcoind).
649 2013-03-03 17:38:57 <sipa> bfgminer is a fork of cgminer, which is a fork of cpuminer
650 2013-03-03 17:39:38 <etotheipi_> PRab: yeah, I was thinking of popping up a warning just before starting the installer and that's all it said was to verify that...
651 2013-03-03 17:39:46 <etotheipi_> but I agree, if I'm going to do it at all, I should just do it 100%
652 2013-03-03 17:40:11 <PRab> etotheipi_: +1
653 2013-03-03 17:40:35 <etotheipi_> I just don't want to deal with LPCWSTRs ever again
654 2013-03-03 17:40:38 <sipa> any system that relies on telling the user what to verify is flawed, imho
655 2013-03-03 17:40:48 <sipa> as an attacker will tell the user something else
656 2013-03-03 17:40:54 <etotheipi_> sipa: so the current state of bitcoin is, too
657 2013-03-03 17:41:14 <kritCoin> i cant find a binary good description of blockchain
658 2013-03-03 17:41:18 <sipa> unfortunately
659 2013-03-03 17:41:20 <etotheipi_> there's always compromises to be made... but I agree this is not a place for me to compromised
660 2013-03-03 17:41:22 <etotheipi_> *compromise
661 2013-03-03 17:41:28 <sipa> kritCoin: i gave you the link
662 2013-03-03 17:41:30 <kritCoin> does anyone have a good source on github
663 2013-03-03 17:41:46 <kritCoin> sipa, cool
664 2013-03-03 17:43:23 <kritCoin> sipa a link would be nice)
665 2013-03-03 17:46:53 <etotheipi_> kritCoin: I gave you a link above (very very simple explanation of the binary structure of the blockfile), sipa gave you a link right after that with the full specification
666 2013-03-03 17:47:26 <kritCoin> i dont like simple links
667 2013-03-03 17:47:55 <kritCoin> i didnt see sipas link if he gave one lemmi look
668 2013-03-03 17:48:40 <etotheipi_> kritCoin: my explanation was simple because the file format is stupid-simple... if you already know how headers and tx are serialized
669 2013-03-03 17:49:40 <sipa> kritCoin: then scroll up
670 2013-03-03 17:49:41 <kritCoin> unfortunatly one would never know because,..., the dont know before hand, chicken and egg thing
671 2013-03-03 17:49:59 <kritCoin> circular reasoning
672 2013-03-03 17:50:06 <kritCoin> i read the wiki now
673 2013-03-03 17:50:24 <kritCoin> the full description is better, thanks sipa
674 2013-03-03 17:50:29 <sipa> kritCoin: the block files just consists of a concatenation of 'block' structures, prefixed with a network magic and length descriptor
675 2013-03-03 18:03:48 <kritCoin> i installed bitcoin qt version
676 2013-03-03 18:03:50 <kritCoin> i looked in program files/bitcoin
677 2013-03-03 18:03:53 <kritCoin> where do i find the blockchain?
678 2013-03-03 18:04:03 <kritCoin> i dont see it
679 2013-03-03 18:09:10 <sipa> kritCoin: they are stored in the datadir, search for datadir on the wiki, it tells you where it is on several OS'es
680 2013-03-03 18:09:20 <sipa> also, can you take this to #bitcoin ?
681 2013-03-03 18:10:55 <kritCoin> i would rather stay in bitcoin-dev
682 2013-03-03 18:11:25 <kritCoin> to much nonsense in bitcoin3
683 2013-03-03 18:11:29 <kritCoin> to much nonsense in bitcoin#
684 2013-03-03 18:11:47 <gmaxwell> You're welcome to stay in #bitcoin-dev, but take the basic tech support to #bitcoin. If nonsense gets in your way I'll kick it out of there.
685 2013-03-03 18:13:29 <kritCoin> you own bitcoin-dev?
686 2013-03-03 18:13:44 <TD> he's an op
687 2013-03-03 18:14:09 <kritCoin> i dont see him opping in dev
688 2013-03-03 18:14:19 <TD> happy now?
689 2013-03-03 18:15:00 <gmaxwell> Shall I banforward you to #bitcoin now? geesh. I wasn't trying to be rude, but really??? the basic stuff should be in #bitcoin, it'll help keep the stupid on a low boil in there.
690 2013-03-03 18:15:22 <kritCoin> i like to become dev active
691 2013-03-03 18:15:42 <kritCoin> so i think my questions about c- coding etc belong here
692 2013-03-03 18:15:42 <sipa> also, you are welcome to ask questions here if they are about more internal stuff
693 2013-03-03 18:15:43 <ThomasV> kritCoin: I'm looking forward to it
694 2013-03-03 18:16:13 <_chrisftw_> hey dudes,whats the average time at the moment for an exchange to process a transaction? assuming a minimum fee payment?
695 2013-03-03 18:16:37 <sipa> define 'process' ?
696 2013-03-03 18:17:25 <PRab> ;;goxlag
697 2013-03-03 18:17:26 <gribble> 0 seconds
698 2013-03-03 18:18:01 <_chrisftw_> well i sent a payment to coinbase - but it still says pending - after 15 minutes
699 2013-03-03 18:18:07 <_chrisftw_> am I doing something wrong?
700 2013-03-03 18:18:12 <TD> a payment of what?
701 2013-03-03 18:18:14 <TD> bitcoins?
702 2013-03-03 18:18:21 <sipa> well they probably wait for the transaction to confirm
703 2013-03-03 18:18:30 <_chrisftw_> yes, from one address to a coinbase address both mine
704 2013-03-03 18:18:38 <sipa> which may take an hour or so
705 2013-03-03 18:18:50 <_chrisftw_> thank you sipa - is there anyway to drastically reduce this?
706 2013-03-03 18:18:55 <_chrisftw_> building a site you see
707 2013-03-03 18:18:57 <sipa> processing on the side of the receiver is instant apart from that
708 2013-03-03 18:19:04 <_chrisftw_> oh
709 2013-03-03 18:19:10 <TD> _chrisftw_: bitcoin payments become visible in seconds
710 2013-03-03 18:19:18 <_chrisftw_> right
711 2013-03-03 18:19:26 <TD> _chrisftw_: it's up to the recipient how long to wait before deciding that it's safe to use
712 2013-03-03 18:19:34 <_chrisftw_> so I assume a tran confirm takes place after the next block is erm mined?
713 2013-03-03 18:19:44 <TD> _chrisftw_: exchanges are the most obvious targets for double spend fraud so they tend to be conservative.
714 2013-03-03 18:19:49 <sipa> yes, typically after 6 blovks
715 2013-03-03 18:19:51 <sipa> blocks
716 2013-03-03 18:20:03 <TD> _chrisftw_: they can wait as long as they like. gox waits for 6 == ~1 hr
717 2013-03-03 18:20:04 <_chrisftw_> and a block is mined once every 15 mins or so
718 2013-03-03 18:20:08 <gmaxwell> _chrisftw_: you should ask coinbase to process coinbase to coinbase transactions internally and instantly.
719 2013-03-03 18:20:16 <TD> in theory you could have an exchange where deposits are instant, but i'd not recommend it
720 2013-03-03 18:20:26 <_chrisftw_> ok
721 2013-03-03 18:20:44 <_chrisftw_> so I need to understandthe "double spend problem" which is fought by delaying confirmations by an hour
722 2013-03-03 18:20:52 <_chrisftw_> thanks guys
723 2013-03-03 18:21:51 <sipa> _chrisftw_: the bitcoin block chain system makes sure that the world obtains one single globally consist view on the order of transactions, where no transacrion conflicts with another (spending the same funds twice)
724 2013-03-03 18:21:52 <TD> that is again, possibly more appropriate for #bitcoin
725 2013-03-03 18:22:18 <sipa> however it doesn't guarantee this immediately - nodes may temporarily disagree about the order of recent events
726 2013-03-03 18:22:41 <sipa> however, the longer you wait, it becomes rxponentially less likely for disagreement to remain
727 2013-03-03 18:24:07 <nanotube> TD: so... being a googlian, you could be a good person to ask: what's your thought on trying to get bitcoin into gsoc2013?
728 2013-03-03 18:25:17 <TD> neat idea
729 2013-03-03 18:25:27 <TD> go for it