1 2013-07-29 12:44:29 <BlueMatt> petertodd: ...
2 2013-07-29 12:44:56 <petertodd> BlueMatt: Hey, it works and is easy to understand. Replace 1s with 0.1s or 0.01s if required.
3 2013-07-29 12:45:26 <gmaxwell> petertodd: it's pretty easy to end up with those approaches leaking information still.
4 2013-07-29 12:45:34 <BlueMatt> for timing specifically, ok, but there is more than one kind of side-channel attack, and by making sure the code runs in constant time, other side-channels are less likely to appear
5 2013-07-29 12:46:31 <petertodd> gmaxwell: Why? If you do it on both incoming and outgoing, and set the interval > longest signature time, the attacker can observe nothing more than the phase of your clock relative to theirs.
6 2013-07-29 12:46:38 <gmaxwell> petertodd: e.g. easy for a small delay to get rounded to zero, or a large delay to be quantized so that the timing leaks in some fraction of cases .. and as bluematt points out, cache sidechannels (which ecdsa implementations create), or power side channels still remain.
7 2013-07-29 12:47:21 <gmaxwell> (not that I'd disagree with adding some timing noise absent other protection??? but it's not a real replacement)
8 2013-07-29 12:47:31 <petertodd> gmaxwell: This isn't a delay, this is a fixed schedule. IE regardless of when the signature operation completes, don't send it to the outside world except on a multiple of a whole second, or whatever interval you want.
9 2013-07-29 12:48:16 <gmaxwell> petertodd: yes, and you end up with a timer implementation that rounds to seconds (say) and then leaks when the start time is late enough it would have rounded to zero.
10 2013-07-29 12:48:36 <gmaxwell> (and getting accurate timing is not platform independant code, so it's more security important crap thats hard to test)
11 2013-07-29 12:49:40 <petertodd> gmaxwell: Right, but the start time doesn't need to be under the attackers control either. Again, every second process the queue of outgoing messages, and process the queue of incoming messages. However long the operations happen in between that interval is unobservable provided they take less time than the interval.
12 2013-07-29 12:50:25 <petertodd> Accurate timing doesn't even matter, because the timing variation has nothing to do with how long the signature operations took.
13 2013-07-29 12:50:26 <gmaxwell> petertodd: still observable to someone who is flooding you with pings and measuring the jitter to tell when you're in sleep. :P
14 2013-07-29 12:51:12 <petertodd> gmaxwell: Yes, which is why you subject *all* messages to this routine.
15 2013-07-29 12:51:21 <gmaxwell> _ping_
16 2013-07-29 12:51:29 <petertodd> ACTION looks at watch
17 2013-07-29 12:51:50 <gmaxwell> as in your kernel is doing this. If you're going to postulate writing a kernel implementation of signing ... use a fking constant time one!
18 2013-07-29 12:52:29 <sipa> TD: the curve-specific optimized EC implementations in OpenSSL are timing-attack resistant (fully, ever for verification, afaik), but the generic implementation (which bitcoin currently uses for secp256k1) isn't
19 2013-07-29 12:52:31 <petertodd> OK, I'm at a quarter of a minute multiple, so I'll send out my queue of responses: pong
20 2013-07-29 12:53:10 <petertodd> You learned *nothing* about how long it took me to process a ping, except that it took less than 15 seconds..
21 2013-07-29 12:53:23 <gmaxwell> ICMP ECHO REQUEST
22 2013-07-29 12:53:25 <gmaxwell> not bitcoin pings.
23 2013-07-29 12:53:34 <sipa> PC LOAD LETTER
24 2013-07-29 12:53:54 <petertodd> LP0 ON FIRE
25 2013-07-29 12:54:24 <sipa> 402 PAYMENT REQuired
26 2013-07-29 12:54:54 <petertodd> gmaxwell: Ah, but if you are postulating stuff like ICMP echo requests, you are already in the regime where my strict schedule is making life at least an order of magnitude more difficult for you.
27 2013-07-29 12:55:21 <petertodd> sipa: 5JirDvEYVarkTqWtkSpkLB9geH2nFudmjFmhAwikXUNiFGqdk7b
28 2013-07-29 12:56:19 <petertodd> gmaxwell: Heck, even if you do think you have a constant time signmsg implementation, the strict schedule is good protection from screwups.
29 2013-07-29 12:58:07 <gmaxwell> petertodd: yea, sure, belt and suspenders is great. I was just objecting to the "add timing fuzz" as a general replacement for constant time.
30 2013-07-29 12:58:48 <gmaxwell> For something like a lossy audio codec where making it constant time is engineering unrealistic best practice is timing the output when you want to hide the timing side channel.
31 2013-07-29 12:58:50 <petertodd> gmaxwell: Right, but you gotta admit, what I'm proposing isn't fuzz, it's something significantly better. It only becomes fuzz through second-order effects.
32 2013-07-29 12:59:41 <gmaxwell> (What you do for audio is that after compressing this packet you hold it and the audio read (triggered by the DSP clock) of the next frame makes you release it)
33 2013-07-29 13:00:17 <petertodd> gmaxwell: Right, pretty much exactly what I'm proposing.
34 2013-07-29 13:16:13 <sipa> jgarzik, petertodd: not sure you saw this yesterday, but i did a benchmark of bitcoind-headersfirst-parallelblocksync-libsecp256k1 on a fast machine with large dbcache, from random peers in 43 minutes
35 2013-07-29 13:16:23 <sipa> </brag>
36 2013-07-29 13:16:29 <petertodd> sipa: deserved
37 2013-07-29 13:16:30 <jgarzik> cool
38 2013-07-29 13:16:56 <petertodd> sipa: you planning on doing any work re: spv/partial mode too?
39 2013-07-29 13:16:56 <sipa> a second run took 46 minutes
40 2013-07-29 13:17:55 <sipa> petertodd: spv, likely - i'd like to see the ui/wallet move to a separate spv-ran process, with a fully vverifying bitcoind process forked off if wanted
41 2013-07-29 13:18:20 <sipa> even if it remains one codebase for now
42 2013-07-29 13:19:59 <petertodd> sipa: Cool, once SPV works I don't think implementing partial is a big deal. For that metter, with blockheaders implementing partial is probably not bad either, it's just it's not useful as a wallet without SPV.
43 2013-07-29 13:21:08 <sipa> spv is basically headersonly + wallet-driven filtered fetching
44 2013-07-29 13:21:16 <sipa> instead of blockchain-driven fetching
45 2013-07-29 13:21:31 <sipa> it's sort of neat
46 2013-07-29 13:21:42 <sipa> there is a pindexBest and a pindexBestHeader
47 2013-07-29 13:21:54 <sipa> and the latter is guaranteed to be always a descendant of the first
48 2013-07-29 13:22:19 <k9quaint> nobody likes Thailand anyway!
49 2013-07-29 13:22:20 <petertodd> Oh, so in pure SPV pindexBest is likely to be just the genesis block?
50 2013-07-29 13:22:24 <sipa> but you can perfectly keep pindexBest at genesis
51 2013-07-29 13:22:31 <sipa> exactly
52 2013-07-29 13:22:52 <sipa> pindexBest is really "the current utxo state"
53 2013-07-29 13:22:59 <sipa> tgere could be more levels
54 2013-07-29 13:23:12 <sipa> like if script validation is done asynchronously
55 2013-07-29 13:23:18 <petertodd> Hmm... in partial pindexBest will usually == pindexBestHeader, and then we need to add pindexBestOldest or something less awkwardly named
56 2013-07-29 13:23:39 <sipa> let's worry about that later
57 2013-07-29 13:23:56 <sipa> i don't think there is a problem in supporting that
58 2013-07-29 13:24:09 <petertodd> Good, so long as you're not designing anything into a corner.
59 2013-07-29 13:24:24 <sipa> the difficult part was making the best-chain decision be headers-based rather than block based
60 2013-07-29 13:25:06 <sipa> anyway, this is not pullreq ready yet, though feel free to try (it's in my jeadersfirst branch)
61 2013-07-29 13:25:16 <sipa> headersfirst
62 2013-07-29 13:25:39 <sipa> reindex doean't work yet (as it can't deal with out-of-order blocks on disk)
63 2013-07-29 13:25:57 <sipa> and there are some issues with steady-state syncing
64 2013-07-29 13:26:18 <sipa> (which tries to avoid the intermediate header sync, to avoid extra propagation delay)
65 2013-07-29 13:26:24 <TD> i was hoping you'd do pruning first. oh well.
66 2013-07-29 13:26:49 <sipa> pruning
67 2013-07-29 13:26:51 <sipa> and bip32
68 2013-07-29 13:26:58 <sipa> and headers-first/spv
69 2013-07-29 13:27:10 <sipa> and secp256k1
70 2013-07-29 13:27:13 <TD> the difference being that there's already an spv implementation, whereas there's no node that prunes
71 2013-07-29 13:27:18 <sipa> and refactoring
72 2013-07-29 13:27:29 <sipa> i can't choose
73 2013-07-29 13:27:33 <sipa> so i do what i like
74 2013-07-29 13:27:52 <TD> *shrug* alright. if it's just for entertainment purposes, go wild
75 2013-07-29 13:28:12 <petertodd> sipa: too bad that headersfirst touches so much consensus critical code :(
76 2013-07-29 13:28:12 <sipa> well, headers first is far more useful than just spv
77 2013-07-29 13:28:40 <petertodd> sipa: IMO pruning is much more interesting with partial mode and SPV myself
78 2013-07-29 13:28:46 <sipa> petertodd: it doea not touch connectblock, checktransaction, connecttransaction, accepttransaction, ...
79 2013-07-29 13:28:46 <TD> why? from-zero bootstrap of a full node will always be slow. you can optimise it, which will change it from "very slow" to "slow" for a while, but then it'll be back to "very slow" again.
80 2013-07-29 13:29:14 <TD> that's why the website tells users to pick between "i want it now" and "i want to help the network"
81 2013-07-29 13:29:15 <sipa> that doesn't make it useless
82 2013-07-29 13:29:28 <sipa> but i agree, pruning is also interesting
83 2013-07-29 13:29:32 <TD> it's not useless, but it won't significantly impact anyones decision about what software to run (or shouldn't)
84 2013-07-29 13:29:58 <petertodd> TD: partial mode can contribute back to the network for incresingly large % of transactions, including helping provide block history to others bootstrapping
85 2013-07-29 13:30:11 <petertodd> TD: and it can provide SPV security until it reaches full-node status
86 2013-07-29 13:30:34 <sipa> but it requires some boring lobbying work and bips to get some flags about block availability in p2p
87 2013-07-29 13:30:50 <petertodd> TD: We really need "run a full node" to be a default thing to do if you've got some spare bandwidth and disk space.
88 2013-07-29 13:30:50 <sipa> not that i expect much objection
89 2013-07-29 13:30:55 <sipa> but it's not fun
90 2013-07-29 13:31:02 <TD> sipa: yeah i doubt it'd involve much "lobbying", per se
91 2013-07-29 13:31:07 <petertodd> sipa: No, although partial is different than what you proposed, so yet more discussion...
92 2013-07-29 13:31:13 <TD> petertodd: well, that's what the website tells people.
93 2013-07-29 13:31:23 <TD> (if they want to donate that spare bandwidth/disk space)
94 2013-07-29 13:31:35 <TD> imho there's really only two speeds that matter - instant and not instant
95 2013-07-29 13:31:37 <petertodd> TD: Indeed, and the website's advice turns users off because their node doesn't seem to do anyting for ages.
96 2013-07-29 13:31:47 <TD> moving aroundin between those two speeds is relatively uninteresting, from a users pov
97 2013-07-29 13:31:49 <petertodd> TD: three speeds, you forgot "apparently instant"
98 2013-07-29 13:31:56 <TD> well. same thing :)
99 2013-07-29 13:32:12 <petertodd> TD: partial is very much apparently instant :)
100 2013-07-29 13:32:40 <sipa> partial is really spv + background upgrading to full, while beinh increasingly useful during that period
101 2013-07-29 13:33:13 <TD> the simplest way to implement that is just make bitcoind into a windows service, and then have it run in the background, and make MultiBit+friends always try connecting to localhost
102 2013-07-29 13:33:31 <TD> so if you decide to help out, you just download+run some background thing, and carry on as normal
103 2013-07-29 13:33:34 <petertodd> sipa: yup, the only thing different from what people have proposed before is the realization that partial can do useful relaying without every block processed
104 2013-07-29 13:33:39 <TD> you're upgraded to full security when you're caught up and beyond that it's transparent
105 2013-07-29 13:33:50 <TD> the nice thing about that is - no complicated changes to the codebase are required.
106 2013-07-29 13:34:25 <sipa> TD: yes, i like that model
107 2013-07-29 13:34:41 <gmaxwell> [OT] if anyone wants to watch me make a fool of myself presenting on Opus (audio codec I work on), I'll be presenting at the IETf technical plenary, which runs from 1740-1940 CEST (the opus stuff will start half way through or so)
108 2013-07-29 13:34:48 <TD> gmaxwell: good luck!
109 2013-07-29 13:34:52 <gmaxwell> stream at http://www.meetecho.com/ietf87/tech_plenary slides at: http://www.ietf.org/proceedings/87/slides/slides-87-iab-techplenary-5
110 2013-07-29 13:35:10 <gmaxwell> TD: I'm only talking for 10 minutes of it and got half my slides slimmed out. :P but it should be fun. Thanks.
111 2013-07-29 13:35:17 <petertodd> gmaxwell: nice!
112 2013-07-29 13:35:26 <sipa> gmaxwell: break a leg!
113 2013-07-29 13:35:51 <petertodd> TD: yeah, ironically for really important stuff complicated changes to the user's idea of what's going on is required, but those people need to know what they're doing...
114 2013-07-29 13:43:37 <petertodd> TD: is it easy in multibit to add arbitrary stuff to the bloom filter and get a call back when it matches?
115 2013-07-29 13:44:12 <TD> multibit is a GUI app. you mean bitcoinj, i think.
116 2013-07-29 13:44:26 <petertodd> doh, thinko
117 2013-07-29 13:44:28 <BlueMatt> petertodd: yes(ish)
118 2013-07-29 13:44:28 <petertodd> yeah, bitcoinj
119 2013-07-29 13:44:31 <BlueMatt> as of 0.10
120 2013-07-29 13:44:32 <TD> yes
121 2013-07-29 13:44:39 <TD> see this class: http://plan99.net/~mike/bitcoinj/0.9/com/google/bitcoin/core/BloomFilter.html
122 2013-07-29 13:44:53 <TD> as BlueMatt says, in 0.10 we made it easier to add your own bloom filter that augments any added by the Wallet class
123 2013-07-29 13:45:38 <TD> you can also add pubkeys to a Wallet and it'll do the standard tracking stuff for you, in 0.10 you can also add ask it to track transactions that aren't relevant (i.e. you don't have any keys or addresses in the wallet)
124 2013-07-29 13:45:56 <TD> 0.10 is current git master, but i'm working on releasing it this week. there aren't many changes going in now.
125 2013-07-29 13:46:10 <TD> (just writing more docs and rewriting the getting started tutorial, actually)
126 2013-07-29 13:46:28 <petertodd> Ah cool, I guess the other question, is can I ask the wallet to track arbitrary scriptPubKeys?
127 2013-07-29 13:48:43 <TD> there's no direct API for that, but it can be achieved by implementing a PeerFilterProvider (object that serves bloom filters), then adding it to the PeerGroup so it's merged with the rest and uploaded. Then you can subclass wallet and override isTransactionRelevant() to return true when you see your special scriptPubKey (i.e. drop the false positives)
128 2013-07-29 13:49:18 <BlueMatt> dont even have to subclass wallet, you can just listen for those txn directly on the peer connections and forward them to a regular wallet
129 2013-07-29 13:49:19 <TD> it's a bit of an unusual use case. i wouldn't be surprised if something weird happens :) but that would cause any transaction containing that scriptPubKey to be inserted into the wallet and have its confidence tracked, as per usual
130 2013-07-29 13:49:22 <TD> of course it might die if you try and create a spend
131 2013-07-29 13:49:25 <BlueMatt> (using the override isRelevant flag)
132 2013-07-29 13:49:35 <gmaxwell> Ah, mp3 stream at http://ietf87streaming.dnsalias.net/ietf/ietf874.m3u (and the streams should be starting now)
133 2013-07-29 13:49:36 <TD> BlueMatt: need to include confirmed transactions
134 2013-07-29 13:49:46 <BlueMatt> well, yes, and scan blocks too
135 2013-07-29 13:50:16 <TD> BlueMatt: why replicate all that when you could just override the wallets notion of relevancy? perhaps we should tighten up this bit of API and document it/do an example app
136 2013-07-29 13:50:50 <TD> BlueMatt: using the wallet as a container of arbitrary transactions you want to track and save isn't unreasonable. really it should be refactored into a base class that just tracks things/processes re-orgs, etc, and then a subclass that knows how to craft spends
137 2013-07-29 13:50:58 <TD> it's been on my todo list since forever but there are always higher prioritites
138 2013-07-29 13:51:00 <BlueMatt> TD: I suppose it doesnt really matter, but subclassing and overriding internal methods just looks ugly
139 2013-07-29 13:51:26 <TD> well, technically isTransactionRelevant is public. so you're not overriding an internal method. but yes, to properly support that, we'd want to document how to do it safely
140 2013-07-29 13:51:47 <petertodd> Yeah, an arbitrary transaction container sounds about right - just thinking about what it'd take to do a "savings wallet" implementation based on my one-time-password oracle idea.
141 2013-07-29 13:52:03 <TD> i haven't read up on that one yet so can't really say
142 2013-07-29 13:52:28 <petertodd> TD: basically the oracle idea, except you are the oracle and your answers are "these coins are now allowed to move
143 2013-07-29 13:52:31 <petertodd> "
144 2013-07-29 13:52:47 <TD> you can already do normal savings wallets by just adding the pubkey with no private part. but that wouldn't work for exotic script types.
145 2013-07-29 13:52:52 <petertodd> TD: could wind up with a pad of paper with codes, and each ocde authorizes, say 1BTC of funds to be spent
146 2013-07-29 13:53:52 <petertodd> TD: no control of *where* the funds go, but it's an extremely simple and robust mechanism to control the rate they are spent - you could have your CFO out on his yaught authorizing funds to be unlocked for a business unit with a sat phone and a pad of paper
147 2013-07-29 13:55:28 <TD> i guess so
148 2013-07-29 13:55:37 <TD> it's an interesting idea. not sure if trezor makes it redundant though
149 2013-07-29 13:55:46 <TD> but there's a certain robustness to a pad of paper that everyone likes :)
150 2013-07-29 13:57:21 <petertodd> TD: yeah, just a different way of solving the problem with different tradeoffs, of course, in some cases it's actually useful that the authorizer doesn't need to know anything, heck, they can authorize a spend before the funds even arrive
151 2013-07-29 13:57:37 <TD> yeah
152 2013-07-29 13:57:39 <petertodd> As always though, getting funds *into* the wallet safely requires thought.
153 2013-07-29 13:57:51 <TD> well, it's my goal that bitcoinj is the easiest and best way to write any kind of interesting contracts app.
154 2013-07-29 13:58:01 <TD> it's imperfect for that in many ways today, but gets better with every release
155 2013-07-29 13:58:36 <petertodd> Well, note that P2SH support is quite useful there, for instance for ensuring oracles learn nothing in advance about what they are authorizing.
156 2013-07-29 14:00:23 <TD> yes. the only reason P2SH isn't implemented is that it hasn't been an important feature for mobile users so far. if someone did implement it, i'd merge the changes in but i don't intend on doing it myself any time soon. deterministic wallets and the payment protocol are the most important things next
157 2013-07-29 14:00:31 <TD> also reviewing and maybe merging BlueMatt's work to kill off netty
158 2013-07-29 14:02:54 <petertodd> Well, maybe you'll get lucky and alp will implement it.
159 2013-07-29 14:03:27 <petertodd> jdillon's opcode whitelist idea seems reasonable to me too, although only if you consider excess stack items at the end of execution to make a tx non-std
160 2013-07-29 14:09:01 <jgarzik> Steve132, a private key may yield an uncompressed or compressed public key, each with their own associated hash values (bitcoin addresses)
161 2013-07-29 14:09:08 <jgarzik> Steve132, compressed should always be used, these days
162 2013-07-29 14:09:20 <Steve132> thanks
163 2013-07-29 14:09:31 <jgarzik> Steve132, In any case, you really should keep your keys private, and not send them to a remote server, just to make such a simple calculation
164 2013-07-29 14:10:09 <Steve132> Obviously. I'm actually just experimenting with something
165 2013-07-29 14:10:35 <Steve132> but yes, for any actual real money, obviously I would not do that
166 2013-07-29 14:22:49 <Krellan> gmaxwell: Last night I let bitcoind rebuild the chainstate and database directories, it finally finished, however it kept crashing at startup
167 2013-07-29 14:23:08 <Krellan> however it would last longer before crashing: it ran for a minute or so on the bitcoin network
168 2013-07-29 14:24:11 <Krellan> my shellscript kept restarting bitcoind, and I'm glad it worked - eventually, bitcoind received newly solved blocks
169 2013-07-29 14:24:14 <Krellan> and when my TX eventually got mined by somebody, bitcoind was now happy, and kept running. It's running fine now, hasn't crashed in hours.
170 2013-07-29 14:24:27 <Krellan> I have captured the last few restarts in scrollback if interested.
171 2013-07-29 14:25:19 <Krellan> This was the "mempool transaction missing input" assertion failure at main.cpp:4251
172 2013-07-29 14:28:53 <Krellan> Interesting how the behavior changed from "die instantly upon startup" to "die a few seconds into the run after establishing network connections".
173 2013-07-29 14:29:21 <Krellan> That was what let it limp until it was able to immediately see a new block on the network and thus find the missing pieces of the TX it needed in order to solve its missing input.
174 2013-07-29 14:41:15 <Krellan> bitcoind listtransactions includes immature, however, bitcoind listunspent does not. Is there a way to make listunspent also include this? Trying to make a script to email me when block found.
175 2013-07-29 14:54:40 <Steve132> What happens if I send two transactions really fast through addresses I control? Like, I send a transaction from address A to address B...then, after it hits the network but before it has any confirmations or is included in a block, resend the same coin
176 2013-07-29 14:54:41 <Steve132> from B
177 2013-07-29 14:54:46 <Steve132> somewhere else
178 2013-07-29 14:54:55 <Steve132> It's not a double-spend, its just a relay
179 2013-07-29 14:55:00 <Steve132> would it be detected as a double-spend?
180 2013-07-29 14:56:38 <Scrat> Steve132: detected by what? and no, it's not a double spend
181 2013-07-29 14:56:53 <Scrat> in fact you can do that in a b.i wallet (send unconfirmed outputs)
182 2013-07-29 14:57:15 <Steve132> Ok.
183 2013-07-29 15:13:05 <TD> scary
184 2013-07-29 15:13:20 <TD> someone is trying to use bitcoinj to write an app without having read satoshi's paper, indeed without any bitcoin knowledge at all
185 2013-07-29 15:13:41 <TD> ACTION fixes the docs/web page to point users at the paper before anything else
186 2013-07-29 15:17:22 <jgarzik> TD, scary yet will continue again and again ;p
187 2013-07-29 15:17:42 <TD> "the docs use terms like 'output' or 'change address' that aren't defined anywhere"
188 2013-07-29 15:17:44 <jgarzik> TD, tons of people download and use bitcoind because they heard it was virtual money, and never read the paper
189 2013-07-29 15:17:45 <TD> hmmm ...
190 2013-07-29 15:17:48 <TD> yeah
191 2013-07-29 15:17:56 <TD> users is one thing. developers - that's something else :)
192 2013-07-29 15:18:05 <jgarzik> true :)
193 2013-07-29 15:23:25 <gmaxwell> TD: _lots_ of people show up trying to build bitcoin _implementations_ without having read the paper, much less apps.
194 2013-07-29 15:23:31 <TD> lol
195 2013-07-29 15:23:44 <TD> damn. i didn't know someone tried to create an implementation without reading the paper. that's bad.
196 2013-07-29 15:24:00 <gmaxwell> And the paper doesn't really walk you through the subtle stuff carefully. E.g. it never bludgeons you that the consensus is only _eventual_. :P
197 2013-07-29 15:24:27 <TD> it doesn't? i thought the section where he writes an entire program to calculate the probability of reversals made that point pretty clear
198 2013-07-29 15:25:12 <gmaxwell> I've observed people thinking they don't need to worry about it because "oh thats high hashpower attacks", the point that small reorgs happen even without attackers surprises people.
199 2013-07-29 15:25:27 <gmaxwell> Ending up with people whos software breaks when something unconfirms and reconfirms. :P
200 2013-07-29 15:25:42 <TD> d'oh
201 2013-07-29 15:25:46 <gmaxwell> (e.g. one amusing one processed transactions twice in that case!)
202 2013-07-29 15:25:48 <lle> bludgeons, hehe
203 2013-07-29 15:25:50 <TD> yeah. well that's why satoshi was against a kind of listtransactions call
204 2013-07-29 15:26:20 <TD> the new bitcoinj "getting started" tutorial shows how to register callbacks for any given depth, but perhaps i should explicitly call out that it could potentially run twice.
205 2013-07-29 15:27:30 <gmaxwell> all this stuff can be discerned from the paper, but if you are very "task driven" ... "How do I do X? Tell me nothing else!" you won't catch that stuff.
206 2013-07-29 15:27:37 <TD> that's true
207 2013-07-29 15:27:49 <TD> the thought of people treating a bitcoin API the same as any regular API fills me with fear
208 2013-07-29 15:27:59 <gmaxwell> (it's sometimes hard even walking task driven people through some of these corner cases on a 1:1 basis)
209 2013-07-29 15:28:19 <gmaxwell> With the _right_ api you could probably hide a lot of the corner cases but not one would want to use it.
210 2013-07-29 15:28:22 <TD> i want to put a gigantic <blink> tag at the top of every webpage saying "YOU ARE HANDLING MONEY, SO DO IT RIGHT IDIOT"
211 2013-07-29 15:28:32 <gwillen> the bad thing about writing bitcoin code may be that you lose money if you get it wrong
212 2013-07-29 15:28:36 <gwillen> but the good thing is it will get fixed real fast
213 2013-07-29 15:28:41 <jgarzik> Yeah, that's an interesting bitcoin side-effect
214 2013-07-29 15:28:49 <jgarzik> It is /too easy/ to write a website that handles money, now :)
215 2013-07-29 15:28:54 <gwillen> yeah
216 2013-07-29 15:29:15 <gmaxwell> gwillen: well, it really cranks the "attackers are adaptive" to another level: a lot of software will fail if the user does something unexpected, but in bitcoin the user gets _paid_ for exploiting it more often than most things. :)
217 2013-07-29 15:29:23 <gwillen> right
218 2013-07-29 15:29:33 <TD> yeah. requiring someone to manually convert data from your web app into wire transfers by hand does and wait several days, does at least avoid some potential screwups :)
219 2013-07-29 15:29:36 <gwillen> people aren't good at thinking adversarially, they're really spectacularly bad at it
220 2013-07-29 15:29:47 <gwillen> but when money shows up, suddenly it becomes obvious why you need to
221 2013-07-29 15:30:10 <nsh> +1
222 2013-07-29 15:30:22 <gmaxwell> TD: right, and you could give a bitcoin API that immitated that kind of high latency process.. But, if you know that you need that interface you're smart enough that you don't.
223 2013-07-29 15:30:29 <TD> indeed
224 2013-07-29 15:36:57 <TD> right. health warning added to the tutorial.
225 2013-07-29 15:45:03 <BlueMatt> ACTION has never read satoshi's full paper
226 2013-07-29 15:45:15 <BlueMatt> so...I guess I fall into the category of building implementations without reading it
227 2013-07-29 15:45:22 <TD> you never read the paper?
228 2013-07-29 15:45:30 <BlueMatt> well, most of it
229 2013-07-29 15:45:44 <TD> boggle :)
230 2013-07-29 15:51:04 <gmaxwell> BlueMatt: wtf. it's like 8 pages of light reading! :P
231 2013-07-29 15:58:53 <BlueMatt> gmaxwell: exactly, and if you skim you can skip 7.5 of them
232 2013-07-29 15:58:58 <BlueMatt> ACTION -> home