1 2013-02-17 00:00:06 <alex_fun> belongs to main chain
  2 2013-02-17 00:00:12 <alex_fun> some exchgange might use alt chain btc
  3 2013-02-17 00:00:18 <muhoo> iirc there's nothing in btc stopping offchain txs.
  4 2013-02-17 00:00:26 <alex_fun> petertodd i dont know I say few use it
  5 2013-02-17 00:02:13 <Eliel_> alex_fun: anyone can set up a website that pretends to be a bitcoin wallet even without an alt chain.
  6 2013-02-17 00:02:37 <alex_fun> Eliel_ yes however then they wont get any btc and start alerting
  7 2013-02-17 00:02:45 <alex_fun> however if someone like electrum
  8 2013-02-17 00:02:55 <alex_fun> put servers to serve large alt chain :)
  9 2013-02-17 00:04:05 <alex_fun> is there some algo that uses only 1 chain
 10 2013-02-17 00:05:03 <gmaxwell> this seems OT for #bitcoin-dev
 11 2013-02-17 00:05:25 <alex_fun> its a question how btc work
 12 2013-02-17 00:05:31 <alex_fun> to understand how it really work
 13 2013-02-17 00:05:38 <alex_fun> and its limitations
 14 2013-02-17 00:05:38 <muhoo> heading that way
 15 2013-02-17 00:07:10 <gmaxwell> alex_fun: Then ask specific technical questions, take economic or social hypothesizing to #bitcoin
 16 2013-02-17 00:07:10 <rdponticelli> alex_fun: You have a lot of research to do before even think about going on with your idea....
 17 2013-02-17 00:07:44 <alex_fun> gmaxwell I ask if I am using say electrum serves how do I check that they use main chain?
 18 2013-02-17 00:07:47 <alex_fun> what do I do?
 19 2013-02-17 00:07:53 <alex_fun> *servers
 20 2013-02-17 00:08:05 <sipa> if you have that question, you shouldn't be using it
 21 2013-02-17 00:08:15 <sipa> the point is that ultimately you trust their server
 22 2013-02-17 00:08:41 <alex_fun> then is technically weak point
 23 2013-02-17 00:08:43 <sipa> (though there is some - and increasing - degree of local checking)
 24 2013-02-17 00:08:48 <alex_fun> if it relies on trust alone
 25 2013-02-17 00:09:08 <sipa> recently they added SPV level verification
 26 2013-02-17 00:09:28 <sipa> so the client can check that the block chain they serve is valid
 27 2013-02-17 00:09:34 <alex_fun> cool
 28 2013-02-17 00:09:53 <sipa> which doesn't mean it guarantees it's the *right* chain, only a valid one
 29 2013-02-17 00:10:05 <sipa> but that is the same sort of guarantee you have with real SPV clients
 30 2013-02-17 00:10:18 <sipa> except those connect to random nodes on the network, and not a special server
 31 2013-02-17 00:11:34 <Eliel_> alex_fun: if you don't want to have to trust that someone else's server is using the bitcoin blockchain, your only option is to run a full bitcoin node yourself.
 32 2013-02-17 00:12:09 <alex_fun> eliel I was thinking if there is a way to make btc and likes even more secure
 33 2013-02-17 00:12:19 <sipa> no need for that
 34 2013-02-17 00:12:22 <alex_fun> I found some paper about it however understood only some
 35 2013-02-17 00:12:30 <sipa> all guarantee you can get you have in SPV mode
 36 2013-02-17 00:12:36 <alex_fun> I am going going to check ripple
 37 2013-02-17 00:12:37 <alex_fun> seems nice
 38 2013-02-17 00:12:52 <alex_fun> to me p2p currency seems simple in theory and tough  in practice :D
 39 2013-02-17 00:13:16 <jgarzik> tough in theory and tougher in practice
 40 2013-02-17 00:14:02 <alex_fun> jgarzik what if there could be a token, whose ownership can be transfered unrevocably with a key?
 41 2013-02-17 00:14:14 <sipa> you mean a bitcoin?
 42 2013-02-17 00:14:24 <alex_fun> and once key is used its no longer working for party a
 43 2013-02-17 00:14:33 <alex_fun> well I mean something simple
 44 2013-02-17 00:14:33 <sipa> you mean a bitcoin?
 45 2013-02-17 00:14:35 <petertodd> alex_fun: how do you make the key not work?
 46 2013-02-17 00:14:47 <gmaxwell> 17:07 < alex_fun> gmaxwell I ask if I am using say electrum serves how do I check  that they use main chain?
 47 2013-02-17 00:14:59 <alex_fun> petertodd I moment I am thinking
 48 2013-02-17 00:15:02 <alex_fun> 1
 49 2013-02-17 00:15:20 <gmaxwell> The electrum client software actually checks that it uses the correct chain history, but it can't tell if its on the longest chain because it trusts the server completely.
 50 2013-02-17 00:16:00 <sipa> alex_fun: the correct answer is: the only way to make sure a key only works once, is by making sure that everyone rejects the second attempt
 51 2013-02-17 00:17:04 <gritcoin> 0.8rc test report (initial sync performance): 2h15m for initial sync on a clean install of windows 0.8.0rc1 build on unremarkable hardware! Nice!
 52 2013-02-17 00:17:26 <sipa> i find that very slow, but glad that people are happy :p
 53 2013-02-17 00:17:45 <alex_fun> ok I got an idea
 54 2013-02-17 00:18:01 <alex_fun> ownership is defined by latest pgp signature
 55 2013-02-17 00:18:05 <gritcoin> well, relative change can be a source of happiness :)
 56 2013-02-17 00:18:08 <alex_fun> something like that
 57 2013-02-17 00:18:11 <sipa> alex_fun: define 'latest'
 58 2013-02-17 00:18:20 <gritcoin> 0.7.2 was ~36 hours on same hardware and same net connection.
 59 2013-02-17 00:19:17 <petertodd> alex_fun: don't say by timestamping, Satoshi's paper itself calls Bitcoin a timestamping system.
 60 2013-02-17 00:19:40 <MobGod> sipa question for you
 61 2013-02-17 00:19:50 <alex_fun> for example I make file coin.txt and sign it with public key saying 1, then when I sell to you I sell you private key
 62 2013-02-17 00:19:59 <MobGod> does gpgtools when running take up a lot of disk space
 63 2013-02-17 00:20:00 <alex_fun> so u can sign coin.tx and say 2
 64 2013-02-17 00:20:09 <alex_fun> then its clear more less
 65 2013-02-17 00:20:32 <petertodd> Only to those who know tx #2 exists.
 66 2013-02-17 00:20:48 <sipa> MobGod: ?
 67 2013-02-17 00:20:53 <sipa> what is gpgtools?
 68 2013-02-17 00:21:04 <alex_fun> the private key controls ability to sign ownership, if I sell private key to you would I be able to use it too or not?
 69 2013-02-17 00:21:08 <MobGod> one sec
 70 2013-02-17 00:21:10 <MobGod> sorry
 71 2013-02-17 00:21:20 <alex_fun> tricky :D
 72 2013-02-17 00:21:30 <alex_fun> however totally doable
 73 2013-02-17 00:21:31 <sipa> alex_fun: you haven't answered to petertodd's remark
 74 2013-02-17 00:21:39 <alex_fun> sipa i am thinking
 75 2013-02-17 00:21:57 <alex_fun> it takes effort for me to invent from scract
 76 2013-02-17 00:22:02 <sipa> alex_fun: 'latest' is not something two spatially distant entities will always agree on
 77 2013-02-17 00:22:03 <alex_fun> as I dont know know alot
 78 2013-02-17 00:22:13 <sipa> alex_fun: as information takes time to travel
 79 2013-02-17 00:22:38 <petertodd> alex_fun: Hundreds of cryptographers have been thinking about this problem too.
 80 2013-02-17 00:22:45 <gritcoin> sipa, "[17:18] <@gmaxwell> gritcoin: perhaps nag sipa to put up his charting code." -- I have "some" experience in location estimation for inhomogeneous poisson processes and am planning on working on network hashrate estimate, but don't want to recapitulate existing work.
 81 2013-02-17 00:22:49 <alex_fun> ok what if there is only 1 key to unlock and lock, and token can be transfered only when unlocked
 82 2013-02-17 00:22:57 <alex_fun> then sale is sale of key
 83 2013-02-17 00:23:08 <alex_fun> and key itself have to change its propertied during sale
 84 2013-02-17 00:23:11 <sipa> alex_fun: so one entity may hear about one (valid) signature first, and another entity may hear about another valid signature
 85 2013-02-17 00:23:21 <petertodd> alex_fun: How do you determine if the token is locked or unlocked?
 86 2013-02-17 00:23:25 <sipa> alex_fun: that is the fundamental problem that bitcoin solves
 87 2013-02-17 00:23:31 <sipa> alex_fun: and it's very hard one
 88 2013-02-17 00:23:53 <alex_fun> so how does it work with satoshi algo?
 89 2013-02-17 00:24:17 <petertodd> sipa: ...and Bitcoin only solves it in the practical sense. PoW is an ugly, yet beautiful, hack.
 90 2013-02-17 00:24:29 <petertodd> alex_fun: lol, you don
 91 2013-02-17 00:24:34 <petertodd> *don't already know that?
 92 2013-02-17 00:24:43 <alex_fun> yes I dont know
 93 2013-02-17 00:24:44 <sipa> yes, it solves it by weakening the problem
 94 2013-02-17 00:25:03 <petertodd> alex_fun: Go find out before you waste our time any further.
 95 2013-02-17 00:25:06 <sipa> alex_fun: you'll need to read more about how bitcoin works then
 96 2013-02-17 00:25:15 <alex_fun> i read
 97 2013-02-17 00:25:22 <sipa> it's explained in the paper
 98 2013-02-17 00:25:28 <alex_fun> it says it solving hash and its generates proof of work
 99 2013-02-17 00:25:38 <alex_fun> each pow is = reward
100 2013-02-17 00:25:48 <sipa> not that part
101 2013-02-17 00:26:00 <mloftis> alex_fun: basically you transfer ownership to a new (public) key by signing a transaction that states that.  you cannot guarentee someones NOT retained a copy of a private key
102 2013-02-17 00:26:02 <petertodd> alex_fun: The fact that PoW is a reward is not a fundemental part of Bitcoin.
103 2013-02-17 00:26:15 <alex_fun> i know petertodd
104 2013-02-17 00:26:29 <mloftis> alex_fun: so you just assign ownership to a new public key...there's also ways of performing contracts in bitcoin, documentation on such is available on the wiki.
105 2013-02-17 00:26:30 <alex_fun> mloftis makes sense
106 2013-02-17 00:26:30 <sipa> gritcoin: not sure if my code will help you that much :)
107 2013-02-17 00:27:07 <alex_fun> mloftis if there is no guarantee that party a release private key
108 2013-02-17 00:27:10 <alex_fun> then ooo I got it
109 2013-02-17 00:27:21 <alex_fun> the block chain itself is like central bank
110 2013-02-17 00:27:25 <mloftis> alex_fun: yup
111 2013-02-17 00:27:29 <alex_fun> it records transactions in time
112 2013-02-17 00:27:29 <alex_fun> right?
113 2013-02-17 00:27:35 <sipa> not in time
114 2013-02-17 00:27:36 <mloftis> alex_fun: and since all the nodes "Agree" on the longes chain wins.
115 2013-02-17 00:27:39 <alex_fun> yay!
116 2013-02-17 00:27:49 <alex_fun> now I can tell girls in bar how it works :D
117 2013-02-17 00:27:52 <sipa> but it defines an authorative order for otherwise valid transactions
118 2013-02-17 00:28:07 <mloftis> alex_fun: but not in time...more like in sequence for a given ownership transfer chain.
119 2013-02-17 00:28:21 <sipa> such that in the case of two attempted spends of the same coin, people agree on who is the right one
120 2013-02-17 00:28:22 <mloftis> sipa said it better i think LOL
121 2013-02-17 00:28:26 <gritcoin> sipa: Cool, I'll just dive in then :) Already notice that the timestamp variations mean the in-block times can't be used to derive arrival intervals, and the blockchain.info "first_time" in their block inventory is weird as well (lots of inverted arrivals vs. height and multiple blocks with same "first_time" value
122 2013-02-17 00:29:00 <alex_fun> mloftis so when I send 1 btc client looks at all chain to see if I am the latest owner
123 2013-02-17 00:29:05 <alex_fun> and if yes it sends it?
124 2013-02-17 00:29:14 <sipa> gritcoin: i use the block timestamps; those are indeed flexible in a way, but only up to 2 hours
125 2013-02-17 00:29:21 <mloftis> alex_fun: sort of.  it knows whats in your wallet because it follows the chain.
126 2013-02-17 00:29:45 <sipa> gritcoin: the idea behind my graphs is this: assume there is a poisson-like process that generates block events
127 2013-02-17 00:29:52 <sipa> gritcoin: hash events, actually
128 2013-02-17 00:30:02 <gritcoin> true enough. And any estimate for time periods less than two hours are going to be pretty meaningless anyway
129 2013-02-17 00:30:03 <alex_fun> and becouse agreed chain is hosted on each client its decentralised
130 2013-02-17 00:30:04 <alex_fun> nice :D
131 2013-02-17 00:30:04 <mloftis> alex_fun: and makes a note when it detects something "given up" (by way of a valid transaction, which ANYONE can verify, by virtue of the way public key crypto works)
132 2013-02-17 00:30:29 <mloftis> I can verify that "yes key A did indeed sign over to key B"  as a third party observer,t hats the beauty of public key crypto.
133 2013-02-17 00:30:36 <sipa> gritcoin: however, it's a poisson-like process with a generation rate that itself is an exponential function of time
134 2013-02-17 00:31:13 <mloftis> alex_fun: more to it than that, but thats the basic idea.
135 2013-02-17 00:31:32 <sipa> gritcoin: so at any point in time T, we assume that the hash events before T were generated by a poissoin process whose generation rate was f(t) = A*exp(B*t), for t<T
136 2013-02-17 00:31:35 <gritcoin> sipa: My initial direction is to treat block generation as a doubly stochastic poisson process with a rate function that is a pinned brownian walk (miner offline/online events act as random walk against total hashrate)
137 2013-02-17 00:31:58 <gritcoin> where the pinning values will follow a function like yours
138 2013-02-17 00:32:18 <mloftis> alex_fun: the key/trick is that a majority of nodes agree on what is valid, based on an agreed upon set of rules.  And transfer of ownership (of a bitcoin) takes place by signing transactions.  those transactions are made permanent as they get buried into the block chain.
139 2013-02-17 00:32:27 <gritcoin> with the walk bandpass filtered to match a miner participation model
140 2013-02-17 00:33:01 <sipa> gritcoin: so I derived a way to calculate a maximum-likelyhood estimation for A and B, given the observed hash events (a block event counts as simultaneous D hash events, with D = block difficulty)
141 2013-02-17 00:33:04 <alex_fun> mloftis and how does btc chain sign them?
142 2013-02-17 00:33:10 <gmaxwell> majority of hashpower, subtle difference??? we can't use 'majority of nodes' because nothing would stop a badguy from spinning up his own fake majority. ... and a majority of nodes doesn't leave a record of their existance nodes in the future can trust.
143 2013-02-17 00:33:16 <alex_fun> i know coins move by solving hash right?
144 2013-02-17 00:33:30 <sipa> alex_fun: transactions have nothing to do with proof of work
145 2013-02-17 00:33:32 <alex_fun> of if I send coin no hash have to be solved for transaction
146 2013-02-17 00:33:37 <alex_fun> sipa ok cool
147 2013-02-17 00:33:47 <alex_fun> so if I send coins to you, how do they travel
148 2013-02-17 00:33:49 <sipa> alex_fun: a transaction is a fully message saying "transfer coin X to new address A"
149 2013-02-17 00:33:53 <sipa> that's all
150 2013-02-17 00:33:59 <sipa> * fully signed
151 2013-02-17 00:34:01 <alex_fun> ok from address to address
152 2013-02-17 00:34:10 <alex_fun> and how are they signed?
153 2013-02-17 00:34:11 <sipa> (that's a major simplification, but it will do for now)
154 2013-02-17 00:34:13 <sipa> ECDSA
155 2013-02-17 00:34:14 <mloftis> alex_fun: miners try to solve a problem, basically, find data to mix in to the list of transactions such that the hash has a specific property...in our case we're looking for a number that falls inside of a given range...we all agree on the range based on the rules of the network.
156 2013-02-17 00:34:20 <sipa> a cryptographic algorithm
157 2013-02-17 00:34:27 <mloftis> alex_fun: thats how PoW goes.
158 2013-02-17 00:34:59 <gritcoin> sipa: very reasonable.
159 2013-02-17 00:35:04 <Zarutian> mloftis: which reminds be of the SAT solver thing
160 2013-02-17 00:35:07 <sipa> alex_fun: if not for the double-spending problem where two people in the world could create simultaneously two different but conflicting valid transactions, that would be the end of the story
161 2013-02-17 00:35:17 <alex_fun> yep
162 2013-02-17 00:35:21 <sipa> alex_fun: but we need a way to authoratively order transactions
163 2013-02-17 00:35:26 <sipa> and that is what the block chain does
164 2013-02-17 00:35:42 <sipa> it's just an ordered list of transactions, grouped together in blocks
165 2013-02-17 00:35:48 <sipa> with each block referring to a previous block
166 2013-02-17 00:36:03 <sipa> and since it's hard to make a block, we can control how quickly they are generated
167 2013-02-17 00:36:17 <alex_fun> so address that sold 10 coins is minus 10 coins right?
168 2013-02-17 00:36:20 <alex_fun> in the chain
169 2013-02-17 00:36:26 <alex_fun> and address that got 10 coins is plus 10
170 2013-02-17 00:36:37 <sipa> yes, but in practice that's not how it works
171 2013-02-17 00:36:43 <alex_fun> like basic double entry bookkeeping bases on blokchain
172 2013-02-17 00:36:46 <sipa> the system doesn't keep track of a balance per address
173 2013-02-17 00:36:58 <sipa> a transaction consumes coins, and produces coins
174 2013-02-17 00:37:03 <sipa> and a coin is either spent or unspent
175 2013-02-17 00:37:09 <alex_fun> hmm I though I am sending btc from address
176 2013-02-17 00:37:14 <sipa> never something in between
177 2013-02-17 00:37:23 <alex_fun> yes double entry
178 2013-02-17 00:37:24 <sipa> yes, that's the abstraction the wallet software provides
179 2013-02-17 00:37:27 <alex_fun> debit credit
180 2013-02-17 00:37:31 <sipa> but it's not how it works internally
181 2013-02-17 00:37:55 <alex_fun> ok so internally how does block chain identifies me as holder of say 100 btc?
182 2013-02-17 00:37:57 <Zarutian> can other things, not fungible or dividable, be transfered in this way? (titles, and other such stuff)
183 2013-02-17 00:38:14 <mloftis> alex_fun: it doesn't ... the wallet has to walk the chain to find that out.
184 2013-02-17 00:38:36 <alex_fun> Zarutian yes provided it does not require gov approval to transfer owndership
185 2013-02-17 00:38:36 <sipa> alex_fun: if the chain defines a transaction with a 100 BTC output coin to you, and no transaction that consumes it afterwards
186 2013-02-17 00:38:39 <alex_fun> say house or car
187 2013-02-17 00:38:51 <alex_fun> sipa makes sense
188 2013-02-17 00:39:02 <alex_fun> what is my ultimate identifier in chain?
189 2013-02-17 00:39:03 <alex_fun> IP?
190 2013-02-17 00:39:05 <alex_fun> key?
191 2013-02-17 00:39:09 <sipa> address
192 2013-02-17 00:39:17 <sipa> which is the hash of a public key
193 2013-02-17 00:39:43 <sipa> gritcoin: i use an exponential window to measure the data the MLE algorithm uses to calculate A and B
194 2013-02-17 00:39:49 <sipa> which varying with
195 2013-02-17 00:40:04 <sipa> gritcoin: turns out, this becomes almost trivial formulas
196 2013-02-17 00:40:16 <gritcoin> And the varying width generates the different windows for the plots?
197 2013-02-17 00:40:26 <sipa> correct
198 2013-02-17 00:40:46 <gritcoin> k
199 2013-02-17 00:41:24 <gritcoin> Very succinct summary; I appreciate it.
200 2013-02-17 00:41:32 <muhoo> addresses, pliral
201 2013-02-17 00:41:33 <sipa> so, what you need to measure is: N = the number of events (weighted by the exponential window)
202 2013-02-17 00:41:46 <Zarutian> alex_fun: I was thinking about UUIDs that smart electronic locks that listen to the bitcoin node network look for. Basicly a lock looks for which public key is the *holder* of the uuid and opens when the corrisponding private key signs a challange from the lock.
203 2013-02-17 00:41:51 <sipa> and T, the average time since each event
204 2013-02-17 00:43:18 <sipa> gritcoin: the window function is t->exp((t-T)/Tau)/Tau, with t<T
205 2013-02-17 00:43:51 <sipa> gritcoin: and the assumed hashrate function is t->A*exp(B*(t-T)/Tau)
206 2013-02-17 00:44:04 <sipa> (Tau = exponential window size)
207 2013-02-17 00:44:13 <Zarutian> (basicly abusing the blockchain to be an updateable ACL where the subjects are addresses and the objects are UUIDs)
208 2013-02-17 00:44:23 <gritcoin> right
209 2013-02-17 00:44:45 <sipa> gritcoin: and T is the average time since each event, measured in units of Tau
210 2013-02-17 00:44:58 <sipa> wait, i'm using T is two different meanings
211 2013-02-17 00:45:24 <sipa> call the average time since each event, measured in units of Tau: A
212 2013-02-17 00:46:11 <mloftis> Zarutian: one of the only issues i see with that is if several changes are made before a block or blocks happen.  until somethings solidified into the block chain it's really just indicating "intent"
213 2013-02-17 00:46:25 <sipa> so A=3 N=5 would mean you've seen 5 hash events in your window, and their average time is T-3*Tau
214 2013-02-17 00:46:28 <sipa> gritcoin: ok?
215 2013-02-17 00:46:54 <mloftis> Zarutian: the netowrk can lose or forget about a transaction that doesn't make it into the block chain...at least in theory...idk if this happens in practice once a transaction gets relayed.
216 2013-02-17 00:47:04 <gritcoin> Yep
217 2013-02-17 00:47:27 <alex_fun> win updates restart happen
218 2013-02-17 00:47:29 <alex_fun> :)
219 2013-02-17 00:47:35 <Zarutian> mloftis: that is an issue I do not know how to resolve
220 2013-02-17 00:47:38 <sipa> gritcoin: grr, and now i'm using A with two meanings
221 2013-02-17 00:47:47 <gritcoin> yeah I see that :) but I follow
222 2013-02-17 00:48:03 <sipa> i'll call the average age just Age
223 2013-02-17 00:48:24 <gritcoin> a/b as mle parameters for hashrate function vs. a as mean T
224 2013-02-17 00:48:38 <sipa> ok, so in that case: A = N/Age, B = 1/Age - 1
225 2013-02-17 00:48:41 <alex_fun> I disconnect when I asked what is the core identifier between wallet.dat and chain?
226 2013-02-17 00:48:47 <mloftis> Zarutian: yeah idk if ya really can within bitcoin.  in reality nothing is absolutely certain...just more and more sure :)  it's ALL probabilities of some sort... gritcoin and sipa there I'm sure have a better term for it ... they seem to be the resident stats at the moment.
227 2013-02-17 00:48:58 <Zarutian> mloftis: block-timed activation of changes? that is such an transaction would say, "I am not to be acted upon until I am x deep in the block chain"
228 2013-02-17 00:49:19 <alex_fun> Zarutian you talking about contracts right?
229 2013-02-17 00:49:32 <sipa> gritcoin: so this gives you, for a given window ending at a certain timestamp, an estimated hashrate function
230 2013-02-17 00:49:54 <gritcoin> nice, yeah, that is quite clean
231 2013-02-17 00:49:55 <Zarutian> alex_fun: not yet. Only the stuff that contract might be able to be about.
232 2013-02-17 00:49:56 <sipa> gritcoin: and you use that hashrate function to 'extrapolate' to the current time, resulting in a guess for the current hash rat
233 2013-02-17 00:50:03 <mloftis> Zarutian: yeah and thats how most implementations work now, see a certain # of confirmations, IE a block plus N blocks behind it/built on it.
234 2013-02-17 00:50:21 <sipa> gritcoin: and if you do the math, the result is the current estimated hashrate (at t=T) is N/Age
235 2013-02-17 00:51:11 <Zarutian> mloftis: twenty minutes wait when houses/cars are traded might be toleratable
236 2013-02-17 00:51:21 <alex_fun> mloftis what is the identifier inside block.dat ?
237 2013-02-17 00:51:26 <alex_fun> the one chain uses
238 2013-02-17 00:51:30 <gritcoin> right, which is actually the MLE of stationary poisson process with average rate N/Age -- but you have additionally constructed a rate function for extrapolation
239 2013-02-17 00:51:36 <alex_fun> the rest I understand already :D
240 2013-02-17 00:52:15 <mloftis> alex_fun: IDK about any of the on disk stuff with bitcoind, I've avoided it.  It has been painful enough trying to understand the serialization of the protocol and blocks LOL
241 2013-02-17 00:52:32 <alex_fun> lol
242 2013-02-17 00:52:37 <alex_fun> ty
243 2013-02-17 00:52:54 <mloftis> alex_fun: each block though is identified by the merkle root.
244 2013-02-17 00:55:25 <sipa> gritcoin: right, exactly
245 2013-02-17 00:55:32 <sipa> gritcoin: though i only use it at one point
246 2013-02-17 00:55:42 <gritcoin> right
247 2013-02-17 01:01:36 <gritcoin> sipa, http://www.columbia.edu/~ww2040/rate.pdf is a very similar approach but assuming a rate function which is piecewise linear
248 2013-02-17 01:03:00 <gritcoin> they have some good discussion about how to choose the size and number of measurement intervals (they also differ in that the are using a square window)
249 2013-02-17 01:04:22 <dhill> so i guess i can't get bitcoind to crash anymore.  hrm.  pretty sure it is a lock/thread issue.
250 2013-02-17 01:04:56 <dhill> slowing it down has resulted in no crashes today.
251 2013-02-17 01:07:33 <FellowTraveler> Hi all, just FYI, I'm in San Fran tonight for one night only. I won't be online so there'll be no way to reach me. But I'll be in the city, walking among you.
252 2013-02-17 01:08:26 <gmaxwell> Why do you assume that anyone here is in San Fran?   Or do you just mean that you'll be on earth among us? :P
253 2013-02-17 01:08:41 <Luke-Jr> lol
254 2013-02-17 01:09:12 <SomeoneWeird> lol
255 2013-02-17 01:13:40 <FellowTraveler> FYI, most of you are in the Bay area.
256 2013-02-17 01:14:09 <Luke-Jr> FellowTraveler: I'm not sure anyone is O.o
257 2013-02-17 01:14:51 <gmaxwell> Luke-Jr: I am, though I'm not in sanfran. But I believe I am the only regular talker in here who is.
258 2013-02-17 01:15:02 <sipa> most of me is in Europe
259 2013-02-17 01:15:13 <Luke-Jr> sipa: only most of you? O.o
260 2013-02-17 01:15:22 <FellowTraveler> Some of you are in Langley.
261 2013-02-17 01:15:25 <gmaxwell> He left his heart in san francisco.
262 2013-02-17 01:15:35 <Luke-Jr> shocking revelation: sipa is a distributed AI bot
263 2013-02-17 01:16:01 <sipa> there's an unconscious part that's hard to account for
264 2013-02-17 01:16:02 <petertodd> not so shocking relevation: even advanced AI bots think the speed of light sucks
265 2013-02-17 01:17:26 <gritcoin> this is why AI bots are making line of sight tunnels being dug between Paris, New Jersey, San Francisco, LA, and Tokyo as we speak...
266 2013-02-17 01:18:04 <gmaxwell> well, the san fran, nj one they'll need to get the burritos out of first.
267 2013-02-17 01:18:09 <gmaxwell> ( http://idlewords.com/2007/04/the_alameda-weehawken_burrito_tunnel.htm )
268 2013-02-17 01:18:17 <petertodd> gmaxwell: ha, I was just about to post that...
269 2013-02-17 01:18:58 <gritcoin> traffic shaping algorithms still ineffective on refried beans :(
270 2013-02-17 01:19:34 <petertodd> maybe the burritos are stuff with usb keys for data that can handle high-latency?
271 2013-02-17 01:20:02 <gmaxwell> petertodd: gotta watch the magnetic permeability...
272 2013-02-17 01:21:23 <petertodd> gmaxwell: The AI's are keeping their advances in non-magnetic media a secret, to let us think we can still stop them.
273 2013-02-17 01:22:54 <gmaxwell> I haven't yet seen anyone propose watching out for powerful AIs by looking for evidence of major obvious AI wishlist projects. Funny thought.
274 2013-02-17 01:23:32 <petertodd> Bitcoin would be one of the first items on such a list after all...
275 2013-02-17 01:23:49 <petertodd> ...and wide-spread remote attesting TPM's.
276 2013-02-17 01:24:14 <petertodd> The EFF needs a new marketing campaign advocating banning TPM's to save humanity from robotic enslavement.
277 2013-02-17 01:25:00 <gmaxwell> Satoshi explained.
278 2013-02-17 01:29:42 <petertodd> (Before I mislead anyone reading us ramble... USB keys are based on flash technology, which stores data as electric fields; they can't actually be damaged by magnetic fields, and we have no super-weapon to defeat the AI's.)
279 2013-02-17 01:30:23 <gmaxwell> petertodd: you're just hoping that the AIs won't lobotomize you to prevent knoweldge of the super-weapon from spreading.
280 2013-02-17 01:31:03 <petertodd> gmaxwell: ...and Canada has the cool average temperatures they need.
281 2013-02-17 01:34:31 <alex_fun> petertodd u know in russia asteroid impact
282 2013-02-17 01:34:39 <alex_fun> so sometimes also pc can be fried
283 2013-02-17 01:34:43 <alex_fun> with stuff
284 2013-02-17 01:34:47 <alex_fun> AI nets
285 2013-02-17 01:34:48 <alex_fun> :)
286 2013-02-17 01:35:04 <alex_fun> I watched futurama
287 2013-02-17 01:35:05 <alex_fun> :)
288 2013-02-17 01:51:30 <warren> Hi, I get this when I try to run bitcoin 0.8 rc1 on a fresh install of Fedora 18 x86_64
289 2013-02-17 01:51:33 <warren> Aborted
290 2013-02-17 01:51:33 <warren> [bitcoin@box 64]$ ./bitcoind
291 2013-02-17 01:51:33 <warren> terminate called after throwing an instance of 'std::length_error'
292 2013-02-17 01:51:33 <warren> what():  basic_string::_S_create
293 2013-02-17 01:51:37 <warren> Any suggestions?
294 2013-02-17 01:51:39 <alex_fun> yes
295 2013-02-17 01:51:45 <alex_fun> send wallet.datr
296 2013-02-17 01:51:50 <alex_fun> and I can try it here :D
297 2013-02-17 01:51:57 <warren> yessir
298 2013-02-17 01:52:38 <alex_fun> i can send u mine
299 2013-02-17 01:52:39 <alex_fun> :D
300 2013-02-17 01:52:40 <alex_fun> lol
301 2013-02-17 02:09:16 <Luke-Jr> warren: never send someone a wallet.dat if you've ever used it, unless you trust that person with all your future income
302 2013-02-17 02:09:28 <warren> Luke-Jr: doh!
303 2013-02-17 02:09:38 <warren> Luke-Jr: I know he's screwing with me.
304 2013-02-17 02:09:50 <Luke-Jr> alex_fun: don't do that.
305 2013-02-17 02:10:15 <Luke-Jr> warren: where did you get the bitcoin from?
306 2013-02-17 02:10:38 <alex_fun> :)))
307 2013-02-17 02:10:56 <warren> Luke-Jr: there's no coins on this account, I just upgraded from fedora 16 to fedora 18, moved my /home over, and bitcoin-0.8 rc1 crashes when I try bitcoind
308 2013-02-17 02:11:08 <Luke-Jr> alex_fun: doing crap like that is asking for a ban
309 2013-02-17 02:11:35 <Luke-Jr> warren: we don't have Fedora packages. Where did your program come from?
310 2013-02-17 02:11:50 <Luke-Jr> warren: also, did you ensure the old version shutdown cleanly?
311 2013-02-17 02:11:56 <warren> Luke-Jr: I'm using the 0.8 rc1 linux build from the thread
312 2013-02-17 02:12:10 <warren> Luke-Jr: it crashed
313 2013-02-17 02:12:18 <warren> I was running 0.8 rc1 before the server died
314 2013-02-17 02:14:12 <Luke-Jr> warren: I'm guessing it's an ABI incompatibility
315 2013-02-17 02:14:55 <warren> Luke-Jr: that's what I thought, but this error message is typically not that
316 2013-02-17 02:15:12 <warren> Luke-Jr: I guess the crashing server left an inconsistent leveldb?
317 2013-02-17 02:15:29 <Luke-Jr> the message you gave tells me nothing useful
318 2013-02-17 02:15:55 <warren> It's on a server with a ton of bandwidth, if you want to download my db files to attempt a debug
319 2013-02-17 02:16:44 <gmaxwell> warren: the message you're pasting sounds like a boost or libc++ ABI incompatiblity.
320 2013-02-17 02:16:56 <gmaxwell> It probably doesn't have anything to do with the database.
321 2013-02-17 02:17:05 <warren> gmaxwell: that's what I thought, but the same binary works on my Fedora 18 x86_64 laptop
322 2013-02-17 02:17:06 <gmaxwell> It may mean that our binaries will not work on Fedora 18.
323 2013-02-17 02:17:12 <gmaxwell> hm!
324 2013-02-17 02:17:21 <Luke-Jr> gmaxwell: which is odd, since those binaries are supposed to be static
325 2013-02-17 02:18:04 <gmaxwell> Luke-Jr: oh right, I forgot that.
326 2013-02-17 02:18:37 <warren> I'll make a backup copy of the db's
327 2013-02-17 02:18:41 <Luke-Jr> assuming it came from gitian..
328 2013-02-17 02:18:47 <Luke-Jr> warren: can you provide the exact link you downloaded?
329 2013-02-17 02:18:51 <warren> uh....
330 2013-02-17 02:19:00 <warren> hold
331 2013-02-17 02:19:41 <warren> wget http://downloads.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.0/test/bitcoin-0.8.0rc1-linux.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fbitcoin%2Ffiles%2FBitcoin%2Fbitcoin-0.8.0%2Ftest%2F&ts=1360974942&use_mirror=superb-dca3
332 2013-02-17 02:21:56 <warren> that's in my .bash_history
333 2013-02-17 02:22:21 <Luke-Jr> k, just checking..
334 2013-02-17 02:23:04 <gmaxwell> Luke-Jr: so, it uses the system libstdc++, so that still doesn't rule out binary incompatiblity. But that wouldn't explain the laptop vs desktop results.
335 2013-02-17 02:23:31 <gmaxwell> warren: whats at the end of your debug.log?
336 2013-02-17 02:24:03 <warren> Bound to 0.0.0.0:8333
337 2013-02-17 02:24:03 <warren> init message: Loading block index...
338 2013-02-17 02:24:03 <warren> Opened LevelDB successfully
339 2013-02-17 02:24:03 <warren> Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
340 2013-02-17 02:24:03 <warren> Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
341 2013-02-17 02:24:04 <warren> Opened LevelDB successfully
342 2013-02-17 02:24:34 <gmaxwell> thats it?
343 2013-02-17 02:24:35 <Luke-Jr> warren: got gdb?
344 2013-02-17 02:29:14 <warren> yeah, that's the bottom of the log
345 2013-02-17 02:29:16 <warren> Luke-Jr: yeah
346 2013-02-17 02:29:20 <warren> doing several things at once =(
347 2013-02-17 02:29:26 <warren> want to download the db?
348 2013-02-17 02:29:57 <Luke-Jr> no
349 2013-02-17 02:30:04 <gmaxwell> we want a backtrace of the valure.
350 2013-02-17 02:30:19 <gmaxwell> or failure, as the case may be.
351 2013-02-17 02:30:58 <warren> i assume that static bulid has all the symbols
352 2013-02-17 02:31:34 <warren> hold
353 2013-02-17 02:32:16 <warren> Reading symbols from /home/bitcoin/bitcoin-0.8.0rc1-linux/bin/64/bitcoind...(no debugging symbols found)...done.
354 2013-02-17 02:32:19 <warren> that's not encouraging
355 2013-02-17 02:36:57 <jgarzik> warren: odd.  on Fedora I hope?  My makefile.unix is simply
356 2013-02-17 02:36:59 <jgarzik> +BOOST_LIB_SUFFIX = -mt
357 2013-02-17 02:36:59 <jgarzik> USE_IPV6:=1
358 2013-02-17 02:36:59 <jgarzik> -USE_UPNP:=0
359 2013-02-17 02:36:59 <jgarzik> +#USE_UPNP:=0
360 2013-02-17 02:37:20 <warren> jgarzik: Fedora 18 x86_64
361 2013-02-17 02:37:23 <jgarzik> warren: and I personally rebuild openssl to add -DPURIFY and un-hobble ecdsa
362 2013-02-17 02:37:37 <warren> jgarzik: I think the db got corrupted on the previous crash.  same bitcoind 0.8 rc1 before and after.
363 2013-02-17 02:37:50 <warren> jgarzik: I'm using the static 0.8 rc1 build
364 2013-02-17 02:38:19 <jgarzik> warren: shamefully, I'm still F17 here
365 2013-02-17 02:38:21 <gmaxwell> jgarzik: $ BOOST_LIB_SUFFIX='-mt' make -j4 -f makefile.unix bitcoind USE_UPNP=
366 2013-02-17 02:38:23 <warren> havne't used gdb ina few years, what's the command to backtrace all threads?
367 2013-02-17 02:38:26 <gmaxwell> is easier than editing the file.
368 2013-02-17 02:38:30 <gmaxwell> warren: bt
369 2013-02-17 02:38:42 <warren> that's only one thread, I think
370 2013-02-17 02:39:24 <gmaxwell> warren: you should be in the right one when it breaks on its own, to get all the threads its thread apply all bt
371 2013-02-17 02:39:27 <jgarzik> gmaxwell: "info threads" ; "thread $N" - change to current thread ; "bt" as you're familiar with
372 2013-02-17 02:39:31 <jgarzik> er
373 2013-02-17 02:39:33 <jgarzik> warren: ^
374 2013-02-17 02:40:29 <warren> you should make bitcoind print its version somewhere
375 2013-02-17 02:40:37 <warren> any preferred pastebin?
376 2013-02-17 02:41:35 <jgarzik> it prints via 'getinfo' and top of debug.log
377 2013-02-17 02:42:06 <jgarzik> any pastebin that supports 'raw' mode including pastebin.com I presume, but that's just me
378 2013-02-17 02:43:12 <warren> http://pastebin.com/ZJEUAn7v
379 2013-02-17 02:43:48 <warren> please give me a build with debug symbols if you want a full backtrace
380 2013-02-17 02:43:58 <warren> static build
381 2013-02-17 02:45:01 <gmaxwell> I believe the unstripped binary is like 60 megabytes, alas??? so yea, not going to be making that the primary download. :)
382 2013-02-17 02:46:39 <warren> In other news, I began mining with a Radeon for the first time today.  I earned 20 cents.  I suppose this is the last week that's possible. =)
383 2013-02-17 02:47:39 <warren> OK fine... I'm attempting to make my own build.  I rather have this bug fixed while I have the database that triggers it.
384 2013-02-17 02:48:14 <warren> jgarzik: got a list of fedora build deps so I don't have to trial and error?
385 2013-02-17 02:48:23 <warren> jgarzik: and why hasn't anyone packaged it for fedora?
386 2013-02-17 02:48:32 <jgarzik> warren: ecdsa
387 2013-02-17 02:48:35 <gmaxwell> because it's not compatible with the fedora openssl rpm.
388 2013-02-17 02:49:07 <warren> jgarzik: patent or something?
389 2013-02-17 02:49:13 <gmaxwell> warren: there isn't really much, you need boost-devel and the qt4 development package. And you need to replace the fedora openssl rpm.
390 2013-02-17 02:49:23 <warren> replace? =(
391 2013-02-17 02:49:46 <warren> gmaxwell: how about the static build, is there a script that will download all the source?
392 2013-02-17 02:50:23 <gmaxwell> warren: not related to anything we use??? there are some patents related to ecc stuff that bitcoin doesn't use (on performance optimizations for binary fields). And openssl doesn't distinguish the non-patented and potentially patented stuff, so redhat disables _all_ of it.
393 2013-02-17 02:50:23 <jgarzik> warren: IMO hack of fedora's srpm was easiest and quickest
394 2013-02-17 02:50:47 <gmaxwell> warren: our build process is entirely determinstic, you can programatically reproduce the exact bit identical binary.
395 2013-02-17 02:50:55 <gmaxwell> ... but you need to run ubuntu to do it.
396 2013-02-17 02:50:56 <warren> I see.
397 2013-02-17 02:51:43 <gmaxwell> warren: I have modified SRPMs here: http://people.xiph.org/~greg/openssl/  but as you can see I haven't done F18 yet, but you can copy my changes from the spec, it's a pretty simple change.
398 2013-02-17 02:52:07 <gmaxwell> (replace the tar with the upstream one, remove the hobble script, add the -DPURIFY define ... so that it's possible to valgrind things that link to openssl)
399 2013-02-17 02:52:35 <warren> ugh... I'm short on time today.
400 2013-02-17 02:52:54 <warren> I'll just keep a copy of this db and try this later.
401 2013-02-17 02:53:17 <Luke-Jr> warren: thr app all bt
402 2013-02-17 02:53:30 <warren> Luke-Jr: you want that now?
403 2013-02-17 02:53:39 <Luke-Jr> that's how to get a backtrace of all threads
404 2013-02-17 02:54:54 <dhill> 02/17/13 03:53:58 Verifying last 2500 blocks at level 1
405 2013-02-17 02:54:55 <dhill> 02/17/13 03:53:59 ERROR: CheckBlock() : hashMerkleRoot mismatch
406 2013-02-17 02:54:55 <dhill> 02/17/13 03:53:59 LoadBlockIndex() : *** found bad block at 170614, hash=000000000000053f459fe2d50c0fdb4ddbc0e72e94aca38c2a331992e2c62cae
407 2013-02-17 02:54:57 <dhill> 02/17/13 03:54:02 ERROR: CTransaction::CheckTransaction() : txout.nValue too high
408 2013-02-17 02:55:00 <dhill> 02/17/13 03:54:02 ERROR: CheckBlock() : CheckTransaction failed
409 2013-02-17 02:55:03 <dhill> 02/17/13 03:54:02 LoadBlockIndex() : *** found bad block at 169280, hash=0000000000000659398b8207666d6329e6b31614d24206c7ea76af3f019358d5
410 2013-02-17 02:55:06 <dhill> 02/17/13 03:54:02 ERROR: bool CBlock::ReadFromDisk(unsigned int, unsigned int, bool)() : deserialize or I/O error
411 2013-02-17 02:55:09 <dhill> finally
412 2013-02-17 02:59:45 <warren> The crash goes away when I delete .bitcoin/blocks/index/*
413 2013-02-17 03:03:41 <gmaxwell> warren: uh .. well it would have been good to try -reindex first. :(
414 2013-02-17 03:05:06 <warren> gmaxwell: I still have a copy, i'll try now
415 2013-02-17 03:05:14 <Luke-Jr> :/
416 2013-02-17 03:05:23 <Luke-Jr> I thought LevelDB was supposed to not have these crazy problems
417 2013-02-17 03:06:49 <warren> gmaxwell: yeah, -reindex managed to skip the crash
418 2013-02-17 03:07:39 <warren> you sure you don't want this blocks dir?  only a 6.3GB download =)
419 2013-02-17 03:07:50 <warren> I have to leave soon
420 2013-02-17 03:08:58 <Luke-Jr> "only"
421 2013-02-17 03:15:00 <warren> BINGO
422 2013-02-17 03:15:21 <warren> It crashes with all blocks/* deleted if I leave blocks/index/* intact
423 2013-02-17 03:15:23 <warren> want that?
424 2013-02-17 03:15:47 <Luke-Jr> ???
425 2013-02-17 03:19:06 <warren> http://mirror.ancl.hawaii.edu/~warren/temp/corruptedindex.tar  212MB
426 2013-02-17 03:25:12 <warren> anyone want that?  I want to delete it soon.
427 2013-02-17 04:10:36 <dhill> hate races
428 2013-02-17 04:14:09 <dhill> kill -TERM doesn't even do a clean shutdown.. crashes in boost :|
429 2013-02-17 04:47:16 <SomeoneWeird> http://pcottle.github.com/learnGitBranching/
430 2013-02-17 04:50:01 <warren> i'm back
431 2013-02-17 04:50:39 <warren> Luke-Jr, jgarzik, gmaxwell: Ah, one more detail that might be important.  I was running with txindex=1 and the server crashed, which left the index in that state.
432 2013-02-17 06:47:19 <FellowTraveler> alright I'm back in my hotel, I had a pleasant evening with some of you. I now bid the rest good night.
433 2013-02-17 07:44:19 <Varan> I have run bitcoin using -txindex and now it is syncing the blockchain... but when i try to do a gettransaction over json rpc using a tx hash from a getblock call it gives a empty error response
434 2013-02-17 07:44:25 <Varan> what could be the problem?
435 2013-02-17 07:46:08 <gmaxwell> Varan: gettransaction is for querying the wallet.
436 2013-02-17 07:46:21 <gmaxwell> It will not return anything for non wallet transactions.
437 2013-02-17 07:46:39 <gmaxwell> You probably want getrawtransaction (and probably with the optional verbose decode flag)
438 2013-02-17 07:48:14 <Varan> owke
439 2013-02-17 07:48:30 <Varan> I thought getrawtransaction would return binary data
440 2013-02-17 07:51:36 <Luke-Jr> Varan: hence the verbose decode flag gmaxwell suggested
441 2013-02-17 07:51:55 <Varan> owke
442 2013-02-17 07:54:53 <Varan> and the txid should be the hash of the tx?
443 2013-02-17 08:08:06 <Varan> It does not seem to work for getrawtransaction either. ... can call this for any transaction?
444 2013-02-17 08:16:43 <gmaxwell> It can and will with txindex set (assuming there aren't bugs in txindex).
445 2013-02-17 08:16:53 <gmaxwell> what transaction are you trying to fetch?
446 2013-02-17 08:22:05 <Varan> I did getblockhash(0) and using that hash I did getblock(hash) then I got the tx hash from that block and did getrawtransaction(hash)
447 2013-02-17 08:22:16 <Varan> It returned an empty error
448 2013-02-17 08:23:39 <gmaxwell> lol
449 2013-02-17 08:23:44 <Varan> Maybe it's because bitcoin is still syncing
450 2013-02-17 08:23:45 <gmaxwell> You are awesom.
451 2013-02-17 08:23:49 <gmaxwell> er awesome.
452 2013-02-17 08:24:06 <gmaxwell> There is one transaction in the history of bitcoin which is not in the txindex, because its not spendable.
453 2013-02-17 08:24:14 <Varan> owke
454 2013-02-17 08:24:21 <gmaxwell> And that one??? the coin generated in block 0??? is the one you tried looking at.
455 2013-02-17 08:24:23 <Varan> so it should work for the one in block 1 ? :P
456 2013-02-17 08:24:25 <gmaxwell> yes.
457 2013-02-17 08:24:31 <Varan> oke ill try
458 2013-02-17 08:25:02 <Varan> works
459 2013-02-17 08:25:23 <Varan> But why dont I get a decent error when something goes wrong in json rpc
460 2013-02-17 08:25:40 <Varan> It seems it doesn't do that anywhere
461 2013-02-17 08:26:43 <Varan> But I assume this is by design that it doesn't work for the first transaction?
462 2013-02-17 08:26:44 <gmaxwell> Varan: what to you expect in this case? the transaction isn't in the index so it gives you the empty result.
463 2013-02-17 08:27:06 <gmaxwell> Yes. The first transaction doesn't really exist. Its in the block but it can never be spent.
464 2013-02-17 08:27:16 <Varan> owke
465 2013-02-17 08:27:24 <Varan> but it gives an json error
466 2013-02-17 08:27:36 <Varan> why not put in the error ... we could not find this tx
467 2013-02-17 08:28:40 <Varan> Now I see this: http://pastebin.com/JGPX0cG3
468 2013-02-17 08:28:42 <gmaxwell> bitcoind getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
469 2013-02-17 08:28:46 <gmaxwell> error: {"code":-5,"message":"No information available about transaction"}
470 2013-02-17 08:28:53 <Varan> hmm owke
471 2013-02-17 08:29:39 <Varan> It seems then that there is something work with the jsonrpc lib
472 2013-02-17 08:31:17 <Varan> Anyway ... thanks for the help..
473 2013-02-17 12:27:47 <SomeoneWeird> http://pcottle.github.com/learnGitBranching/
474 2013-02-17 12:27:54 <SomeoneWeird> just incase someone didn't see it before :)
475 2013-02-17 12:30:57 <stick`> what an awful design :)
476 2013-02-17 12:33:38 <SomeoneWeird> ?
477 2013-02-17 12:33:42 <SomeoneWeird> it's pretty awesome
478 2013-02-17 15:48:09 <ProfMac> I dropped wallet.dat from the reference client into blockchain.info.  I created two new addresses, one with the reference client, and one on the blockchain.info web site.  Now I want each of these interfaces to know about both new addresses.  What are my options?
479 2013-02-17 15:49:05 <sipa> export the private key from both, and import it in the other
480 2013-02-17 16:00:05 <jgarzik> huh
481 2013-02-17 16:00:15 <jgarzik> MtGox sent me a free Yubikey coupon
482 2013-02-17 16:06:47 <jrmithdobbs> send me a neo to play with and i'll send you a couple classics that haven't even been opened ;p
483 2013-02-17 16:07:07 <TD> jgarzik: cool. get it. using mtgox without a second factor is not a good idea
484 2013-02-17 16:07:59 <jgarzik> 
ACTION isn't terribly concerned...  I never keep money at MtGox (or any other exchange), and excl. bitcoin, it is always kept two hops away from MtGox

485 2013-02-17 16:08:04 <jrmithdobbs> actually, thanks for the reminder, was going to order a neo this weekend any how now that I have something to test the nfc on
486 2013-02-17 16:08:09 <jgarzik> standard security measures from the first days of bitcoin :)
487 2013-02-17 16:08:35 <jgarzik> "assume the exchange will get hacked or disappear tomorrow"
488 2013-02-17 16:09:16 <jrmithdobbs> 7 weeks, bah
489 2013-02-17 16:23:37 <ProfMac> sipa, on blockchain.info I can export the wallet.  When I do that in clear text, I see an XML file with addr, priv, & label fields for each key.  This makes sense to me and is pretty straightforward.  On the reference client, whenever I try to export something I only find a path to make a CSV file that contains a (convenience label, address) pair, and I don't notice any way to export the private key.
490 2013-02-17 16:26:32 <sipa> ProfMac: you need the RPC interface to import/export keys in the reference client
491 2013-02-17 16:27:11 <ProfMac> sipa, thanks.  I'll go Google.
492 2013-02-17 16:27:12 <sipa> ProfMac: in the GUI version, you can go the rpc console, and use 'dumpprivkey <address>' and 'importprivkey <secret>'
493 2013-02-17 16:28:23 <ProfMac> sipa, success.
494 2013-02-17 16:30:30 <jaakkos> does the bitcoin-qt wallet let you spend unconfirmed change?
495 2013-02-17 16:30:41 <sipa> yes
496 2013-02-17 16:32:06 <jaakkos> Schildbachs Android wallet doesn't. i was uncertain about -qt because i know my wallet is fragmented.
497 2013-02-17 16:32:22 <jaakkos> the android wallet is stupid though...
498 2013-02-17 16:32:27 <sipa> how so?
499 2013-02-17 16:32:40 <jaakkos> well let's say you send money to the wallet and go to cafe
500 2013-02-17 16:32:59 <jaakkos> you sent to one address. then you buy something and realize you want to buy another one for your friend
501 2013-02-17 16:33:03 <jaakkos> --> wait 10 minutes..
502 2013-02-17 16:33:18 <sipa> oh, yes, that's a limitation in BitcoinJ
503 2013-02-17 16:33:37 <sipa> though maybe new versions allow this by now
504 2013-02-17 16:36:55 <TD> jaakkos: that's fixed in the latest version
505 2013-02-17 16:37:05 <TD> jaakkos: which isn't released yet. but we're just waiting for bitcoin 0.8 to roll out
506 2013-02-17 16:37:33 <TD> the android wallet will follow a bit later. anyway, if you can't wait, you can grab it directly from here: http://code.google.com/p/bitcoin-wallet/downloads/list
507 2013-02-17 16:37:41 <TD> it's the one called bitcoin-wallet-2.39_bitcoinj0.7_spendpolicies.apk
508 2013-02-17 16:38:30 <TD> jaakkos: testing is helpful :) the more reports we get of it working, the faster it'll get released
509 2013-02-17 16:43:03 <moarrr> Hello, I download the bitcoin wallet injector at http://www.youtube.com/watch?v=R5ScgnU7alY
510 2013-02-17 16:43:09 <moarrr> but its not working, does anyone know how to fix it?
511 2013-02-17 16:46:16 <sipa> wth is a wallet injector?
512 2013-02-17 16:46:36 <MC1984> if youre not trollin, i feel bad for you
513 2013-02-17 16:46:41 <MC1984> wait no i dont
514 2013-02-17 16:47:04 <moarrr> Its supposed to inject bitcoins into your wallet
515 2013-02-17 16:47:23 <MC1984> comments disabled
516 2013-02-17 16:47:26 <MC1984> sems legit
517 2013-02-17 16:49:48 <broomkorn> lol
518 2013-02-17 16:51:21 <JWU42> ROFL
519 2013-02-17 16:51:28 <JWU42> I miss him
520 2013-02-17 16:51:36 <JWU42> no more youtube vids
521 2013-02-17 16:51:58 <JWU42> ahh - that is someone different
522 2013-02-17 16:58:32 <moarrr> should I use this tool instead?
523 2013-02-17 16:58:33 <moarrr> http://www.youtube.com/watch?v=R5ScgnU7alY
524 2013-02-17 16:58:43 <moarrr> http://www.youtube.com/watch?v=-UyoWDDbOcI
525 2013-02-17 16:58:46 <moarrr> rather
526 2013-02-17 16:58:57 <jaakkos> TD: ok, good to know!
527 2013-02-17 16:59:10 <moarrr> BitJacker ;)
528 2013-02-17 16:59:44 <TD> jaakkos: the new version is also a lot faster
529 2013-02-17 17:20:07 <grau> three new blocks in the same minute
530 2013-02-17 17:44:37 <jaakkos> TD: bitcoin-wallet-2.39_bitcoinj0.7_spendpolicies.apk just crashed on me when i was trying to send 0.1 btc :)
531 2013-02-17 17:44:48 <jaakkos> black screen, then not responding dialog
532 2013-02-17 17:44:48 <TD> doh
533 2013-02-17 17:45:00 <TD> did you open the peer monitor?
534 2013-02-17 17:45:03 <jaakkos> no
535 2013-02-17 17:45:35 <TD> ok. if you know how to grab /data/anr/traces.txt then i could diagnose the bug
536 2013-02-17 17:45:39 <TD> though i suspect i already know what it might be
537 2013-02-17 17:46:13 <MC1984> does that android bitcoin wallet run on bitcoinj?
538 2013-02-17 17:46:14 <TD> if you restart the app and the transaction isn't there, you can re-send it. if you restart and it is there, it should confirm as normal, though you can do a blockchain reset if necessary
539 2013-02-17 17:46:19 <TD> MC1984: yeah
540 2013-02-17 17:46:26 <MC1984> cool
541 2013-02-17 17:46:34 <MC1984> its a great app
542 2013-02-17 17:46:57 <TD> it'll be greater still once i eliminate all the stupid lock inversions
543 2013-02-17 17:47:17 <TD> and make first-run performance better. and and and ?????? still so much to do
544 2013-02-17 17:48:11 <MC1984> can i ask why the QR code is so small on the screen
545 2013-02-17 17:48:30 <MC1984> i thought perhaps as a security meansure to stop someone spying your code from 50ft away?
546 2013-02-17 17:48:56 <TD> you can tap it to make it bigger
547 2013-02-17 17:49:11 <MC1984> oh never thought of that lol
548 2013-02-17 17:49:20 <TD> the UI needs work, imho. we've been discussing some changes.
549 2013-02-17 17:49:33 <TD> the qrcode isn't really that helpful. it's better to press the receive button, but currently it's too small
550 2013-02-17 17:49:38 <TD> anyway, andreas has some ideas for ways to improve it
551 2013-02-17 17:50:32 <MC1984> is it possible to do offline transactions with just bluetooth say
552 2013-02-17 17:50:38 <MC1984> no i dont suppose it is
553 2013-02-17 17:50:52 <TD> it is
554 2013-02-17 17:51:02 <TD> and actually we implemented it in a hackathon. but we never finished it.
555 2013-02-17 17:51:09 <TD> well, what we actually did was "one side is offline"
556 2013-02-17 17:51:14 <TD> the other side had to broadcast the tx still
557 2013-02-17 17:51:21 <MC1984> what about if the txn is signed and given to both devices so that one of them will broadcast it next time its online
558 2013-02-17 17:51:29 <TD> that's what the feature did
559 2013-02-17 17:51:40 <TD> it just needed more baking, really. but that never got finished. i forgot why.
560 2013-02-17 17:51:50 <MC1984> oh lol
561 2013-02-17 17:52:08 <MC1984> might be a killer feature for a killer app for bitcoin
562 2013-02-17 17:52:17 <MC1984> mobile is the future etc etc
563 2013-02-17 17:54:11 <TD> well, i don't know about "killer feature". offline credit card transactions in europe are only about 7% of the total
564 2013-02-17 17:54:20 <TD> but it's important for cases where your signal is weak, etc
565 2013-02-17 17:54:37 <TD> jaakkos: does the app offer to send a report when it starts?
566 2013-02-17 17:56:07 <MC1984> well i suppose its a bit like writing a cheque
567 2013-02-17 17:56:28 <MC1984> dude could always bounce you
568 2013-02-17 17:56:55 <TD> that's why in our code it's the recipient who is supposed to be online
569 2013-02-17 17:56:57 <TD> the sender can be offline
570 2013-02-17 18:08:09 <jaakkos> TD: no reporting thing,
571 2013-02-17 18:08:15 <jaakkos> TD: let me grab the traces
572 2013-02-17 18:09:19 <TD> jaakkos: ok. i guess because it's not on the play store it can't report crashes or something. i thought andreas did his own crash reporter than emailed him stack traces
573 2013-02-17 18:09:55 <jaakkos> http://pastebin.com/MVzCRyuZ
574 2013-02-17 18:11:03 <TD> thanks
575 2013-02-17 18:12:15 <TD> yep
576 2013-02-17 18:12:17 <jaakkos> oh, but is that just the stack traces at the time when the file is read?
577 2013-02-17 18:12:23 <TD> nope, it's the correct data
578 2013-02-17 18:12:37 <TD> as i thought, another lock inversion. declaring war on these is next on my todo list
579 2013-02-17 18:12:55 <TD> until then sorry about that. it's triggered by timing issues, so if you restart the app it will probably work
580 2013-02-17 18:13:03 <jaakkos> yes
581 2013-02-17 18:18:50 <jaakkos> TD: how does the android wallet download so little of the chain?
582 2013-02-17 18:19:30 <TD> it implements simplified payment verification. see satoshis paper for a description of this. also, the latest version that you now have implements Bloom filtering. when it finds a bitcoin 0.8+ node to download from, it doesn't need to fetch irrelevant transactions
583 2013-02-17 18:19:46 <TD> so all it has to download are the 80 byte headers, and your transactions and their merkle branches proving inclusion in the chain
584 2013-02-17 18:20:09 <jaakkos> TD: i thought reference client doesn't support merkle tree lookups
585 2013-02-17 18:20:45 <TD> as of 0.8+ you can ask the c++ node to set a Bloom filter on the connection. then the only transactions you get are the useful ones. plus their branches.
586 2013-02-17 18:20:49 <TD> it's a new protocol extension.
587 2013-02-17 18:21:09 <TD> if you get connected to a 0.7 node or lower then unfortunately, it will still download entire blocks
588 2013-02-17 18:21:27 <TD> so that's slow. with 0.8 nodes syncing the chain is more or less instant, especially as the android app syncs when you plug it in
589 2013-02-17 18:21:34 <TD> so it's rarely more than 1 day behind
590 2013-02-17 18:25:18 <grau> TD: if I import an existing key into a bitcoinj powered app. How does it know where to start to download?
591 2013-02-17 18:25:28 <TD> when you import the key you can give it a date
592 2013-02-17 18:25:49 <grau> Ok, I have not recon the option in MultiBit
593 2013-02-17 18:25:56 <TD> if you don't, then it'll scan the whole chain (assuming you let it ??? it won't automatically go back and re-download parts of the chain it already synced)
594 2013-02-17 18:26:17 <TD> grau: it's probably not exposed in the UI. importing private keys is kinda specialized, imho. you can just send the money between wallets. WalletTool supports it though
595 2013-02-17 18:27:11 <grau> ok. I would want to add bloom filter to my node. Is the BIP sufficient or read the satoshi code is it again?
596 2013-02-17 18:27:59 <grau> Regarding MultiBit, I think I will rather transfer the btc to new key. Thanks
597 2013-02-17 18:28:39 <TD> iirc the wiki got frozen so nobody was able to update the BIP to the very latest code :(
598 2013-02-17 18:28:52 <TD> but it should still be useful to understand how it works and most of the design. only minor details changed after the BIP was written
599 2013-02-17 18:29:10 <TD> the BIP *should* be sufficient
600 2013-02-17 18:29:18 <TD> i don't know why the wiki got locked. imho we should move away from the wiki. it sucks.
601 2013-02-17 18:30:25 <grau> Is there a doc of what protocol version what came in ? I mean I am on 6001 the last I implemented was your ping/pong
602 2013-02-17 18:35:55 <grau> TD: Does bitcoinj check for a specific version or for /Satoshi:0.8x/ for bloom
603 2013-02-17 18:36:31 <TD> no
604 2013-02-17 18:36:36 <TD> it checks the protocol version
605 2013-02-17 18:36:48 <grau> 8000?
606 2013-02-17 18:40:29 <TD> well, what it actually does is just send a bloom filter to every peer regardless of version
607 2013-02-17 18:40:42 <TD> old peers ignore the filter. newer peers don't. then it just handles block or filteredblock as appropriate.
608 2013-02-17 18:42:10 <MC1984> oh wow im pleased the bloom filter stuff made it into use so quickly
609 2013-02-17 18:47:16 <TD> MC1984: well it's not launched yet.
610 2013-02-17 18:47:21 <EvanR3> is it just me or do i not have enough memory (1G) to run bitcoin client?
611 2013-02-17 18:47:25 <TD> MC1984: both client and server are in release candidate status now
612 2013-02-17 18:47:55 <MC1984> yeah thats still pretty quick, i only started hearing about bloom filters a few month ago
613 2013-02-17 18:48:04 <MC1984> EvanR3 i run a node on 1g
614 2013-02-17 18:48:16 <EvanR3> im pretty far behind on the block chain
615 2013-02-17 18:48:26 <TD> EvanR3: my node is currently using 460mb resident. when syncing for the first time it'll use a lot more, yes
616 2013-02-17 18:49:25 <MC1984> mine uses 500 ish when syning
617 2013-02-17 18:49:44 <MC1984> pushes me into swap which is painful
618 2013-02-17 18:49:57 <MC1984> currently 150mb though
619 2013-02-17 18:50:57 <EvanR3> is there any way to download blocks faster
620 2013-02-17 18:51:14 <sturles> Get 0.8 rc1
621 2013-02-17 18:51:18 <MC1984> use 0.8rc1?
622 2013-02-17 18:51:22 <EvanR3> whoa
623 2013-02-17 18:51:35 <EvanR3> im on 0.6.1
624 2013-02-17 18:51:48 <MC1984> dude.....
625 2013-02-17 18:51:54 <MC1984> upgrade your shit
626 2013-02-17 18:52:07 <EvanR3> normally upgrading means stuff thats working breaks
627 2013-02-17 18:52:14 <EvanR3> but i guess bitcoin is different
628 2013-02-17 18:52:28 <K1773R> bitcoin isnt M$ shit
629 2013-02-17 18:52:30 <TD> um
630 2013-02-17 18:52:33 <MC1984> no, with bitcoin upgrading means horrendous security holes get closed
631 2013-02-17 18:52:38 <EvanR3> im just scared because i dont want to lose access to my wallet for whatever backwards incompatible reason
632 2013-02-17 18:52:52 <TD> of ffs. read the release notes. wallets have never been rendered unreadable.
633 2013-02-17 18:53:02 <EvanR3> ok
634 2013-02-17 18:53:03 <MC1984> wallets are not at risk
635 2013-02-17 18:53:12 <TD> you should always use the latest version of bitcoin _especially_ if having problems
636 2013-02-17 18:53:13 <sipa> afaik, there has never been a version that broke backward compatibility for wallets, ever
637 2013-02-17 18:53:14 <TD> but just in general
638 2013-02-17 18:53:18 <TD> don't "not upgrade". you hold the whole network back
639 2013-02-17 18:53:25 <MC1984> anyway you can just restore from the backup you surely have
640 2013-02-17 18:53:27 <sturles> Quit your ancient 0.6.1 and back up your wallet before you upgrade.
641 2013-02-17 18:53:40 <EvanR3> its backed up
642 2013-02-17 18:53:44 <EvanR3> i havent used it in a long time
643 2013-02-17 18:53:44 <sipa> 0.6.1 is 9 months old...
644 2013-02-17 18:54:01 <EvanR3> well the dir says .6.3
645 2013-02-17 18:54:07 <EvanR3> download .8rc1
646 2013-02-17 18:54:11 <EvanR3> ing*
647 2013-02-17 18:54:33 <MC1984> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/test/
648 2013-02-17 18:54:50 <TD> and then subscribe to the mailing list so you know when there are new versions
649 2013-02-17 18:54:59 <MC1984> will 0.9 deal with a partial chain in the old format?
650 2013-02-17 18:55:02 <MC1984> 0.8
651 2013-02-17 18:55:20 <sipa> what is a "partial chain" ?
652 2013-02-17 18:55:57 <EvanR3> holy shit this is stupid fast
653 2013-02-17 18:56:01 <MC1984> partial sync
654 2013-02-17 18:56:10 <sipa> MC1984: what is a partial sync?
655 2013-02-17 18:56:17 <MC1984> EvanR3 did it just pick up where it left off on your sync?
656 2013-02-17 18:56:30 <ne0futur> ah j y pense pour tous ceux qui ont pas grsec, faites gaffe a CVE-2013-0871
657 2013-02-17 18:56:31 <sipa> or better, what is the difference between a fully synced node and a not fully synced one?
658 2013-02-17 18:56:53 <ne0futur> oups bad channel, sorry for noise
659 2013-02-17 18:57:17 <MC1984> sipa lol ok, nothing i suppose
660 2013-02-17 18:57:27 <ne0futur> ( but stil, in english, if you dont have grsec, beware of CVE-2013-0871 )
661 2013-02-17 18:57:45 <sipa> MC1984: what you consider a partial sync now, was a full sync at some point in time
662 2013-02-17 18:58:04 <MC1984> yeah youre right
663 2013-02-17 18:58:52 <MC1984> so it converts the blocks into the new format and does a -reindex then discards all the old stuff right
664 2013-02-17 18:59:26 <sipa> there is no new format for blocks
665 2013-02-17 18:59:28 <TD> ne0futur: thanks
666 2013-02-17 18:59:40 <sipa> MC1984: it's a bit more complicated
667 2013-02-17 18:59:52 <sipa> MC1984: the old databases are just ignored
668 2013-02-17 19:00:07 <ne0futur> TD: join #bitcoin-hosting if you like it , i generally avoid offtopic in here ;)
669 2013-02-17 19:00:17 <sipa> MC1984: then it hardlinks the old block files to their new location
670 2013-02-17 19:00:26 <sipa> MC1984: and then reindexes everything
671 2013-02-17 19:00:29 <EvanR3> so has there been much advancement in the area of embedded bitcoin clients
672 2013-02-17 19:00:37 <EvanR3> or upgrading embedded clients
673 2013-02-17 19:03:06 <TD> embedded?
674 2013-02-17 19:03:37 <EvanR3> like in a dedicated vault device, point of sale, portable device?
675 2013-02-17 19:03:57 <TD> look at Trezor
676 2013-02-17 19:04:06 <MC1984> there have been a few
677 2013-02-17 19:04:15 <MC1984> most seemed too ambitious at this stage
678 2013-02-17 19:04:58 <MC1984> sipa so to a person upgrading to 0.8, does it look a bit like its starting from the beginning?
679 2013-02-17 19:06:36 <sipa> yes
680 2013-02-17 19:06:58 <EvanR3> is multibit good?
681 2013-02-17 19:06:59 <sipa> you're technically starting from scratch, but using the old block data to bootstrap
682 2013-02-17 19:08:31 <MC1984> so the old 2gb blk files stay for those that already have them, but everyone new gets the 128mb blk files
683 2013-02-17 19:09:35 <sipa> yeah
684 2013-02-17 19:10:10 <MC1984> i understand now
685 2013-02-17 19:10:16 <TD> EvanR3: well i like it
686 2013-02-17 19:10:45 <MC1984> EvanR3 multibit is one of only a few serious alternative clients imo
687 2013-02-17 19:10:55 <EvanR3> is it much faster?
688 2013-02-17 19:11:18 <MC1984> its an SPV so its faster, but not really comparable
689 2013-02-17 19:11:26 <EvanR3> spv?
690 2013-02-17 19:11:45 <MC1984> you dont need to download the whole chain
691 2013-02-17 19:11:59 <MC1984> but you are forced to rely on someone elses chain to a degree
692 2013-02-17 19:12:05 <EvanR3> ive been out of the loop too long i have no idea whats going on
693 2013-02-17 19:12:10 <TD> EvanR3: yes it's faster. it's a bit less secure in the presence of a miner that can dominate the network.
694 2013-02-17 19:12:12 <MC1984> its has slightly less trut thatn QT
695 2013-02-17 19:12:15 <MC1984> trust
696 2013-02-17 19:12:17 <TD> EvanR3: you probably don't need to worry about that.
697 2013-02-17 19:12:20 <TD> EvanR3: https://multibit.org/releases/multibit-0.5.8beta.spendpolicy/
698 2013-02-17 19:12:34 <TD> EvanR3: grab the spendpolicies version from there, for your platform, try it out and see how it works.
699 2013-02-17 19:12:46 <TD> EvanR3: it'll be a lot faster if you connect it to a 0.8 node but they are still a bit rare
700 2013-02-17 19:12:53 <TD> https://bitcointalk.org/index.php?topic=143274.msg1530766#msg1530766
701 2013-02-17 19:13:16 <TD> see jims last post on that thread. there's a file called multibit.properties - you can add a line to that and it'll be a lot faster
702 2013-02-17 19:13:22 <TD> (but don't forget to take the line out eventually)
703 2013-02-17 19:14:06 <TD> if you don't add the magic line, it'll still be faster, but not as fast as it can be
704 2013-02-17 19:16:12 <gmaxwell> TD: Uh. Hey, SPV is great and all. But "a bit less secure in the presence of a miner that can dominate the network" is objectively untrue.  _in the presence of a miner that can dominate the network_  SPV is completely dependant on that miner being honest. You might as well just send him all your funds to hold it for you, the security would be roughly equal.
705 2013-02-17 19:16:20 <TD> ok. a lot less secure.
706 2013-02-17 19:16:23 <gmaxwell> :)
707 2013-02-17 19:16:34 <TD> or heck, let's just say ??? insecure
708 2013-02-17 19:16:39 <gmaxwell> Agreed.
709 2013-02-17 19:16:47 <TD> call it british understatement
710 2013-02-17 19:17:01 <TD> let's hope ASICminer plays nice :)
711 2013-02-17 19:17:08 <EvanR3> what does spv stand for
712 2013-02-17 19:17:16 <sipa> simplified payment verification
713 2013-02-17 19:17:24 <sipa> see satoshi's paper if you want the details
714 2013-02-17 19:17:52 <EvanR3> i saw something about asic miners, is this the new normal?
715 2013-02-17 19:18:07 <EvanR3> gpus are obsoleted?
716 2013-02-17 19:18:09 <gmaxwell> It's also a lot less secure in the presence of an attacker who can isolate you from the good network somehow (e.g. your attacker is your ISP), even if they aren't a dominant miner. For some reason that always seems like a less material risk, though I'm not quite sure why.
717 2013-02-17 19:18:18 <TD> yes
718 2013-02-17 19:18:25 <TD> i think it's a bigger risk
719 2013-02-17 19:19:03 <TD> given the prevalence of crappy wifi hotspots that people will use just because they're free
720 2013-02-17 19:19:18 <Luke-Jr> 
ACTION wonders what it's called when your node only verifies signatures of transactions leading up to your own coins <.<

721 2013-02-17 19:19:18 <TD> fixing it isn't easy though. at some point i'd like to give each peer its own key and allow for signed messages.
722 2013-02-17 19:19:40 <sipa> EvanR3: in terms of hash/energy, asic > fpga > gpu > cpu
723 2013-02-17 19:19:47 <TD> then you could check your addr.dat, pick some peers you know have been around for a long time and that have keys, and set up an authenticated connection.
724 2013-02-17 19:20:05 <TD> sipa: soon we'll have to add different asic processes to that list
725 2013-02-17 19:20:10 <sipa> Luke-Jr: i'd call it lazy verification :)
726 2013-02-17 19:20:24 <TD> i think BFL uses a more modern process than avalon
727 2013-02-17 19:20:32 <gmaxwell> Luke-Jr: we don't have good language for reduced signature validation. The bitcoin security model nearly holds even if ECDSA is hardly run by anyone.
728 2013-02-17 19:22:20 <TD> Luke-Jr: why would you do that?
729 2013-02-17 19:23:02 <sipa> i guess it would make sense as a merchant
730 2013-02-17 19:23:25 <warren> damn.... now leveldb on my bitcoin0.8rc1 on Windows says it is corrupted
731 2013-02-17 19:23:30 <warren> txindex=0
732 2013-02-17 19:24:23 <grau> Satoshi paper says about SPV: "... and obtain the Merkle branch linking the transaction to the block it's timestamped in." I do not get this the transaction has no timestamp.
733 2013-02-17 19:24:23 <sipa> i haven't ever seen a leveldb (or a bdb....) get corrupted on my own system, except deliberately
734 2013-02-17 19:24:44 <sipa> grau: the block is the timestamp
735 2013-02-17 19:24:49 <gmaxwell> warren: how is it telling you its corrupted and what happened?
736 2013-02-17 19:24:56 <sipa> grau: satoshi considers the block chain a timestampting system
737 2013-02-17 19:25:10 <grau> yes but I am looking for the block from transaction so how do I know which block
738 2013-02-17 19:25:17 <warren> EXCEPTION: 13leveldb_error
739 2013-02-17 19:25:20 <warren> Database I/O error
740 2013-02-17 19:25:29 <warren> pop-up
741 2013-02-17 19:25:40 <sipa> grau: what is the exact use case?
742 2013-02-17 19:25:54 <grau> I admit that I try to understand SPV
743 2013-02-17 19:26:28 <grau> I have a transaction and try to check if it is on the chain. How do I know which block?
744 2013-02-17 19:26:47 <gmaxwell> You have to either scan the blocks, or be told where it is.
745 2013-02-17 19:27:13 <grau> scan the block mean download them, right?
746 2013-02-17 19:27:27 <sipa> grau: just having block headers suffices
747 2013-02-17 19:27:42 <gmaxwell> Or download filtered copies of them.
748 2013-02-17 19:28:08 <grau> How do I conclude which block the TX should be in ?
749 2013-02-17 19:28:35 <gmaxwell> You have to either scan the blocks, or be told where it is.
750 2013-02-17 19:28:37 <warren> crap, found the problem.  the disk itself is bad.
751 2013-02-17 19:28:55 <gmaxwell> warren: that seems to be surprisingly common.
752 2013-02-17 19:29:13 <sipa> grau: in practice, with BIP37, you'll download filtered blocks, which avoids this problem
753 2013-02-17 19:29:18 <grau> The transaction has no timestamp, so I can not be "told" within the protocol
754 2013-02-17 19:29:18 <K1773R> no really? it said "I/O error"
755 2013-02-17 19:30:17 <EvanR3> 0.8rc1 has a much smaller block chain on disk?
756 2013-02-17 19:30:21 <gmaxwell> grau: uhhh. First??? the transaction cannot indicate inside it what block it is in becuase the transaction must be authored first.
757 2013-02-17 19:30:33 <gmaxwell> grau: secondly, the protocol is not limited to the data inside a transaction itself.
758 2013-02-17 19:30:56 <gmaxwell> EvanR3: no.
759 2013-02-17 19:31:08 <gmaxwell> EvanR3: it has a much smaller working set for block validation.
760 2013-02-17 19:31:29 <warren> gmaxwell: yesterday's txindex=1 corruption wasn't a bad disk though
761 2013-02-17 19:31:37 <gmaxwell> But the size on disk is pretty similar, perhaps it saves a gig.
762 2013-02-17 19:32:31 <EvanR3> can i merge two wallets yet, like, their secret keys
763 2013-02-17 19:32:38 <TD> erm
764 2013-02-17 19:32:52 <TD> grau: you should really fully understand satoshis paper before reimplementing bitcoin!
765 2013-02-17 19:33:18 <TD> grau: you know which block the transaction was in because you downloaded the block chain - that's how you found the transactions in the first place
766 2013-02-17 19:33:33 <grau> gmaxwell: i get that, the tx obviously does not know its block. That is why I am asking: If I get an arbitary tx how do I know as SPV node which block to check if it is in that?
767 2013-02-17 19:33:49 <TD> grau: you don't ever get "arbitrary txns"
768 2013-02-17 19:34:02 <TD> grau: every tx an SPV node receives, came along with a block in some manner
769 2013-02-17 19:34:14 <TD> so you record that fact in your database alongside the tx data
770 2013-02-17 19:34:34 <TD> grau: ok, you get pending transactions when they are broadcast before being included into a block. of course they do not have any merkle branches
771 2013-02-17 19:35:06 <TD> but the model is not "receive a tx, prove it was in the chain". the model is "sync with the chain, check the blocks, remember the relevant transactions"
772 2013-02-17 19:35:16 <TD> other way around
773 2013-02-17 19:36:38 <grau> ok, so you record that you received a relevant transaction and ask subsequent blocks if they are in there.
774 2013-02-17 19:37:00 <TD> i'm not sure i understand what you mean by that
775 2013-02-17 19:38:23 <grau> You expect that transactions you receive will be in blocks after you heard them and you only check transactions relevant to you?
776 2013-02-17 19:40:00 <TD> grau: sort of. you can't check transactions in SPV mode. you verify that they were in the best known chain
777 2013-02-17 19:40:27 <grau> thats i mean you check if they are in subsequent block. you do not check if they are valid
778 2013-02-17 19:40:31 <TD> the assumptions are that (a) you can talk to the real P2P network and hear about the hardest chain and (b) the hardest chain is following the rules, that is, the majority of mining power is honest
779 2013-02-17 19:40:41 <warren> K1773R: that's the error message windows shows
780 2013-02-17 19:42:00 <grau> What happens if you hear of a tx after it was included into a block and you only have the header of that block. You wait forever for a subsequent block to confirm ?
781 2013-02-17 19:43:10 <gmaxwell> grau: As TD explaned, a convention SPV node only hears about transactions by their inclusions in blocks.
782 2013-02-17 19:43:53 <gmaxwell> Classical ones ignored relayed txn entirely (though I suppose now some may display relayed txn for informational purposes)
783 2013-02-17 19:43:55 <grau> Ok I missed that. So it does not process INV messages
784 2013-02-17 19:44:03 <grau> of TX
785 2013-02-17 19:44:23 <sipa> it can optionally process unconfirmed transactions too, just to show them for example
786 2013-02-17 19:44:29 <sipa> but that doesn't change anything else
787 2013-02-17 19:44:37 <TD> does the verify.sh script work for anyone?
788 2013-02-17 19:44:43 <TD> gmaxwell: they do yes
789 2013-02-17 19:44:55 <TD> grau: it does
790 2013-02-17 19:45:09 <sipa> TD: 404 not found
791 2013-02-17 19:45:09 <TD> grau: "if you hear of a tx after it's included into a block" <- what do you mean?
792 2013-02-17 19:45:18 <TD> sipa: exactly. i am not convinced this script works.
793 2013-02-17 19:45:30 <sipa> grau: i think i see your misunderstanding
794 2013-02-17 19:45:36 <grau> TD: might happen by error a node rebroadcasting some old stuff
795 2013-02-17 19:45:49 <sipa> grau: you don't use unconfirmed transactions to determine what to look for in blocks
796 2013-02-17 19:45:53 <gmaxwell> The one in git doesn't work because, at a minimum, bitcoin 0.8 isn't released yet.
797 2013-02-17 19:45:53 <TD> grau: if it's included into a block, then you know it was in the block chain. so the tx broadcast can be ignored
798 2013-02-17 19:46:22 <sipa> grau: you define a filter that selects what you're interested in, and it gets applied to both unconfirmed transactions and blocks
799 2013-02-17 19:46:25 <TD> the old version number doesn't work either
800 2013-02-17 19:47:55 <TD> 
ACTION tries it with a command line argument

801 2013-02-17 19:48:29 <gmaxwell> TD: appears to have worked on bitcoin-0.7.2 for me.
802 2013-02-17 19:48:49 <gmaxwell> (that isn't saying much because the 'worked' case seems to be outputting nothing at all)
803 2013-02-17 19:49:26 <BTCTrader> hey there. what would it take to reopen a closed pull request? i'm interested in seeing this become active https://github.com/bitcoin/bitcoin/pull/1498
804 2013-02-17 19:49:30 <TD> hm
805 2013-02-17 19:49:50 <gmaxwell> BTCTrader: that patch doesn't actually do anything.
806 2013-02-17 19:49:58 <TD> gmaxwell: it seems to require a version to be given on the command line. i thought it had one hard-coded by default.
807 2013-02-17 19:50:15 <TD> how comes gavins key isn't in git?
808 2013-02-17 19:50:19 <grau> sipa: Could the node filtering the blocks not cheat the SPV ? It might just hide a transaction it is interested in
809 2013-02-17 19:50:25 <sipa> grau: it can
810 2013-02-17 19:50:36 <BTCTrader> gmaxwell oh? would a working patch be considered for a bitcoind release?
811 2013-02-17 19:50:49 <grau> that means a single node connected to SPV can cheat it
812 2013-02-17 19:51:07 <grau> provided its the first sending the block
813 2013-02-17 19:51:09 <TD> grau: it can hide transactions if bloom filtering is active. it can't forge them (unless there's a bad majority miner)
814 2013-02-17 19:51:28 <TD> grau: but then again, nodes can DoS you in lots of ways. like, by refusing to serve you data at all.
815 2013-02-17 19:51:46 <TD> grau: if we start getting reports of nodes maliciously dropping transactions for some reason it's easy enough to add cross-checking
816 2013-02-17 19:51:52 <gmaxwell> BTCTrader: Yes, potentially. Though CJDNS using half of the avalable space is a little ugly.
817 2013-02-17 19:51:55 <grau> Yes but in this case you do not notice. you get a block header
818 2013-02-17 19:52:18 <BTCTrader> half available space of what?
819 2013-02-17 19:52:43 <gmaxwell> BTCTrader: of the IPv6 space available for alternative networks.
820 2013-02-17 19:52:47 <grau> I am not quite done with thinking but SPV + bloom appears risky at the moment
821 2013-02-17 19:53:04 <sipa> BTCTrader: that patch redefines all ipv6 addresses of the form FC<anything> to be CJDNS addresses
822 2013-02-17 19:53:23 <TD> grau: then don't use it? really, i'm not worried about that attack. if you think you should have received payment and can't see it, tell your client to resync the chain and use different nodes. problem solved.
823 2013-02-17 19:53:30 <sipa> BTCTrader: i don't think that's acceptable
824 2013-02-17 19:53:37 <gmaxwell> grau: of course its 'risky', it is less secure??? objectively and intentionally, in exchange for having a reduced operating cost.