1 2013-07-01 00:11:28 <CodeShark> there it stays until a new block is seen
  2 2013-07-01 00:11:51 <BW^-> codeshark: wow - so no broadcast at all until then
  3 2013-07-01 00:11:52 <BW^-> though
  4 2013-07-01 00:12:05 <BW^-> codeshark: about how frequently is there a new block? (*checking log*)
  5 2013-07-01 00:12:10 <CodeShark> it's broadcast immediately when it is determined it is valid
  6 2013-07-01 00:12:11 <nsh> 10m
  7 2013-07-01 00:12:26 <BW^-> codeshark: ah
  8 2013-07-01 00:12:26 <CodeShark> on average there's 10 minutes between blocks but there's high variance
  9 2013-07-01 00:12:29 <nsh> blocks are discovered as a poisson process with an expectation of 10m
 10 2013-07-01 00:12:41 <nsh> though it varies with network hashpower
 11 2013-07-01 00:12:51 <nsh> which changes a lot as miners come on and offline
 12 2013-07-01 00:13:02 <BW^-> so
 13 2013-07-01 00:13:02 <BW^-> wait
 14 2013-07-01 00:13:10 <BW^-> you commit a new transaction to your mempool
 15 2013-07-01 00:13:29 <BW^-> codeshark,nsh: what is the next piece of code that processes it - there's an immediate broadcast to the network isn't it?
 16 2013-07-01 00:13:46 <nsh> too ignorant of the code to say, sorry
 17 2013-07-01 00:15:44 <CodeShark> BW^-: look at ProcessMessage in main.cpp
 18 2013-07-01 00:16:08 <BW^-> codeshark: what trigs ProcessMessage, a 1second-timer or alike?
 19 2013-07-01 00:16:56 <nsh> BW^-, see https://bitcointalk.org/index.php?topic=41719.0
 20 2013-07-01 00:17:10 <nsh> -- Thread ThreadMessageHandler in net.cpp
 21 2013-07-01 00:17:34 <nsh> "This thread goes through all the nodes and calls ProcessMessages(pnode) in main.cpp which looks for valid messages on the node receive queue (pFrom->vRecv) and if it finds one, it calls ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv), which is also in main.cpp."
 22 2013-07-01 00:17:59 <nsh> i'd heartily recommend reading all these posts so that your questions are more pointed and annoy the busy devs less :)
 23 2013-07-01 00:18:19 <nsh> but for the grace of them go we
 24 2013-07-01 00:19:25 <CodeShark> or just look at the source code :)
 25 2013-07-01 00:20:06 <CodeShark> grep "ProcessMessage(" to see where it is called, or use something like doxygen
 26 2013-07-01 00:20:40 <nsh> aha, that was it!
 27 2013-07-01 00:20:45 <nsh> https://dev.visucore.com/bitcoin/doxygen/
 28 2013-07-01 00:23:58 <CodeShark> http://blockhawk.net/bitcoindoc/html/main_8cpp.html#a8ba92b1a4bce3c835e887a9073d17d8e
 29 2013-07-01 00:25:15 <nsh> sweet
 30 2013-07-01 00:38:43 <BW^-> codeshark: good point
 31 2013-07-01 00:38:51 <BW^-> nsh: very good point, yes i'm doing this right now :))
 32 2013-07-01 00:40:49 <CodeShark> BW^-: you might also want to look at ThreadMessageHandler in net.cpp
 33 2013-07-01 00:42:32 <Diablo-D3> goddamnit
 34 2013-07-01 00:42:36 <Diablo-D3> bitcoin says my wallet is corrupt
 35 2013-07-01 00:42:58 <CodeShark> always keep at least two copies of a wallet :)
 36 2013-07-01 00:43:10 <nsh> salt, meet wound...
 37 2013-07-01 00:43:16 <CodeShark> heh
 38 2013-07-01 00:43:19 <Diablo-D3> I have a copy, but it refuses to retrieve all the transactions
 39 2013-07-01 00:43:31 <CodeShark> can it at least read the private keys?
 40 2013-07-01 00:47:33 <Diablo-D3> CodeShark: it refuses to start
 41 2013-07-01 00:48:02 <CodeShark> I was actually working a little on the wallet loading error handling earlier today...could certainly use many improvements
 42 2013-07-01 00:48:45 <CodeShark> so it exits with either copy of the wallet?
 43 2013-07-01 00:49:17 <CodeShark> I think someone had written a tool to recover the keys from corrupt wallets
 44 2013-07-01 00:49:39 <CodeShark> forgot who and where
 45 2013-07-01 00:52:41 <CodeShark> the wallet refusing to retrieve all the transactions isn't such a terrible thing - recover the keys, start a new wallet, import the keys, and resync :)
 46 2013-07-01 00:52:54 <nsh> there's this thread: https://bitcointalk.org/index.php?topic=160295.0
 47 2013-07-01 00:53:18 <nsh> (unresolved)
 48 2013-07-01 00:53:39 <nsh> also: http://bitcoin.stackexchange.com/questions/3533/error-loading-wallet-dat-wallet-corrupted
 49 2013-07-01 00:53:45 <CodeShark> I'd rather move the wallet entirely off of bdb :)
 50 2013-07-01 00:53:48 <nsh> (solved by using an older version)
 51 2013-07-01 00:53:59 <nsh> might be indicated...
 52 2013-07-01 00:54:25 <nsh> "I intend to add a sort of "recovery mode" in 0.7.0 for situations like this." -Pieter Wuille
 53 2013-07-01 00:55:56 <nsh> <sipa>\tjoehallofame: i've just implemented a very quick "wallet recovery mode" patch for bitcoin; if i make you a windows build of it, would you consider trying it? (it's hardly tested, but it may save your wallet)
 54 2013-07-01 00:55:58 <nsh> http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/04/01
 55 2013-07-01 01:04:07 <Diablo-D3> YAY
 56 2013-07-01 01:04:08 <Diablo-D3> FIXED IT
 57 2013-07-01 01:04:23 <Diablo-D3> db4.8_dump -p ~/.bitcoin/wallet.dat > wallet.txt
 58 2013-07-01 01:04:28 <Diablo-D3> db4.8_load -f wallet.txt wallet.dat.new
 59 2013-07-01 01:04:33 <Diablo-D3> mv wallet.dat.new ~/.bitcoin/wallet.dat
 60 2013-07-01 01:04:46 <CodeShark> ah, cool
 61 2013-07-01 01:05:03 <Diablo-D3> 
ACTION shuts down bitcoin makes immediate copy of new wallet

 62 2013-07-01 01:06:28 <nsh> Diablo-D3, nice one :)
 63 2013-07-01 01:06:43 <Diablo-D3> I wonder why my old wallet didnt contain all the keys
 64 2013-07-01 01:06:43 <nsh> 
ACTION drinks in celebration of Diablo-D3's not-so-bad luck

 65 2013-07-01 01:06:50 <Diablo-D3> Im pretty sure I havent made 100 new tx since then
 66 2013-07-01 01:15:50 <BW^-> bitcoind supports Simple Payment Verification through the fClient variable?
 67 2013-07-01 01:29:00 <Luke-Jr> BW^-: bitcoind does not support SPV yet
 68 2013-07-01 01:29:33 <nsh> Luke-Jr, is it actively planned or kinda waylaid?
 69 2013-07-01 01:29:55 <nsh> there are two currently maintained 3rd party SPV nodes afaik
 70 2013-07-01 01:30:06 <nsh> although i vaguely recall some issues with android wallet
 71 2013-07-01 01:30:25 <BW^-> luke-jr: as i understand it from https://bitcointalk.org/index.php?topic=41718.0 , back in 2011 it was supported, anyhow
 72 2013-07-01 01:30:26 <BW^-> aha noted
 73 2013-07-01 01:30:52 <Luke-Jr> BW^-: never by bitcoind
 74 2013-07-01 01:31:17 <Luke-Jr> your link admits "This is currently not considered to be finished code."
 75 2013-07-01 03:24:43 <gmaxwell> recursive build?! egads!
 76 2013-07-01 03:25:32 <nsh> "i'm sorry Madam, it's gitians all the way down..."
 77 2013-07-01 03:25:57 <gmaxwell> Why did we ask for this?  My own expirence is that it's horrible makes doing things like putting all the object files out of the way a pain, slows compiling, etc.
 78 2013-07-01 03:34:55 <sipa> gmaxwell: jeff asked for that, afaik
 79 2013-07-01 03:35:14 <sipa> don't know why, and i personally have no opinion
 80 2013-07-01 03:40:30 <gmaxwell> Well theuni's comments there reflect my expirences too: its slow, screws things up, and once people realized that good multiple directory support was possible without it many changed their projects to not be recursive.  Though, it's a bit less bad when you're not building a library.
 81 2013-07-01 04:00:57 <CodeShark> are OpenSSL compressed keys always exactly 33 bytes in length? (sign byte + 32 bytes for x coordinate)?
 82 2013-07-01 04:01:03 <sipa> yes
 83 2013-07-01 04:01:32 <k9quaint> gmaxwell: you are just afraid of make :P
 84 2013-07-01 04:02:13 <sipa> though openssl doesn't have that much to do with it, it's lart of SEC and other standards
 85 2013-07-01 04:02:17 <sipa> part
 86 2013-07-01 04:02:39 <CodeShark> yes, just making sure that the OpenSSL code in my CoinKey class doesn't throw me something weird on occasion which throws off my validation logic
 87 2013-07-01 04:05:50 <phantomcircuit> CodeShark, yes but openssl will accept zero padded values
 88 2013-07-01 04:06:08 <CodeShark> ok, as long as it doesn't give me zero padded outputs everything is fine
 89 2013-07-01 04:06:12 <phantomcircuit> but bitcoin treats them as nonstandard after 0.8.2
 90 2013-07-01 04:13:48 <sipa> phantomcircuit: not afaik
 91 2013-07-01 04:13:59 <phantomcircuit> sipa, no not yet?
 92 2013-07-01 04:13:59 <sipa> and that would be completely nonstandard...
 93 2013-07-01 04:14:27 <phantomcircuit> sipa, openssl definitely does accept null padded just about everything
 94 2013-07-01 04:14:37 <sipa> CodeShark is talking about public keys
 95 2013-07-01 04:14:40 <sipa> are you?
 96 2013-07-01 04:14:56 <sipa> sounds like you are referring to the DER encoded signatures
 97 2013-07-01 04:14:57 <phantomcircuit> no
 98 2013-07-01 04:15:31 <sipa> public keys are exactly 33 or exactly 65 bytes
 99 2013-07-01 04:15:48 <sipa> well, or 1 byte for the point at infinity
100 2013-07-01 04:15:57 <sipa> but that is nkot a valid public key
101 2013-07-01 04:36:42 <sipa> CodeShark: and it will zero-pad, if there are zeroes, to make the x coordinate 32 bytes
102 2013-07-01 04:37:59 <CodeShark> right. eventually I'll probably end up swapping out openssl for your secp256k1 library
103 2013-07-01 04:38:44 <maaku> what's the advantage of your secp256k1 library?
104 2013-07-01 04:39:00 <CodeShark> smaller footprint, a LOT faster, fewer dependencies
105 2013-07-01 04:39:23 <CodeShark> and hopefully cleaner syntax, too :)
106 2013-07-01 04:41:04 <CodeShark> downside: hasn't been field tested as much
107 2013-07-01 04:41:53 <maaku> audited for timing attacks, memory clears?
108 2013-07-01 04:42:06 <CodeShark> right, sidechannel attacks are a possibility
109 2013-07-01 04:43:06 <CodeShark> although sidechannel attacks are probably not as big a risk as many seem to think they are
110 2013-07-01 04:43:30 <CodeShark> if someone has sufficient access to your machine to mount a sidechannel attack they probably can also install a keystroke logger
111 2013-07-01 04:44:15 <CodeShark> sidechannel attacks are a bigger risk when talking across a network
112 2013-07-01 04:44:19 <maaku> sidechannel attacks are doable (and demonstrated) on the cloud
113 2013-07-01 04:44:20 <CodeShark> or to an untrusted device
114 2013-07-01 04:44:43 <maaku> you just have to get on the same cluster as the vm
115 2013-07-01 04:44:57 <sipa> maaku: the primary purpose was speeding up validation, where timing attacks don't matter
116 2013-07-01 04:45:09 <sipa> for signing, you want more resitant algoryhms
117 2013-07-01 04:45:14 <maaku> ok
118 2013-07-01 04:45:27 <sipa> some parts are constant time, but certainly not everything
119 2013-07-01 04:45:45 <CodeShark> in any case, for signing I think I know how to get constant-time and constant cache-access
120 2013-07-01 04:45:54 <sipa> me too :)
121 2013-07-01 04:46:13 <sipa> anyway, audited... certainly not enough
122 2013-07-01 04:46:20 <CodeShark> and for signing performance doesn't really matter as much
123 2013-07-01 04:46:34 <CodeShark> well, let me qualify that
124 2013-07-01 04:46:54 <CodeShark> for signing on a typical personal computer (or even smartphone or tablet)
125 2013-07-01 04:46:59 <sipa> it signs in 30us now or so
126 2013-07-01 04:47:04 <sipa> and verifies in 90us
127 2013-07-01 04:47:10 <CodeShark> for signing on an 8-bit processor, performance does matter - a LOT :)
128 2013-07-01 04:47:19 <warren> maaku: you can build bitcoin on RHEL or Fedora without replacing openssl
129 2013-07-01 04:47:52 <maaku> warren: i was questioning the security, not the usefullness
130 2013-07-01 04:48:06 <sipa> and you should
131 2013-07-01 04:49:43 <maaku> not that I don't trust sipa to write crypto code, but ???i rewrote the core crypto routines to be faster??? should set off alarm bells regardless ;)
132 2013-07-01 04:50:36 <sipa> absolutely
133 2013-07-01 04:51:05 <CodeShark> the problem isn't so untractable as to be impossible to check for holes - but in the crypto world, whenever anything that's been used for a while is replaced it should set off alarm bells :)
134 2013-07-01 04:51:31 <sipa> but i'm working on the auditing part :)
135 2013-07-01 04:53:31 <petertodd> That making core crypto routines faster is a desired thing shows how badly Bitcoin scales. :( If I ever make a cryptocoin, I'm writing it in Python, and architecting it so that's acceptable!
136 2013-07-01 04:54:22 <nsh> also openssl isn't necessarily slow because "it has to be". it's a larger entity and therefore the code is not structure for maximum efficiency in ECDSA
137 2013-07-01 04:54:42 <CodeShark> lol - that's an interesting way to challenge yourself, petertood
138 2013-07-01 04:54:47 <CodeShark> *petertodd
139 2013-07-01 04:54:59 <sipa> it also just doesn't have all secp256k1-specific tricks implemented
140 2013-07-01 04:55:19 <nsh> what are the chances one of those tricks opens up a subtle vulnerability though, i wonder
141 2013-07-01 04:55:24 <petertodd> Heh, in general if you can't make it fast enough in Python you probably are using bad algorithms. :) But only in general...
142 2013-07-01 04:55:29 <CodeShark> zero for validation
143 2013-07-01 04:55:30 <nsh> that's possibly an open question is advanced magics
144 2013-07-01 04:55:36 <nsh> *in
145 2013-07-01 04:55:43 <CodeShark> nsh, the possibility is zero if only used for validation
146 2013-07-01 04:55:45 <nsh> oh ok
147 2013-07-01 04:55:52 <CodeShark> sipa's code is clearly not suited to signing yet
148 2013-07-01 04:55:53 <CodeShark> ;)
149 2013-07-01 04:55:58 <nsh> 
ACTION nods

150 2013-07-01 04:56:16 <petertodd> CodeShark: could be a subtle incompatibility vulnerability too though.
151 2013-07-01 04:56:51 <sipa> well, all tricks boil dpwn to mathematical identities
152 2013-07-01 04:57:01 <CodeShark> petertodd: you mean data formats?
153 2013-07-01 04:57:01 <sipa> and they are quite easy to explain
154 2013-07-01 04:57:03 <maaku> petertodd: we will eventually see GPU and FPGA secp256k1, I'm sure
155 2013-07-01 04:57:03 <nsh> true, forking risks open up almost a new category of possible problems that have not had a history in the literature
156 2013-07-01 04:57:14 <sipa> whether they're imp,ementee correctly is something else entirely
157 2013-07-01 04:57:38 <CodeShark> data formats would have to be validated and made canonical and guaranteed unique before even attempting to switch
158 2013-07-01 04:57:46 <petertodd> nsh: Yeah, people often forget how Bitcoin is blazing a new path there.
159 2013-07-01 04:57:55 <nsh> someone needs to herd up a bunch of discrete mathematics grad students and for a two week intensive on bitcoin for this purpose :)
160 2013-07-01 04:57:58 <nsh> 
ACTION nods

161 2013-07-01 04:58:29 <nsh> it's the first consensuated distributed database of its kind, and the stakes are massive
162 2013-07-01 04:58:40 <nsh> i don't know how you guys aren't all chain-smoking to be honest
163 2013-07-01 04:58:51 <petertodd> nsh: I don't think I've *ever* seen a crypto anything talk about the risk of a false negative signature validation.
164 2013-07-01 04:59:25 <CodeShark> there are plenty of greater forking risks than potential incompatibilities in crypto libraries (as long as my previous point is adhered to) - such as resource limitations or unknown bugs
165 2013-07-01 04:59:27 <petertodd> nsh: In addition to Bitcoin I do cave exploration; I also try to avoid actually writing code. :P
166 2013-07-01 04:59:38 <nsh> 
ACTION smiles

167 2013-07-01 04:59:48 <sipa> in most setups, a false negative just means that someone who was authorized can't grt in
168 2013-07-01 05:00:03 <petertodd> sipa: Yup, not a horrible thing.
169 2013-07-01 05:00:04 <sipa> for bitcoin, it means All Hell Breaks Loose(tm)
170 2013-07-01 05:00:09 <nsh> right
171 2013-07-01 05:00:22 <nsh> there's a talk/thesis in that aspect alone
172 2013-07-01 05:00:54 <petertodd> Heck, has there even ever been a from scratch crypto-currency implementation? I'm pretty sure every alt-coin ever made is based on bitcoind.
173 2013-07-01 05:01:25 <nsh> maybe in Adam Back's head
174 2013-07-01 05:01:34 <petertodd> nsh: ha
175 2013-07-01 05:01:57 <sipa> petertodd: i'd love to do that as an experimemt
176 2013-07-01 05:02:10 <petertodd> sipa: I came up with a half-decent timestamping blockchain today actually; might be worthwhile implementing it quickly just to have that datapoint.
177 2013-07-01 05:02:24 <nsh> petertodd, pray tell :)
178 2013-07-01 05:02:28 <sipa> 
ACTION stops earth's time for 2 years

179 2013-07-01 05:02:41 <nsh> petertodd, would you do that in python?
180 2013-07-01 05:02:44 <sipa> hey hi everyone
181 2013-07-01 05:03:01 <nsh> <farnsworth> terrible news, everybody!
182 2013-07-01 05:05:25 <petertodd> nsh: yes, python! from a users point of view what sucks about bitcoin timestamps, done right, is that they take a confirmation at least; the user wants 1 second max confs.
183 2013-07-01 05:05:36 <nsh> right...
184 2013-07-01 05:06:35 <petertodd> So what you want ideally is a blockchain with a 1 second interval, which is kinda crazy, but if the blocksize is tiny it's not actually all that bad. (propagation is fast for ~1-5KiB messages)
185 2013-07-01 05:07:12 <nsh> right, 10m was just so the moon colony can be part of bitcoin
186 2013-07-01 05:07:13 <nsh> :)
187 2013-07-01 05:07:16 <petertodd> Timestamping is also kinda unique, because there is no such thing as a double-spend, kinda. For anti-DoS you don't want to sure much more than 1 block per second for all time.
188 2013-07-01 05:07:22 <nsh> hmm
189 2013-07-01 05:07:42 <nsh> s/sure/store?
190 2013-07-01 05:08:35 <petertodd> s/sure/store/ So structure your blockchain as a DAG, with a defined "most-work" path, and secondaries, and at some point just throw out sufficiently low-PoW paths through the DAG.
191 2013-07-01 05:08:58 <nsh> ohhhhh
192 2013-07-01 05:09:11 <nsh> hah, i like it!
193 2013-07-01 05:09:26 <nsh> that's like reorgs by design
194 2013-07-01 05:09:44 <nsh> constantly reorgs
195 2013-07-01 05:09:54 <petertodd> Yes! Which helps make the 1s block interval saner.
196 2013-07-01 05:09:58 <nsh> and because ordering isn't so vital
197 2013-07-01 05:10:03 <nsh> that's the other property that makes that doable
198 2013-07-01 05:10:08 <nsh> gotcha
199 2013-07-01 05:10:11 <nsh> very nice :)
200 2013-07-01 05:10:27 <nsh> this could work for namecoin stuff as well, couldn't it?
201 2013-07-01 05:10:44 <petertodd> Yup, I don't think aiming for 1s *accuracy* is really all that realistic, but 1s resolution is fine and more importantly it means the user only has to wait a few seconds to be fairly sure their timestamp got recorded.
202 2013-07-01 05:11:01 <nsh> yup, within the window of human patience
203 2013-07-01 05:11:02 <CodeShark> at some point you have to sacrifice C, A, or P :)
204 2013-07-01 05:11:16 <petertodd> I've got a different key-value DAG think I'm calling zookeyv for namecoin stuff actually.
205 2013-07-01 05:11:41 <nsh> i'd like to see that when it's possible
206 2013-07-01 05:12:18 <nsh> oh, you've mentioned it on the list
207 2013-07-01 05:12:49 <petertodd> Of course, you should ask, what are these blocks going to be anyway? Well actually, the obvious thing is to make it easily Bitcoin "merge-mine" compatible, and by that, I mean a block is just a merkle path from a txout to a Bitcoin block header, either a real one in chain, or a lesser PoW one.
208 2013-07-01 05:13:18 <petertodd> The timestamp-specific bit is then just a merkle-tree of one or more previous blocks.
209 2013-07-01 05:13:19 <nsh> hmm
210 2013-07-01 05:13:41 <nsh> i think i understand vaguely. but i'm still a bit foggy on merkle-tree matters
211 2013-07-01 05:13:55 <Luke-Jr> petertodd: well, it has to be in the real blockchain to get timestamped forward
212 2013-07-01 05:14:20 <petertodd> Finally, the rule for best-block selection, IE what you mine your next block on, works totally different from Bitcoin: pick the highest total work for the given time and build upon that.
213 2013-07-01 05:14:42 <petertodd> Luke-Jr: yeah, hence making it possible to "mine" one of these blocks by just making a transaction.
214 2013-07-01 05:15:01 <petertodd> Luke-Jr: Which is fine because the structure is a DAG rather than a chain.
215 2013-07-01 05:15:12 <nsh> wait, how do you enforce the rate of mining?
216 2013-07-01 05:15:23 <nsh> can difficulty be adjusted with that much resolution?
217 2013-07-01 05:15:45 <petertodd> nsh: By just picking the hardest PoW with a given timestamp, within the 1s or whatever interval.
218 2013-07-01 05:16:01 <nsh> hmm
219 2013-07-01 05:16:14 <nsh> right, ok
220 2013-07-01 05:16:19 <petertodd> nsh: You just don't *need* difficulty at all, because all you care about is limiting the max block rate - there's no economics involved.
221 2013-07-01 05:16:29 <nsh> gotcha
222 2013-07-01 05:16:41 <Luke-Jr> you don't even need to limit the rate really. just measure it provably.
223 2013-07-01 05:16:47 <Luke-Jr> but limiting it might be easiest way to do that
224 2013-07-01 05:17:17 <petertodd> Luke-Jr: The limit is just because 1s is a reasonable amount for a user to wait, and that gives a good upper limit on blockchain size.
225 2013-07-01 05:17:20 <petertodd> Luke-Jr:
226 2013-07-01 05:17:42 <Luke-Jr> petertodd: well, I was thinking it might be good to slow down when people don't need it
227 2013-07-01 05:17:48 <petertodd> Luke-Jr: More timestamps than 1/s can be handled by nodes co-operatively creating merkle trees of digests requested - haven't figured out how exactly that will work.
228 2013-07-01 05:18:07 <nsh> Luke-Jr, there might be things that are useful to timestamp for 'clock' transactions
229 2013-07-01 05:18:12 <nsh> such as, dunno, weather data or something
230 2013-07-01 05:18:21 <petertodd> Luke-Jr: But it does slow down! If people don't make timestamps, blocks just won't get added. Of course, you can always make false ones, but that is impossible to stop.
231 2013-07-01 05:18:43 <Luke-Jr> petertodd: then you can't prove the time passed ;p
232 2013-07-01 05:19:21 <petertodd> Luke-Jr: This works in conjunction with the Bitcoin blockchain remember, which I really hope advances forward...
233 2013-07-01 05:19:27 <nsh> use lol
234 2013-07-01 05:19:29 <nsh> *lol
235 2013-07-01 05:19:35 <Luke-Jr> true
236 2013-07-01 05:19:38 <nsh> maybe people stop using money and then we can't timestamp document anymore
237 2013-07-01 05:19:39 <nsh> :(
238 2013-07-01 05:19:52 <petertodd> nsh: Same risk for using Bitcoin to timestamp directly.
239 2013-07-01 05:20:24 <nsh> 
ACTION nods

240 2013-07-01 05:20:28 <nsh> wasn't being serious :)
241 2013-07-01 05:21:10 <petertodd> One ugly thing with this scheme is it's easy for griefers to use some hashing power to rewrite the chain between full-diff Bitcoin blocks - if that's a problem getting pools to merge mine this would be required.
242 2013-07-01 05:21:39 <nsh> hm
243 2013-07-01 05:22:13 <nsh> would be a pretty esoteric thing to grief
244 2013-07-01 05:22:15 <petertodd> Yeah, it's either allow rewrites, or the blockchain can get arbitrarily large due to huge side-forks - there is a tradeoff.
245 2013-07-01 05:22:18 <nsh> not that this has ever put people off
246 2013-07-01 05:22:33 <nsh> right
247 2013-07-01 05:23:20 <petertodd> Exactly - and timestamping is a lot more important than people realize. Timestamping is a huge business, just not one we often see because it's so associated with highly regulated industries.
248 2013-07-01 05:23:55 <nsh> right, it's massively important in various legal contexts
249 2013-07-01 05:24:14 <nsh> and probably quite a nice earner for a small industry
250 2013-07-01 05:24:43 <petertodd> Yup, and timestamping as a business is weird, because what they're really selling is legal services, not technical services, and the pricing is often amazingly expensive.
251 2013-07-01 05:24:52 <nsh> 
ACTION nods

252 2013-07-01 05:25:09 <Luke-Jr> you're assuming any legal context cares about technical timestamp stuff
253 2013-07-01 05:25:09 <nsh> but at least that means they won't be so threatened by a network solution
254 2013-07-01 05:25:13 <petertodd> In the long run blockchain timestamping could be seriously, seriously disruptive... but that's a long way away.
255 2013-07-01 05:25:26 <nsh> well, they'd still be able to sell their legal expertise
256 2013-07-01 05:25:29 <nsh> and contacts, etc.
257 2013-07-01 05:25:42 <nsh> they'd just use the blockchain to avoid having to have on-site tech people
258 2013-07-01 05:25:49 <nsh> it might be a good thing for efficiency in the final reckoning
259 2013-07-01 05:25:58 <petertodd> Luke-Jr: That's the thing, they do! Which is why the thing timestamping companies are really selling is the service by which their lawyers come to court and convince judge and jury of why the tech works.
260 2013-07-01 05:26:00 <nsh> if visa used bitcoin they'd probably save money
261 2013-07-01 05:26:28 <Luke-Jr> petertodd: well, my point is all this is only useful *in addition* to existing stuff
262 2013-07-01 05:26:29 <petertodd> nsh: Supposedly mastercard's backend architecture looks rather like Bitcoin...
263 2013-07-01 05:26:33 <Luke-Jr> in a legal context
264 2013-07-01 05:26:35 <nsh> petertodd, so i've heard
265 2013-07-01 05:26:51 <phantomcircuit> petertodd, i find that hard to believe
266 2013-07-01 05:27:07 <nsh> phantomcircuit, maybe not the mathematics, but the architecture
267 2013-07-01 05:27:10 <phantomcircuit> stream processors? absolutely
268 2013-07-01 05:27:11 <nsh> dunno
269 2013-07-01 05:27:21 <petertodd> Luke-Jr: Sure, my point is once the tech is there, independent lawyers will realize they can offer that legal service themselves, gradually changing the way courts look at it all.
270 2013-07-01 05:27:21 <phantomcircuit> nsh, there's no reason for them to do that
271 2013-07-01 05:27:32 <nsh> right, they don't have a trust problem
272 2013-07-01 05:27:35 <phantomcircuit> visa/mastercard are really nothing more than structured messaging networks
273 2013-07-01 05:27:53 <phantomcircuit> they probably store messages but only for auditing reasons
274 2013-07-01 05:28:00 <phantomcircuit> (which is very important for them)
275 2013-07-01 05:28:02 <petertodd> nsh: But they *do* have a consensus problem; lots of consensus solving things looks kinda like Bitcoin if you squint a bit.
276 2013-07-01 05:28:11 <nsh> mmm
277 2013-07-01 05:28:20 <phantomcircuit> petertodd, uh how do they have a consensus problem?
278 2013-07-01 05:28:26 <nsh> i was just imaging what happens if some state collapses like somalia
279 2013-07-01 05:28:33 <nsh> and some criminals get in control of the visa station
280 2013-07-01 05:28:48 <nsh> they ought to have contingencies for that
281 2013-07-01 05:29:12 <nsh> i guess they just stop listening
282 2013-07-01 05:29:12 <phantomcircuit> nsh, there isn't a visa station in somalia for starters
283 2013-07-01 05:29:19 <nsh> right, hypothetical
284 2013-07-01 05:29:43 <phantomcircuit> nsh, hypothetically if militants assault the visa center then they're probably in a lot of trouble
285 2013-07-01 05:29:48 <petertodd> phantomcircuit: All databases are like that - even allowing for going over your limit they still need to come to consensus over what nodes are alive and dead and so on. Pretty standard stuff actually, but from what I've heard mastercard's setup looks more like Bitcoin than most.
286 2013-07-01 05:29:50 <nsh> heh, true
287 2013-07-01 05:29:52 <phantomcircuit> since the audit would cost millions
288 2013-07-01 05:30:08 <petertodd> phantomcircuit: Yeah, hopefully visa's egg basket is one strong basket...
289 2013-07-01 05:30:28 <phantomcircuit> petertodd, supposedly it's very secure
290 2013-07-01 05:30:37 <phantomcircuit> it's probably secure enough they have insurance
291 2013-07-01 05:30:43 <phantomcircuit> which is the real protection
292 2013-07-01 05:31:12 <nsh> the cost of insurance is (theoretically) a function of the non-insurance protections
293 2013-07-01 05:31:19 <petertodd> phantomcircuit: Heh, that'd be a hell of an insurance contract... I could believe that they don't have insurance actually.
294 2013-07-01 05:31:34 <nsh> they're insured by the state, like the big banks :)
295 2013-07-01 05:31:34 <petertodd> phantomcircuit: Potential losses are just so enormous...
296 2013-07-01 05:31:37 <phantomcircuit> petertodd, visa doesn't handle account balances, they only handle preapproval limits which can be safely forgotten
297 2013-07-01 05:31:58 <nsh> some people have some pretty large limits...
298 2013-07-01 05:32:05 <petertodd> petertodd: They do handle account balances, the balances of their *merchants*
299 2013-07-01 05:32:18 <phantomcircuit> nsh, the card limit isn't the same as the preapproval limit
300 2013-07-01 05:32:23 <nsh> oh, ok
301 2013-07-01 05:32:57 <nsh> it's just what requires no human intervention?
302 2013-07-01 05:32:58 <phantomcircuit> petertodd, nope merchants have banks
303 2013-07-01 05:33:10 <phantomcircuit> just the way there are issuing banks there are merchant banks
304 2013-07-01 05:33:27 <phantomcircuit> and the vast majority of merchants deal with an intermediary processor anyways
305 2013-07-01 05:33:39 <phantomcircuit> visa isn't actually directly interacting with your local coffeeshop
306 2013-07-01 05:33:56 <petertodd> phantomcircuit: Oh, so that stuff isn't going throught he visa datacenter? Interesting, that's very different from the way the media was talking about it.
307 2013-07-01 05:34:24 <phantomcircuit> petertodd, it does but it goes through an intermediary who collects all the fees as one
308 2013-07-01 05:34:35 <phantomcircuit> so visa clears to a single processor account
309 2013-07-01 05:34:41 <phantomcircuit> and the processor clears to the merchants
310 2013-07-01 05:34:45 <nsh> makes sense, i guess
311 2013-07-01 05:34:51 <petertodd> phantomcircuit: Right, so the intermediary has a copy of the transaction records essentially.
312 2013-07-01 05:35:08 <petertodd> phantomcircuit: Which means if visa's datacenter goes down it's less of a disaster.
313 2013-07-01 05:36:22 <phantomcircuit> nsh, no it's more liek you go to starbucks and want to buy $4 in coffee, starbucks asks their processor for approval the processor checks for preapprovals, if none it asks visa which checks for preaprovals assuming there isn't one, visa forwards to the issuing bank who replies with success/fail PLUS some approval information to reduce the number of inquiries
314 2013-07-01 05:36:38 <phantomcircuit> petertodd, no it's still a colossal disaster
315 2013-07-01 05:36:43 <nsh> hmm
316 2013-07-01 05:36:48 <phantomcircuit> but everything can be cached