1 2013-01-11 07:33:11 <petertodd> doublec: git clone has a branch option to set the branch during the clone, I'm just wondering if they made a nice easy copy-n-paste thing like they already do in other places
2 2013-01-11 09:09:12 <sipa> gmaxwell: pulling checkcoins should be fine, the only part i'm not fully satisfied with is reporting (and perhaps selecting rollback length, in case of a very large dbcache)
3 2013-01-11 09:10:05 <sipa> BlueMatt: exactly, the proper solution is something like an (alternate) block store
4 2013-01-11 09:19:39 <sipa> BlueMatt: not a global which changes the semantics of pretty much everything
5 2013-01-11 11:55:05 <sipa> Luke-Jr: what was the repo/branchname to get to github's pull request view?
6 2013-01-11 11:56:10 <Luke-Jr> sipa: huh?
7 2013-01-11 11:57:43 <sipa> Luke-Jr: there was some repository url, or a branch name, or ..., to access the pull requests's head and merged view on github
8 2013-01-11 11:57:51 <Luke-Jr> oh that
9 2013-01-11 11:58:11 <Luke-Jr> [remote "origin-pull"]
10 2013-01-11 11:58:12 <Luke-Jr> fetch = +refs/pull/*:refs/remotes/origin-pull/*
11 2013-01-11 11:58:14 <Luke-Jr> url = git://github.com/bitcoin/bitcoin.git
12 2013-01-11 11:58:56 <sipa> thanks!
13 2013-01-11 11:59:38 <Luke-Jr> np
14 2013-01-11 12:11:29 <Luke-Jr> sipa: hey, if the utxo lacks disk positions??? how were we EVER getting raw transactions for ANY txns? :o
15 2013-01-11 12:11:41 <sipa> Luke-Jr: it has heights
16 2013-01-11 12:12:06 <sipa> Luke-Jr: which is enough to find the matching block index entry, read the entire block from disk, and search for our transaction in there :)
17 2013-01-11 12:12:12 <Luke-Jr> ah, and that wouldn't work for non-main-chain txns
18 2013-01-11 12:12:18 <sipa> and is slow
19 2013-01-11 12:12:29 <sipa> and won't work for spent transactions
20 2013-01-11 12:12:47 <Luke-Jr> well, it would if we didn't delete them
21 2013-01-11 12:12:59 <sipa> well, a lot would have to change for that
22 2013-01-11 12:13:12 <Luke-Jr> yeah, your solution is probably better anyway
23 2013-01-11 12:13:38 <sipa> as the CCoins serialization doesn't even support transactions with no outputs remaining, and metadata is stored in undo data for the last input being spent
24 2013-01-11 12:14:37 <sipa> plus, i prefer to keep the coins database as lightweight as possible, as its performance is critical for the core operation... indexes are just optimizations for extra functionality
25 2013-01-11 13:28:15 <sipa> gmaxwell: i'm in favor of reducing the default -checkblocks
26 2013-01-11 13:29:17 <sipa> 2500 takes quite a while if they need to be loaded from a slow disk, and corrupted blocks are no longer a threat to the network (as long as it's not in the range that is potentially reorganized)
27 2013-01-11 13:31:20 <gmaxwell> I'm of the opinion that it should still be "a lot" but that could be a lot less than 2500.
28 2013-01-11 13:31:57 <gmaxwell> How slow is slow? What can your laptop with the spinning disk do in two seconds?
29 2013-01-11 13:33:24 <sipa> i've seen load times of close to a minute when no block data is in cache
30 2013-01-11 13:33:37 <sipa> vs 10s when it is in cache
31 2013-01-11 13:35:05 <sipa> i'd say it needs to be at least 200 blocks
32 2013-01-11 13:38:49 <gmaxwell> I was thinking 'two days worth' (e.g. 288) was "a lot", so somewhat similar. A minute is pretty terrible.
33 2013-01-11 13:48:17 <sipa> gmaxwell: it could be something like "at least 288 blocks and at least 2016 transactions" for example, making it go somewhat further back in older parts of the chain
34 2013-01-11 13:50:11 <sipa> then again, introducing an extra config flag for that is serious overkill
35 2013-01-11 14:26:12 <gmaxwell> https://bitcointalk.org/index.php?topic=135856.msg1448014#msg1448014 ...
36 2013-01-11 14:27:47 <sipa> ?
37 2013-01-11 14:30:17 <gmaxwell> I am wondering if I'm just not getting a joke, piuk is proposing to send penny flood attacks at nodes to deanonymize them better because his realyed by metric isn't terribly accurate?
38 2013-01-11 14:37:22 <sipa> ehhh :s
39 2013-01-11 15:09:16 <helo> what's the best way to count the number of coins that have never moved?
40 2013-01-11 15:09:35 <gavinandresen> helo: use a 64-bit integer.
41 2013-01-11 15:09:43 <gavinandresen> helo: :-)
42 2013-01-11 15:09:51 <helo> haha
43 2013-01-11 15:09:51 <sipa> i'd suggest using arithmetic
44 2013-01-11 15:10:32 <sipa> helo: more seriously, in 0.8 code, iterate over the utxo set (txdb.cpp has code that does this, for gettxoutsetinfo), and add the amounts of all coins that have fCoinbase==true
45 2013-01-11 15:11:09 <helo> can do, thanks :)
46 2013-01-11 15:14:19 <sipa> implemented, compiled, running
47 2013-01-11 15:16:18 <sipa> Never moved: 204719048427238 satoshi
48 2013-01-11 15:16:40 <sipa> 2M BTC
49 2013-01-11 15:17:09 <sipa> gmaxwell: on my VPS:
50 2013-01-11 15:17:10 <sipa> 2013-01-11 16:14:52 Verifying last 2500 blocks at level 3
51 2013-01-11 15:17:10 <sipa> 2013-01-11 16:16:16 No coin database inconsistencies in last 120 blocks (54152 transactions)
52 2013-01-11 15:23:50 <Diapolo> hi there
53 2013-01-11 15:23:58 <Luke-Jr> hey Diapolo
54 2013-01-11 15:29:06 <BlueMatt> sipa: huh?
55 2013-01-11 15:29:09 <BlueMatt> sipa: re: what?
56 2013-01-11 15:29:17 <BlueMatt> sipa: ohhhh
57 2013-01-11 15:29:18 <Diapolo> There are 4 references to CTransaction::FetchInputs() in a comment in main.h, but this function isn't in anymore, a core dev should update these.
58 2013-01-11 15:29:19 <BlueMatt> sipa: nevermind
59 2013-01-11 15:31:05 <helo> ahh neat
60 2013-01-11 15:32:22 <sipa> Diapolo: nice catch
61 2013-01-11 15:32:53 <sipa> Diapolo: that functionality is now hidden begind the CCoinsView interface, so i guess those @see's can just be removed
62 2013-01-11 15:33:19 <Diapolo> sipa: I found that after reading that vuln description by Sergio
63 2013-01-11 15:39:52 <Diapolo> sipa, when creating another test-binary of your turbo branch, can you include the new stack-protector pull?
64 2013-01-11 15:45:41 <sipa> Diapolo: will do
65 2013-01-11 15:46:03 <Diapolo> if (!FindUndoPos(pindex->nFile, pos, ::GetSerializeSize(blockundo, SER_DISK, CLIENT_VERSION) + 40)) it was
66 2013-01-11 15:46:23 <Diapolo> +8 before the recent verify pull, a comment would be nice or a constant :)?
67 2013-01-11 15:54:55 <sipa> jgarzik: didn't you have a pullreq with a generic timer implementation, to replace the wallet unlock thing?
68 2013-01-11 15:55:51 <jgarzik> sipa: generic timer implementation, yes
69 2013-01-11 15:56:07 <jgarzik> sipa: I do not remember what I used it for; I think something network related, not wallet
70 2013-01-11 15:56:18 <jgarzik> sipa: either way, boost's deadline timer should suffice, so I did not push
71 2013-01-11 15:57:22 <jgarzik> sipa: There we go... replaced ThreadDumpAddresses with a timer: https://github.com/jgarzik/bitcoin/commits/timer
72 2013-01-11 15:59:41 <gmaxwell> Getting rid of all our timer threads will nicely reduce memory usage at least on Linux, we actually get a fair amount of bloat from thread stacks.
73 2013-01-11 16:00:30 <sipa> jgarzik: i couldn't find anything in boost, and was very surprised about that :)
74 2013-01-11 16:00:35 <sipa> jgarzik: i didn't look inside asio though
75 2013-01-11 16:00:53 <jgarzik> sipa: yep, asio is the location
76 2013-01-11 16:01:01 <sipa> jgarzik: so i wrote this: https://github.com/sipa/bitcoin/commit/0d1fd2c7e88c1b3b09019730c4151008dda243b3
77 2013-01-11 16:01:12 <jgarzik> sipa: because usually timers are implemented through select(2) or poll(2)
78 2013-01-11 16:01:48 <gmaxwell> Should probably have a work-queue implemented as a heap, with a bunch of items that have a first-runnable-time and just work through them.
79 2013-01-11 16:03:02 <sipa> gmaxwell: a multimap should be almost as good in practice, and a lot less code
80 2013-01-11 16:03:50 <BlueMatt> Diapolo: I have a feeling 1674 is too old for pull-tester to get to it anymore...
81 2013-01-11 16:03:59 <gmaxwell> I was thinking things like peer rotation, resends, and such could go into it.. but even that actally isn't that much stuff.
82 2013-01-11 16:04:01 <jgarzik> sipa: I like the model of keeping a time-ordered list, and iterating through that
83 2013-01-11 16:04:11 <gmaxwell> sipa: what, there isn't some crazy template heap in boost? :P
84 2013-01-11 16:04:13 <jgarzik> sipa: you always know when the next timer will fire
85 2013-01-11 16:04:19 <BlueMatt> Diapolo: (github's api only returns a subset of pull requests...not them all, im gonna eventually try to bitch at them and see if i can get it changed)
86 2013-01-11 16:04:39 <sipa> jgarzik: exactly
87 2013-01-11 16:05:39 <Diapolo> BlueMatt: this explains, why pulltester doesn't catch it, thanks... I asked sipa about integrating it into his next test build then
88 2013-01-11 16:05:56 <sipa> BlueMatt: i've been wanting to rewrite #1674 using union-find
89 2013-01-11 16:06:18 <BlueMatt> Diapolo: I can fire off a manual test if you want
90 2013-01-11 16:06:35 <BlueMatt> sipa: or should i just wait?
91 2013-01-11 16:06:46 <sipa> BlueMatt: nah, no idea when i'll have time for that
92 2013-01-11 16:07:03 <BlueMatt> alright, ill fire off a manual test
93 2013-01-11 16:07:46 <gmaxwell> sipa: what do you actually mean other than #1674?
94 2013-01-11 16:08:11 <sipa> ?
95 2013-01-11 16:08:12 <Diapolo> BlueMatt: thanks :)
96 2013-01-11 16:08:43 <sipa> gmaxwell: i must admit i never really got to understanding the code changes in #1674 - perhaps i should try that first
97 2013-01-11 16:08:54 <gmaxwell> Pull 1674 is "Bitcoin-Qt (Windows): expand GCC Stack-Smashing Protector usage", and if you can apply union-find to that, then I'm impressed. :P
98 2013-01-11 16:09:00 <sipa> uhhh
99 2013-01-11 16:09:18 <sipa> i mean 1647!
100 2013-01-11 16:09:38 <gmaxwell> Ah!
101 2013-01-11 16:09:59 <Diapolo> gmaxwell: ^^
102 2013-01-11 16:09:59 <sipa> we should require a minimal levenshtein distance between the decimal encodings of pullreq numbers
103 2013-01-11 16:10:03 <gmaxwell> We also need gain union-find for taint tracking.
104 2013-01-11 16:10:11 <gmaxwell> But thats on my todo.
105 2013-01-11 16:10:18 <BlueMatt> I like how TD[gone] always spell checks my comments and finds dumb misspellings....
106 2013-01-11 16:10:31 <BlueMatt> sipa: yes!
107 2013-01-11 16:10:34 <sipa> BlueMatt: at least that means he reads everything!
108 2013-01-11 16:10:41 <BlueMatt> sipa: true
109 2013-01-11 16:12:41 <sipa> gmaxwell: i love it when a neat algorithm becomes actually useful :)
110 2013-01-11 16:14:09 <gmaxwell> it's such a fantastic algorithim. It's my go to tool now for explaining the value of algoritims to people. It's simply enough to get exactly right including all the optimizations from memory, and rich enough that it doesn't sound obvious. (e.g. explaining a binary search to people gets a 'well duh')
111 2013-01-11 16:20:23 <sipa> hmm, for a byaddr index... you could index on the output of extractdestinations, or just on hash(outputscript)
112 2013-01-11 16:20:54 <sipa> the first is slightly more functional, but there could be compatibility problems if new templates are added later
113 2013-01-11 16:21:47 <gmaxwell> For a block explorer functionality you do generally want to search on a normalized form. Someone inserting a NOP into your script should still return the txn.
114 2013-01-11 16:23:33 <gmaxwell> Does suggest that the database should have a 'extractdestination version' field, and force reindexing if that gets bumped.
115 2013-01-11 16:23:45 <gavinandresen> sipa: hash(output script). or even truncate(hash(output script)) to save keyspace
116 2013-01-11 16:24:03 <sipa> gavinandresen: i was thinking about hash160(output script)
117 2013-01-11 16:24:07 <gmaxwell> ah, thats a point. False positives are not too harmful.
118 2013-01-11 16:24:29 <gmaxwell> e.g. even 4 bytes of key is probably ample.
119 2013-01-11 16:24:40 <gavinandresen> gmaxwell: exactly???.
120 2013-01-11 16:24:42 <gmaxwell> Though if that were the case the hash should probably be per node and secret.
121 2013-01-11 16:24:42 <sipa> gavinandresen: an average serialized tx reference is 10 bytes now
122 2013-01-11 16:25:03 <sipa> so using something of the same order of magnitude is probably a good compromise
123 2013-01-11 16:25:21 <sipa> so perhaps 64 bits
124 2013-01-11 16:25:32 <gmaxwell> (otherwise some genius could collide the key and make updates to an element go linear, 64 bits would be less risky)
125 2013-01-11 16:26:28 <gavinandresen> well, we've already got some keys that will have gazillions of entries (satoshidice! (say that like "Newman!"))
126 2013-01-11 16:26:57 <sipa> yeah, i don't like the idea of one entry in the db growing to tens of megabytes
127 2013-01-11 16:27:02 <sipa> but it's probably inevitable
128 2013-01-11 16:27:53 <gmaxwell> what could be done is having a parameter (ugh) that blacklists entries when they get too big. But: parameter.
129 2013-01-11 16:27:54 <gavinandresen> disk space is cheap. Transaction fees are supposed to stop those attacks??? when the price dropped from $30 down to $2 we probably should have increased default fees
130 2013-01-11 16:28:39 <gmaxwell> gavinandresen: I mean, right now if you index deepbits address a getbyaddress on it will probably block the process for three minutes and consume 400 mb of ram. :P
131 2013-01-11 16:28:44 <sipa> gmaxwell: haha, just add a flag saying "too many others", and output a "..." in the RPC output :p
132 2013-01-11 16:29:33 <sipa> gavinandresen: there is no policy that punishes reuse of addresses, is there?
133 2013-01-11 16:29:51 <gmaxwell> sipa: well I was thinking more like, a seperate table of blacklisted keys, when you get too many, the key is deleted. Nothing on the blacklist is added, and the RPC returns an error. Then a default setting so that nothing but 1van and dice trigger it. And if you want those, you can set the limit to 0 (infinite). But ::shrugs::
134 2013-01-11 16:29:56 <gavinandresen> import private key and some wallet operations on mega-large wallets are the only places where we'd use the new index right now, right?
135 2013-01-11 16:30:15 <gavinandresen> sipa: no, no policy that punishes address re-use right now.
136 2013-01-11 16:30:29 <sipa> gavinandresen: yes, and perhaps an RPC to expose lookups
137 2013-01-11 16:30:32 <gmaxwell> sipa: I advocated such a policy but it was too easily misunderstood as something specifically targeting dice. (which it wasn't??? but until dice goes away I think it'll keep being misunderstood as that)
138 2013-01-11 16:31:12 <gavinandresen> If we add a RPC to expose lookups, then a param to limit the number returned is a good idea. I'd vote for just an error that says how many there are, and a largish default, for RPC behavior
139 2013-01-11 16:31:40 <gmaxwell> (restating my argument for the logs: the reuse is bad for privacy for everyone, and also it encourages people to get bright ideas about blocking. The reuse of addresses is also a weak implicit signal about a public-usage or existing relationshup which doesn't need fast confirmation... so we ought to greatly deprioritize reuse)
140 2013-01-11 16:32:16 <sipa> gavinandresen: right now, i'm mostly interested in implementing it to see how costly it is, and not so much as in applications of it (though electrum servers would love it)
141 2013-01-11 16:32:42 <gavinandresen> gmaxwell: The Bitcoin Faucet was probably the biggest re-use criminal before SD. I re-used the same address to keep its wallet from growing, and to give complete funding transparency.
142 2013-01-11 16:32:54 <gmaxwell> applications I'd think would be electrum servers, armory, and personal block exploring.
143 2013-01-11 16:32:58 <debiantoruser> Greetings
144 2013-01-11 16:33:10 <debiantoruser> Is there anybody who can explain me, why fee is not a ?????? ??????
145 2013-01-11 16:33:18 <debiantoruser> ??? ??????
146 2013-01-11 16:33:23 <debiantoruser> ?????? ??????
147 2013-01-11 16:33:27 <gavinandresen> darn keyboards
148 2013-01-11 16:33:36 <gmaxwell> Fee is not a pipe?
149 2013-01-11 16:33:37 <gavinandresen> ??? or is he talking in morse code?
150 2013-01-11 16:34:19 <gavinandresen> let's guess: "fee is not a percentage of the transaction amount" ?
151 2013-01-11 16:34:37 <gavinandresen> "fee is not an integer number of satoshis?"
152 2013-01-11 16:34:50 <sipa> "fee is not a zero"
153 2013-01-11 16:34:56 <gmaxwell> "fee is not a free market?"
154 2013-01-11 16:35:13 <jgarzik> "fee is not an alpaca"
155 2013-01-11 16:35:15 <gmaxwell> "fee is not a parameter set bit the recipent?"
156 2013-01-11 16:35:20 <gmaxwell> s/bit/by/
157 2013-01-11 16:35:26 <gavinandresen> "fee is not a DHT" ?
158 2013-01-11 16:35:30 <gmaxwell> ahhhhhhhh!
159 2013-01-11 16:35:31 <helo> hah
160 2013-01-11 16:35:33 <Luke-Jr> that's not pipes, it's tonal!
161 2013-01-11 16:35:35 <Luke-Jr> :P
162 2013-01-11 16:35:42 <Luke-Jr> (j/k ofc)
163 2013-01-11 16:35:45 <gavinandresen> ooh, good one: "fee is not tonal"
164 2013-01-11 16:35:47 <gmaxwell> Ah, "Why the fee is not a tonal number?"
165 2013-01-11 16:36:13 <gmaxwell> (there is still time until april!)
166 2013-01-11 16:36:20 <Luke-Jr> debiantoruser: but seriously, are you going to clarify?
167 2013-01-11 16:38:13 <Luke-Jr> guess not
168 2013-01-11 16:38:23 <jgarzik> Man, this birth is a whole lot of work. Apparently sex triggers labor, so...
169 2013-01-11 16:38:37 <gmaxwell> Reasoning from the markov random field that is my logs the most likely completions are: "fee is not a function!" "fee is not applied" "fee is not a problem" "fee is not a fixed amount" "fee is not a tip!"
170 2013-01-11 16:38:46 <jgarzik> "fee is not a baby"
171 2013-01-11 16:38:47 <Luke-Jr> jgarzik: so does walking
172 2013-01-11 16:38:52 <gavinandresen> all righty???. just FYI for everybody: I've been working on code signing certs for our osx/windows builds, which has turned out to involve an OSX and Xcode upgrade, which I'm halfway through???.
173 2013-01-11 16:38:56 <igetgames> tabasco sauce
174 2013-01-11 16:39:52 <sipa> TD: i agree with not destroying potentially nice applications in the future by blocking something that doesn't seem useful now
175 2013-01-11 16:40:11 <sipa> TD: but clearly, something with a locktime that will take 1 year cannot be expected to remain in memory pools until then anyway
176 2013-01-11 16:40:25 <debiantoruser> @gmaxwell: are my messages clean come?
177 2013-01-11 16:40:39 <Luke-Jr> sipa: was that meant to be in here?
178 2013-01-11 16:40:43 <gmaxwell> debiantoruser: we are waiting with abated breath! "Be sure to drink your ???"
179 2013-01-11 16:40:51 <gmaxwell> debiantoruser: we did not recieve your question.
180 2013-01-11 16:40:57 <gmaxwell> 09:33 < debiantoruser> Is there anybody who can explain me, why fee is not a
181 2013-01-11 16:41:05 <gmaxwell> Thats all we got, and then garbage.
182 2013-01-11 16:41:10 <Luke-Jr> gmaxwell: tor is censoring him
183 2013-01-11 16:42:17 <sipa> debiantoruser: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/01/11
184 2013-01-11 16:42:30 <TD> sipa: nodes could possibly be told how much disk space they can use for storing the mempool and then throw out the futuremost transactions when it fills up
185 2013-01-11 16:42:50 <debiantoruser> Is there anybody who can explain me, why fee is not a one hundred-millionth of a Bitcoin(satoshi)?
186 2013-01-11 16:43:09 <Luke-Jr> debiantoruser: what good would that fee do?
187 2013-01-11 16:43:35 <gavinandresen> TD: I like the idea of limiting the memory pool to (say) 10x the max block size is a great idea, then prioritizing by the same rules you'd use to build a block.
188 2013-01-11 16:43:57 <debiantoruser> Luke-Jr: It is more userfriend for users
189 2013-01-11 16:44:06 <debiantoruser> spam or freedom
190 2013-01-11 16:44:16 <sipa> debiantoruser: by your reasoning, 0 satoshi would even be better?
191 2013-01-11 16:44:18 <gmaxwell> gavinandresen: this has funny interactions with child-pays-for-parent unless we have a reject pool.
192 2013-01-11 16:44:18 <TD> debiantoruser: theoretically the fee should float according to available machine resources
193 2013-01-11 16:44:23 <debiantoruser> Why it is 0.005 - It is really big for saing that we don't get a fee like any another bank transfers system?
194 2013-01-11 16:44:30 <TD> debiantoruser: in practice, that's hard and nobody wrote the code for it yet, so it's a fixed magic number
195 2013-01-11 16:45:00 <lianj> debiantoruser: for now its just a anti spam measure
196 2013-01-11 16:45:01 <TD> debiantoruser: i don't think anyone really knows what the "right" value is, we just know the current value is a decent incentive to not DoS the network, though it doesn't discourage all ultra-high-load users (eg satoshidice)
197 2013-01-11 16:45:07 <BlueMatt> ACTION still wants to have a long and involved fee discussion at some bitcoin dev meetup
198 2013-01-11 16:45:08 <gavinandresen> gmaxwell: good point
199 2013-01-11 16:45:12 <Luke-Jr> debiantoruser: it's apparently too small, in practice
200 2013-01-11 16:45:15 <TD> debiantoruser: if you want to research and prototype better fee schedules then please do so
201 2013-01-11 16:45:32 <jgarzik> sadly fees are related to bitcoin's real world value... something intrinsically not found in the chain
202 2013-01-11 16:46:08 <gmaxwell> Priority queue based dynamic behavior would mean that the system would constantly use the maximum amount of resources regardless of real demand. Certantly reasonable when non-attack load would keep it near that level... unfortunate before then.
203 2013-01-11 16:46:21 <debiantoruser> @jgarzik: You right here, and 1Btc = 10$, then 0.005 - is 5 cent for each tx, it is really big for micropayments systems
204 2013-01-11 16:46:23 <Pucilowski> Does a raw tx refer to a signed or unsigned tx?
205 2013-01-11 16:46:34 <sipa> Pucilowski: both, i guess
206 2013-01-11 16:46:38 <gavinandresen> debiantoruser: see https://gist.github.com/2961409 for lots of thoughts on better-handling fees
207 2013-01-11 16:47:00 <Pucilowski> sipa: are you familiar with armory?
208 2013-01-11 16:47:04 <gavinandresen> debiantoruser: the only thing implemented was a change to miner's transactions selection policy so they sort by fee-per-kb by default
209 2013-01-11 16:47:05 <gmaxwell> debiantoruser: the base fee is 0.0005 in the reference client, not 0.005, 0.005 means the transaction is 10x larger than the base transaction size.
210 2013-01-11 16:47:14 <TD> gmaxwell: well, i'm actually ok with the network being saturated 100% of the time as long as "good" traffic takes priority over "less good" traffic. the alternative is lots of magic numbers that don't really adapt to market forces
211 2013-01-11 16:47:34 <TD> debiantoruser: some clients set the fee larger than it actually needs to be.
212 2013-01-11 16:47:41 <sipa> Pucilowski: not really
213 2013-01-11 16:47:49 <TD> debiantoruser: in particular, anything based on bitcoinj has crap fee handling and often charges fees when none are actually needed
214 2013-01-11 16:48:02 <TD> debiantoruser: also, bitcoin has an alternative way to handle micropayments in which you don't need a separate TX for every micropayment
215 2013-01-11 16:48:11 <TD> debiantoruser: so micropayment apps are still possible, assuming gavinandresen doesn't break it :)
216 2013-01-11 16:48:27 <debiantoruser> Am i right, that my modified client with fee setted to 0 would not send transaction?
217 2013-01-11 16:48:33 <gmaxwell> TD: I know you are, and we disagree. Right now we need all the adoption we can get, and that can be maximized by reducing resource usage. Magic numbers are kinda lame, but at the same time, they're actually more determinstic than adaptive behavior, so thats a plus for them. (one of few)
218 2013-01-11 16:48:37 <gavinandresen> TD: can I break it if I promise to fix it later?
219 2013-01-11 16:48:43 <Luke-Jr> debiantoruser: it would send, but maybe no miner would confirm it
220 2013-01-11 16:49:06 <TD> debiantoruser: it depends on the transaction
221 2013-01-11 16:49:07 <BlueMatt> TD: the reason BLOOM_UPDATE_P2PUBKEY_ONLY wasnt removed after templates were added is there was discussion of whether it was worth it
222 2013-01-11 16:49:10 <TD> debiantoruser: many transactions don't need a fee
223 2013-01-11 16:49:20 <gmaxwell> debiantoruser: depending on the transaction it may not even realy, in which case you may get that input stuck in your wallet.
224 2013-01-11 16:49:27 <BlueMatt> TD: anyway...needs discussion
225 2013-01-11 16:49:36 <BlueMatt> bbl
226 2013-01-11 16:50:33 <Pucilowski> How does an unsigned and signed raw tx vary? Is the signature simply appended onto the end?
227 2013-01-11 16:51:29 <debiantoruser> That is why i'm suggest to set fee to satoshi(0.00000001BTC)
228 2013-01-11 16:51:31 <sipa> Pucilowski: no, unsigned ones have an empty string as their txin script
229 2013-01-11 16:51:43 <debiantoruser> It is ideal for all time
230 2013-01-11 16:51:57 <Luke-Jr> debiantoruser: 0.00000001 BTC fee is no better than no-fee-at-all
231 2013-01-11 16:52:32 <debiantoruser> no-fee-at-all - is a hole for spammers/scammers/fbi, etc
232 2013-01-11 16:53:00 <Luke-Jr> debiantoruser: 0.00000001 BTC is fine for spammers and scammers too
233 2013-01-11 16:53:02 <Luke-Jr> debiantoruser: we like the FBI
234 2013-01-11 16:53:39 <jgarzik> debiantoruser: 0.00000001 BTC is too low to discourage spammers
235 2013-01-11 16:53:50 <debiantoruser> Luke-Jr: if spammers like to lost 1 mill * 0.00000001 BTC, they are welcome! (:
236 2013-01-11 16:53:59 <gavinandresen> debiantoruser: see https://bitcointalk.org/index.php?topic=3332.0 for a discussion of how much it costs the network to process a transaction
237 2013-01-11 16:54:35 <Luke-Jr> debiantoruser: spammers already pay 0.0005 BTC * 1 million :/
238 2013-01-11 16:54:37 <debiantoruser> normal user should get the freedom to send thousands of micropayments!
239 2013-01-11 16:54:47 <lianj> debiantoruser: fyi, coinbase pays the fee for your first x txs of a month
240 2013-01-11 16:54:51 <sipa> debiantoruser: and have the entire network pay for them?
241 2013-01-11 16:55:00 <sipa> debiantoruser: microtransactions are very costly to the system
242 2013-01-11 16:55:46 <jgarzik> debiantoruser: Indeed. Bitcoin is not for micropayments
243 2013-01-11 16:56:05 <sipa> at least, individual bitcoin transactions are not for micropayments
244 2013-01-11 16:56:58 <gmaxwell> did everyone see Peter Todd's plans to make fidelity bonded (and perhaps remote-attestitation secured) chaum token issuing banks for doing fast micropayments off chain? I'm very excited about that and hope it gets done.
245 2013-01-11 16:56:58 <Luke-Jr> gavinandresen: that thread was before, and didn't cover, the risk of orphan block for miners
246 2013-01-11 16:57:43 <gavinandresen> Luke-Jr: more analysis welcome. Has anybody done a good analysis of the orphan block issue?
247 2013-01-11 16:58:07 <debiantoruser> @jgarzik: There are should appear such system, like bitcoin but for micropayments (:
248 2013-01-11 16:58:21 <sipa> debiantoruser: simply not economically feasible
249 2013-01-11 16:58:45 <Luke-Jr> gavinandresen: I'm afraid I don't know of any proper analysis so far.
250 2013-01-11 16:58:58 <gavinandresen> gmaxwell: link to Peter's plans?
251 2013-01-11 16:59:04 <jgarzik> sipa: micropayments are feasible as a layer above bitcoin
252 2013-01-11 16:59:11 <sipa> jgarzik: sure, that'
253 2013-01-11 16:59:25 <Luke-Jr> debiantoruser: it's possible, but not a priority for any developer yet AFAIK
254 2013-01-11 16:59:26 <sipa> jgarzik: sure, that's why i said: 18:56:35 < sipa> at least, individual bitcoin transactions are not for micropayments
255 2013-01-11 16:59:36 <Luke-Jr> debiantoruser: there is a lot of work for the main Bitcoin layer first
256 2013-01-11 17:00:38 <gmaxwell> gavinandresen: he talked about them on IRC. I don't think he has a writeup yet. He's written up one little part. The idea is that you have a bank. It's honesty is machine provable (via the blockchain). The bank is opened by its founders giving away some amount of bitcoin (as fees to random miners) in a provable way. The client software will only do business with a bank if its deposits are less than the given away funds, and if it has never be
257 2013-01-11 17:01:16 <sipa> has never be [...]
258 2013-01-11 17:01:21 <gmaxwell> has never been caught cheating.
259 2013-01-11 17:01:25 <gmaxwell> gavinandresen: any cheating destroys the fidelity bond. Additionally the bank's core can run on an ibm cryptocard, so its behavior is proven a second way as well.
260 2013-01-11 17:02:00 <gmaxwell> The bank would really only have three functions: Recieve bitcoins and give chaum tokens. Convert chaum tokens to chaum tokens (trades). And recieve chaum tokens and return bitcoins.
261 2013-01-11 17:03:03 <gmaxwell> E.g. it would be like mtgox codes. but blinded so the bank can't tell who's transacting with who. ... and secured in a way that scales to more parties than "trust mtgox" does??? unprofitable to cheat through a fidelity bond, and difficult to cheat due to secure hardware.
262 2013-01-11 17:03:15 <gavinandresen> Neat idea.
263 2013-01-11 17:04:13 <sipa> isn't that basically OpenTransactions?
264 2013-01-11 17:04:20 <gavinandresen> Is he thinking the operators would be anonymous, so invulnerable to seizure/shutdown ?
265 2013-01-11 17:04:23 <sipa> or what it aims to do?
266 2013-01-11 17:05:14 <TD> this is just a variant on Hals bitcoin competitor, RPOW
267 2013-01-11 17:05:25 <TD> it's not inherently a bad idea, i'm all for trusted computing
268 2013-01-11 17:05:41 <sipa> i think it's exactly what you want on top of bitcoin
269 2013-01-11 17:05:48 <TD> for many micropayment applications you don't need micropayments to arbitrary constantly changing endpoints though, you really just want to adjust the size of a payment to one party very often
270 2013-01-11 17:05:56 <TD> and bitcoin already has facilities for that
271 2013-01-11 17:06:01 <sipa> chaumian cash is anonymous, fast, and centralized
272 2013-01-11 17:06:25 <TD> if you want to spray micropayments around to totally different parties, sure, it can be useful
273 2013-01-11 17:06:31 <TD> assuming they all agree on which "bank" to use
274 2013-01-11 17:07:07 <gmaxwell> TD: the fidelity bond makes it more than RPOW.
275 2013-01-11 17:08:01 <gmaxwell> The problem the secure hardware has is (1) IBM can profitably cheat, (2) with a big enough bank someone with an electron microscope gamma emitter frobaz can profitably cheat.
276 2013-01-11 17:08:58 <gmaxwell> Fidelity bonds mean that cheating loses you the bond. If you want to shut down you should be able to sell your fidelity bond... so you'd make more money by shutting down honestly and selling the bond.
277 2013-01-11 17:10:25 <hasfijyvydyyyy> I, i'm triyng to code a open source php bitcoin mixing script
278 2013-01-11 17:10:30 <gmaxwell> gavinandresen: I dunno what he thinks, but I think he thinks there would be many of these things and they'd be used for only moderate value.. so the risk from shutdown is not terribly great.
279 2013-01-11 17:11:33 <Luke-Jr> gmaxwell: wait, so this idea is dependent on some proprietary chip being closed-source?
280 2013-01-11 17:12:06 <hasfijyvydyyyy> So the idea is the user make a deposit, the deposit is frammented in multiple wallet, and then send to a main wallet were all transactios pass. Then the amount is sent in different blocks in random amount to different address user provided.
281 2013-01-11 17:12:10 <hasfijyvydyyyy> Should this work?
282 2013-01-11 17:12:36 <gmaxwell> Luke-Jr: No. There are really two ideas with I think are highly complementary. Petertodd's original is pure fidelity bonds. I recommended the cyptocards becuase its an orthorgonal kind of protection and would make people who don't feel comfortable with the fidelity bond happy.
283 2013-01-11 17:13:10 <gmaxwell> hasfijyvydyyyy: not a great idea. Instead people should just write a single joint transaction. Then they don't have to trust that your wallet won't get compromised.
284 2013-01-11 17:13:43 <Luke-Jr> hasfijyvydyyyy: that sounds like laundry, which is illegal most countries???
285 2013-01-11 17:14:20 <gmaxwell> Luke-Jr: the idea behind the cryptocard is that there is hardware??? which can be arbritarily open??? but which contains a private key, signed by a trusted authority that the hardware doesn't let out. The hardware also can perform remote attestation: e.g. it can use that key to sign a message to prove to anyone what software it is currently running.
286 2013-01-11 17:14:22 <hasfijyvydyyyy> Luke-Jr: that will be a script, not a service. Everyone can us it the way they want, as bitcoin
287 2013-01-11 17:15:04 <Luke-Jr> hasfijyvydyyyy: there's a scary court case going on now, which aims to set a precedent that software developers can be prosecuted for how their software is used :/
288 2013-01-11 17:15:24 <hasfijyvydyyyy> in which country?
289 2013-01-11 17:15:46 <Luke-Jr> hasfijyvydyyyy: USA
290 2013-01-11 17:15:56 <hasfijyvydyyyy> gmaxwell: sorry, i'm not a english native language speaker, what is a 'joint transaction'
291 2013-01-11 17:16:14 <Luke-Jr> hasfijyvydyyyy: a single Bitcoin transaction, combining the inputs and outputs of many people
292 2013-01-11 17:16:18 <hasfijyvydyyyy> Luke-Jr: as i thounght :) I will alway stay away from that abuse land
293 2013-01-11 17:16:42 <Luke-Jr> (as if anywhere else is much better)
294 2013-01-11 17:17:20 <hasfijyvydyyyy> some things are better, other are worse
295 2013-01-11 17:17:29 <hasfijyvydyyyy> but it depends on things that we prefer
296 2013-01-11 17:18:02 <hasfijyvydyyyy> sorry, dinner :) i will be back soon
297 2013-01-11 17:19:47 <TD> gmaxwell: you wouldn't use a cryptocard for that these days, trusted computing/TXT is a better framework
298 2013-01-11 17:19:49 <TD> or at least easier to use :)
299 2013-01-11 17:21:17 <gmaxwell> TD: doesn't provide actually secure remote attestation on any of the commidity hardware available today.
300 2013-01-11 17:22:11 <Diapolo> What is better to understand? wallet database or just wallet?
301 2013-01-11 17:22:50 <gmaxwell> TD: or ??? has this happened while I wasn't looking? having to hunt down cryptocards on ebay kinda sucks! :P
302 2013-01-11 17:23:01 <gmaxwell> (plus they're fairly slow)
303 2013-01-11 17:23:55 <Luke-Jr> ACTION ponders if Bitcoin-Qt should support TPM wallet encryption
304 2013-01-11 17:24:14 <gmaxwell> Luke-Jr: doesn't really help much of anything alas.
305 2013-01-11 17:25:08 <Luke-Jr> gmaxwell: it helps the wallet-on-USB-key case
306 2013-01-11 17:25:45 <gmaxwell> Luke-Jr: it does, but a password largely gives you the same help.
307 2013-01-11 17:26:09 <TD> gmaxwell: yes it does
308 2013-01-11 17:26:30 <TD> gmaxwell: you know the page i wrote about storj, right?http://en.bitcoin.it/wiki/Agents
309 2013-01-11 17:28:20 <Diapolo> Is there any sense in having if (!bitdb.Open(GetDataDir())) in init.cpp twice (in step 5 and later in step 7)?
310 2013-01-11 17:28:25 <TD> gmaxwell: you can buy systems from dell and other PC shops where the TPM is integrated into the northbridge, or the CPU. very, very hard to penetrate that. then you can enter a sealed world and remotely attest to the code running within it
311 2013-01-11 17:28:43 <TD> you can flip in and out of the secure realm, but the secure realm still runs regular x86 code you can compile with your normal tools
312 2013-01-11 17:28:48 <TD> it's a pretty nice setup. complicated but nice
313 2013-01-11 17:28:50 <TD> see trustvisor
314 2013-01-11 17:28:54 <gmaxwell> TD: can you pin the cache so you run entirely out of internal memory?
315 2013-01-11 17:29:08 <gmaxwell> (otherwise dram is very easy to shim)
316 2013-01-11 17:29:22 <gmaxwell> (esp if you only need to create a few bitflips to extract a private key)
317 2013-01-11 17:30:40 <Diapolo> sipa: Is there any sense in having if (!bitdb.Open(GetDataDir())) in init.cpp twice (in step 5 and later in step 7)?
318 2013-01-11 17:30:51 <gmaxwell> TD: I'll look, that would certantly make petertodd happy... needing special hardware for this kinda stinks. But I think the fidelity bond alone is not quite persuasive enough, especially if the bond resale market is not very liquid.
319 2013-01-11 17:31:24 <TD> gmaxwell: i don't think there are explicit instructions for that, no, but you can certainly access some memory in order to fill the cache and then use that. do it implicitly. by default after entering the secure realm interrupts are disabled, you run in supervisor mode. so nothing is going to clear the cache underneath you
320 2013-01-11 17:31:43 <Pucilowski> Whats the difference between -server and -daemon?
321 2013-01-11 17:31:50 <TD> gmaxwell: well, you need "special hardware" in that not every cpu/mobo combo supports it. the intel website says which do. but it's certainly not exotic hardware.
322 2013-01-11 17:32:05 <Luke-Jr> pretty sure mine has TPM
323 2013-01-11 17:32:15 <Luke-Jr> no clue how to do anything remotely useful with it tho
324 2013-01-11 17:32:28 <TD> TPM is necessary but not sufficient
325 2013-01-11 17:32:33 <TD> what cpu do you have?
326 2013-01-11 17:32:34 <gmaxwell> yea yea, but right. totally different order of magnitude. You'd like also implement this on a device who's only interface to the outside world was some simple serial bus, rather than a network interface.. but all stuff any geek could setup without much work.
327 2013-01-11 17:33:42 <Luke-Jr> TD: i5-2400
328 2013-01-11 17:33:42 <TD> right. it's a lot easier to order up a nice workstation or server from a PC maker than acquire an ibm cryptocard
329 2013-01-11 17:33:48 <Luke-Jr> TD: Intel DW64SW motherboard
330 2013-01-11 17:33:57 <Luke-Jr> DQ67SW*
331 2013-01-11 17:34:03 <TD> http://ark.intel.com/products/52207/Intel-Core-i5-2400-Processor-6M-Cache-up-to-3_40-GHz
332 2013-01-11 17:34:16 <TD> the CPU supports it for sure. see "trusted execution technology"
333 2013-01-11 17:34:37 <TD> TXT is a bit of a pain in that you typically need to make sure your BIOS is up to date, etc. it's not really deployable by your grandma
334 2013-01-11 17:34:53 <TD> but it's totally doable for somebody to set up a hosting service where the machines you rent are all TXT capable and can remotely attest
335 2013-01-11 17:34:59 <Luke-Jr> TD: if I make a wrong move, am I screwed? :P
336 2013-01-11 17:35:02 <Diapolo> AFAIK TPMs are not yet on-chip?
337 2013-01-11 17:35:27 <gmaxwell> mostly the trusted computing only needs to be hard enough so that people who don't grok the fidelity bond are happy, and so that cracking the txt and stealing the funds takes more work than an ordely shutdown and sell off of your bond.
338 2013-01-11 17:36:03 <TD> Luke-Jr: haha
339 2013-01-11 17:36:05 <TD> you have no idea
340 2013-01-11 17:36:12 <TD> TXT is one of the only ways i know of to actually brick a motherboard
341 2013-01-11 17:36:17 <Luke-Jr> :/
342 2013-01-11 17:36:21 <TD> and i don't mean "brick" as in hipster iphone-jailbreak "brick:
343 2013-01-11 17:36:24 <Luke-Jr> I think I can live without it
344 2013-01-11 17:36:32 <TD> i mean actually turn it into a worthless hunk of metal you have to throw in the trash
345 2013-01-11 17:36:40 <TD> it's only an issue with old BIOS versions, iirc.
346 2013-01-11 17:36:49 <Luke-Jr> ?
347 2013-01-11 17:37:27 <TD> if you invoke TXT with a buggy BIOS version, some motherboards persist some state to some on-board nvram that then cannot be changed, and prevents bootup
348 2013-01-11 17:37:33 <TD> there's no way to recover from it. you need a new motherboard.
349 2013-01-11 17:37:49 <TD> which is why TXT docs come with health warnings at the top :)
350 2013-01-11 17:38:20 <TD> anyway, home time
351 2013-01-11 17:44:13 <Diapolo> I would be happy if some core dev could take a look at my question ^^: Is there any sense in having if (!bitdb.Open(GetDataDir())) in init.cpp twice (in step 5 and later in step 7)?
352 2013-01-11 17:58:23 <Pucilowski> http://puu.sh/1MtEo any ideas?
353 2013-01-11 18:04:54 <gavinandresen> Pucilowski: JSON does not do single-quotes, if I recall correctly
354 2013-01-11 18:07:09 <Pucilowski> i tried wrapping the key in [" "], [], no brackets, etc
355 2013-01-11 18:07:32 <Pucilowski> wrapped in just " " results in error: value is type int, expected array
356 2013-01-11 18:27:57 <gavinandresen> Pucilowski: the windows command shell has funky quoting rules; I don't use windows myself, so have no idea what they are. But some combination of backslashes will make it work....
357 2013-01-11 18:35:12 <jgarzik> heh "some combination of backslashes will make it work" has often been uttered in the presence of Windows
358 2013-01-11 18:48:40 <sipa> is bitcointalk down?
359 2013-01-11 18:49:15 <Guest67321> down for me
360 2013-01-11 18:49:28 <Guest67321> for 1 or 2 hours
361 2013-01-11 18:49:58 <Guest67321> hmmm now up
362 2013-01-11 18:50:16 <Guest67321> strange
363 2013-01-11 18:50:16 <sipa> it seems to be a problem here, i can't access any site
364 2013-01-11 19:00:28 <jgarzik> Schneier blog post "Breaking Hard-Disk Encryption" http://www.schneier.com/blog/archives/2012/12/breaking_hard-d.html
365 2013-01-11 19:00:59 <jgarzik> nothing new
366 2013-01-11 19:13:39 <sturles> There was a session on 29c3 about breaking hard disk encryption. Some interesting teckniques used there. Conclusion: If you have physical access and it is on or the user will turn it on after getting it back, you have won.
367 2013-01-11 19:57:56 <BlueMatt> hmmmm...motherboard smokes, still works....should probably get that replaced
368 2013-01-11 19:59:31 <BlueMatt> TD: anything else you want to see done to bloom filters for bitcoind?
369 2013-01-11 19:59:43 <TD> mempool?
370 2013-01-11 19:59:46 <BlueMatt> done
371 2013-01-11 19:59:52 <TD> in that case, i guess not
372 2013-01-11 20:00:00 <BlueMatt> sipa: do you like/dislike the script matching stuff
373 2013-01-11 20:00:00 <TD> though i should implement mempool in bcj and test it
374 2013-01-11 20:00:12 <BlueMatt> yes, that and the script matching stuff, which is largely untested
375 2013-01-11 20:01:30 <sipa> BlueMatt: i find it hard to say, given that the current applications will only use a subset of the functionality
376 2013-01-11 20:02:27 <sipa> is bip37 up-to-date with the implementation?
377 2013-01-11 20:02:42 <BlueMatt> no
378 2013-01-11 20:02:44 <BlueMatt> t yet
379 2013-01-11 20:03:52 <sipa> so what is the current implementation?
380 2013-01-11 20:05:19 <BlueMatt> its bip 37 + flags to control when/if things get added to the filter automagically
381 2013-01-11 20:05:45 <sipa> and which flags are there?
382 2013-01-11 20:06:48 <BlueMatt> BLOOM_UPDATE_ALL, BLOOM_UPDATE_NONE, BLOOM_UPDATE_P2PUBKEY_ONLY (which does pay2pubkey and multisig pay to pubkey) and BLOOM_UPDATE_SCRIPT_TEMPLATES_ONLY
383 2013-01-11 20:07:06 <BlueMatt> the last being up for debate if people object
384 2013-01-11 20:07:40 <sipa> i don't like the protocol depending on which script templates exist
385 2013-01-11 20:08:28 <sipa> what is script templates only?
386 2013-01-11 20:08:54 <BlueMatt> matches the provided script templates
387 2013-01-11 20:09:24 <sipa> which are sent as part of the filter spec?
388 2013-01-11 20:09:31 <BlueMatt> yes
389 2013-01-11 20:10:02 <BlueMatt> well at least one of BLOOM_UPDATE_SCRIPT_TEMPLATES_ONLY or BLOOM_UPDATE_P2PUBKEY_ONLY really need to be there, and you were talking about sending script templates being overcomplicated
390 2013-01-11 20:10:02 <sipa> so you can simulate P2PUBKEY_ONLY using script templates only?
391 2013-01-11 20:10:08 <BlueMatt> yes
392 2013-01-11 20:10:18 <BlueMatt> i see where this is going....
393 2013-01-11 20:11:03 <sipa> it still feels weird to me that you'd control what stuff causes auto updates, and not what to match
394 2013-01-11 20:11:23 <sipa> if you're going to send a template, you'd certainly want that to be used for matching too
395 2013-01-11 20:12:13 <BlueMatt> well it will match anything, and it just feels weird to provide option to restrict matches, seems like someone may do something weird implementation-wise and hurt privacy
396 2013-01-11 20:12:25 <BlueMatt> that and doing that implementation complicates the matching process further
397 2013-01-11 20:12:41 <BlueMatt> (and as it is, the matching commit is really just a refactor, and id kinda like to keep it that way
398 2013-01-11 20:13:08 <sipa> if i tell you to only do auto-updating on a particular template, i can very reasonably guess that you're only interested in those templates too
399 2013-01-11 20:13:22 <gavinandresen> could you generalize to "match bytes 11-30" ?
400 2013-01-11 20:13:27 <BlueMatt> sipa: not true at all
401 2013-01-11 20:13:42 <sipa> *you can
402 2013-01-11 20:13:49 <BlueMatt> sipa: for pay to pubkeyhash, you care but you dont want it updated
403 2013-01-11 20:14:12 <BlueMatt> gavinandresen: you could, but it just seems like a waste and an over-complication, unless someone has a use-case?
404 2013-01-11 20:14:20 <sipa> right
405 2013-01-11 20:14:38 <sipa> this feels all too complicated
406 2013-01-11 20:14:49 <gavinandresen> I'd just like it to Just Work if we add new script templates in the future.
407 2013-01-11 20:15:17 <BlueMatt> gavinandresen: matching still will, thats the reason why matching doesnt require templates
408 2013-01-11 20:15:23 <sipa> the only problem is address reuse causing a massive amount of false matches, with positive feedback loopbehaviour if you have auto-updating
409 2013-01-11 20:15:29 <sipa> right?
410 2013-01-11 20:15:46 <BlueMatt> sipa: no loop involved, just feedback....yes
411 2013-01-11 20:15:54 <BlueMatt> and im not sure it has to do with address reuse
412 2013-01-11 20:16:06 <BlueMatt> because it matches outpoints, so there is no loop here, just feedback
413 2013-01-11 20:16:17 <sipa> well, the feedback loop is a problem in general, but not one you can solve
414 2013-01-11 20:16:37 <sipa> hmm, right
415 2013-01-11 20:16:48 <BlueMatt> yes, the idea is to limit the feedback, and if you limit to p2pubkey alone, then you limit the feedback very significantly
416 2013-01-11 20:16:55 <BlueMatt> (to around 1tx/block)
417 2013-01-11 20:16:59 <BlueMatt> instead of all of them
418 2013-01-11 20:17:09 <TD> the point of stating in the protocol which output scripts trigger auto-expansion/feedback/etc is so you can avoid hitting popular reused keys
419 2013-01-11 20:17:13 <TD> yeah
420 2013-01-11 20:17:18 <TD> it's a pragmatic change
421 2013-01-11 20:18:34 <gmaxwell> TD: on your client enhancement checklist, you should probably keep a list of false positives you've recieved, and then use them to search for tweaks when you update filters.
422 2013-01-11 20:18:49 <TD> good idea
423 2013-01-11 20:18:53 <TD> there are more important things for now though
424 2013-01-11 20:18:57 <gmaxwell> Absolutely.
425 2013-01-11 20:19:31 <gmaxwell> That just will rescue it in the pessimistic case where something like deepbit or sdice happens to collide with one of your addresses in the default tweak.
426 2013-01-11 20:19:32 <sipa> how about a flag to enable/disable auto_update in general, and have an optional list of templates to filter? (if none provided: match all; if one or more provided: only if it matches any of them)
427 2013-01-11 20:20:01 <MC1984> who is andreas schildbach
428 2013-01-11 20:20:10 <sipa> author of bitcoin wallet for android
429 2013-01-11 20:20:30 <BlueMatt> sipa: do you mean match or update?
430 2013-01-11 20:20:32 <MC1984> yeah does he have a handle in here or whaever
431 2013-01-11 20:20:40 <BlueMatt> sipa: because the issue is, you want to match way more than you want to be auto-added
432 2013-01-11 20:20:43 <sipa> BlueMatt: for updating
433 2013-01-11 20:20:52 <TD> sipa: ?
434 2013-01-11 20:20:58 <BlueMatt> sipa: that is what the pull does, it just happens to add a default P2PUBKEY flag as well
435 2013-01-11 20:21:11 <BlueMatt> (which can be removed if you just want to always send the list of P2PUBKEY templates)
436 2013-01-11 20:21:12 <TD> sipa: right, you want to match against all outputs but only auto-add for some
437 2013-01-11 20:21:24 <TD> MC1984: no, why
438 2013-01-11 20:21:33 <sipa> yes
439 2013-01-11 20:21:43 <TD> BlueMatt: btw there are some findbugs warnings added by the bloom filter code
440 2013-01-11 20:21:53 <gavinandresen> replace the hard-coded enum values with CScript templates, I think sipa means, with the pseudo-opcodes for matching punk
441 2013-01-11 20:21:57 <BlueMatt> TD: alright, Ill look into them
442 2013-01-11 20:22:01 <MC1984> bitcoin wallet disappeared itself off my android tablet :/
443 2013-01-11 20:22:12 <TD> gavinandresen: that's what matt has already done
444 2013-01-11 20:22:15 <sipa> BlueMatt: i dislike the complexity of the templates, but hardcoding particular address types seems just ugly
445 2013-01-11 20:22:16 <TD> MC1984: "disappeared itself" ?
446 2013-01-11 20:22:22 <BlueMatt> sipa: agreed
447 2013-01-11 20:22:30 <BlueMatt> sipa: its kinda ugly either way...
448 2013-01-11 20:22:53 <MC1984> the icon was gone
449 2013-01-11 20:23:01 <MC1984> play store said its not installed
450 2013-01-11 20:23:05 <MC1984> odd
451 2013-01-11 20:23:17 <sipa> BlueMatt: and since the templates subsume the p2pubkey behaviour using only a few tens of bytes in a 36k filter datastructure, i don't think we need it
452 2013-01-11 20:23:20 <TD> that is ?????? not good
453 2013-01-11 20:23:24 <TD> does it appear in your applications list?
454 2013-01-11 20:23:28 <TD> what version of android is this?
455 2013-01-11 20:23:49 <BlueMatt> sipa: I suppose thats fair, it can be removed
456 2013-01-11 20:23:55 <MC1984> i just reinstalled it to see if it really was uninstalled
457 2013-01-11 20:24:10 <TD> i've never heard of that happening before
458 2013-01-11 20:24:19 <MC1984> i think this is the second time its gone a bit strange
459 2013-01-11 20:24:20 <TD> it's bad if it can happen though. uninstallation deletes the wallet
460 2013-01-11 20:24:30 <MC1984> damn
461 2013-01-11 20:24:55 <TD> is this tablet special or unusual in any way? rooted? got unusual apps installed? what version is it?
462 2013-01-11 20:25:15 <MC1984> not rooted
463 2013-01-11 20:25:27 <MC1984> ICS 4 0 4
464 2013-01-11 20:25:55 <MC1984> archos 80 cobalt is the name
465 2013-01-11 20:27:01 <TD> i have no idea how that can have happened, sorry
466 2013-01-11 20:27:41 <MC1984> hmm actually, after reinstall it was only 3 days behind with the chain and my preferences were still set
467 2013-01-11 20:27:57 <MC1984> so its like the system forgot it was installed?
468 2013-01-11 20:28:54 <BlueMatt> on another note, should any additional pseudo-opcodes be added to allow for more generous matching in the future?
469 2013-01-11 20:29:37 <TD> that's totally random. maybe archos have a weird bug in their fork of ics?
470 2013-01-11 20:30:28 <MC1984> yeah its probably that
471 2013-01-11 20:30:40 <MC1984> i paid ?44 for this tablet
472 2013-01-11 20:31:16 <MC1984> spec wise its top end hough apparently
473 2013-01-11 20:31:25 <sipa> BlueMatt: i suppose you can define a range of opcodes that for now match anything
474 2013-01-11 20:31:43 <TD> MC1984: well, it's definitely very strange but glad to hear nothing got lost
475 2013-01-11 20:31:45 <sipa> BlueMatt: so if there is an update in the future, a new client talking to an old server will just get too much
476 2013-01-11 20:31:55 <sipa> instead of missing things
477 2013-01-11 20:32:08 <MC1984> dont have coins on it anyway
478 2013-01-11 20:32:10 <BlueMatt> sipa: ack
479 2013-01-11 20:32:29 <MC1984> have the testnet version though with some testcoins in it and thats never done anything strange
480 2013-01-11 20:32:41 <gavinandresen> ??? these updating opcode-filled scripts are received over the network, right? That makes me nervouse.
481 2013-01-11 20:32:53 <sipa> gavinandresen: why>
482 2013-01-11 20:33:10 <gavinandresen> the pseudo-opcodes haven't been exposed to the network before, they were purely for internal use only
483 2013-01-11 20:33:44 <sipa> well, you could define matcher opcodes separately
484 2013-01-11 20:33:46 <gavinandresen> so if there is a crashing bug of some kind by combining them in some weird way....
485 2013-01-11 20:34:04 <sipa> oooh, you mean in the matching code
486 2013-01-11 20:34:08 <gavinandresen> yes
487 2013-01-11 20:34:23 <sipa> right, i guess i didn't realize network-received patterns would be passed to the matcher engine
488 2013-01-11 20:35:02 <gavinandresen> I thought that is what was being proposed, to eliminate the hard-coded enum.
489 2013-01-11 20:35:28 <sipa> yes
490 2013-01-11 20:36:34 <BlueMatt> gavinandresen: ack, it needs more review before that part could be merged
491 2013-01-11 20:36:41 <gavinandresen> ok. if we do that, we need to carefully re-review the opcode matching code, and maybe write a special-purpose fuzzer
492 2013-01-11 20:37:27 <BlueMatt> it looked reasonably safe when i read it, but it definately needs very close reading
493 2013-01-11 20:37:55 <TD> guh
494 2013-01-11 20:38:01 <TD> can we maybe do that in v2 of the protocol?
495 2013-01-11 20:38:06 <TD> i'd like to get bloom v1 over with and merged
496 2013-01-11 20:38:27 <BlueMatt> we can just leave it with just p2pubkey/all/none for now
497 2013-01-11 20:38:42 <sipa> ok
498 2013-01-11 20:39:10 <gavinandresen> simple to start is good. real-word usage might never need anything more....
499 2013-01-11 20:39:39 <sipa> if everyone only uses p2sh and pay-to-pubkeyhash from now on, there's no need for more :)
500 2013-01-11 20:39:42 <johzi> man, i see this gmaxwell troll here again. i can't believe how he hasn't been banned from the internet yet
501 2013-01-11 20:41:19 <BlueMatt> gmaxwell: why is it that so many people hate you?
502 2013-01-11 20:42:05 <BlueMatt> what did you do to all these kids?
503 2013-01-11 20:42:12 <sipa> BlueMatt: it's always the same kid
504 2013-01-11 20:42:19 <BlueMatt> ahh ok
505 2013-01-11 20:42:21 <BlueMatt> makes more sense
506 2013-01-11 20:42:30 <BlueMatt> someone really has nothing good to do with their time
507 2013-01-11 20:42:55 <johzi> why are you letting the gmaxwell freak be here?
508 2013-01-11 20:43:03 <gmaxwell> it's one person.
509 2013-01-11 20:43:06 <gavinandresen> somebody please kick johzi for off-topic trolling
510 2013-01-11 20:43:08 <BlueMatt> better question: why are we lett
511 2013-01-11 20:43:16 <sipa> BlueMatt: don't feed the troll
512 2013-01-11 20:43:32 <BlueMatt> gmaxwell: aww, beat me to it
513 2013-01-11 20:43:48 <BlueMatt> sipa: somehow i missed ^H and hit enter... on that last one
514 2013-01-11 20:44:09 <Luke-Jr> hmm, someone seems to be trying to exploit Eloipool on Eligius :o
515 2013-01-11 20:44:20 <Luke-Jr> is fd0001 a valid "transaction count"?
516 2013-01-11 20:45:19 <Luke-Jr> nm, forgot this is LE
517 2013-01-11 20:51:03 <MC1984> whats the rationale behind having the chain in 128mb chunks with the new database instead of 2gb
518 2013-01-11 20:51:29 <MC1984> easier to move around via outside methods?
519 2013-01-11 20:53:11 <sipa> MC1984: mostly easier to delete part of it
520 2013-01-11 20:53:27 <MC1984> :o
521 2013-01-11 20:53:35 <midnightmagic> i eased back on trying to talk reason with him because i realised i was talking to him more than I was even talking to my wife in terms of volume and time. i guess perhaps I was doing some good after all. :-/
522 2013-01-11 20:53:51 <sipa> midnightmagic: who?
523 2013-01-11 20:55:25 <sipa> MC1984: needing to delete blocks in blobs of 2GB isn't very nice :)
524 2013-01-11 20:55:44 <sipa> (not that the code does that right now, but maybe somewhere in the future it will)
525 2013-01-11 20:56:08 <MC1984> hopefully never imo
526 2013-01-11 20:56:12 <MC1984> at least not for the desktop version
527 2013-01-11 20:56:22 <MC1984> >implying there will be a desktop in the future
528 2013-01-11 20:58:38 <TD> has anyone got some testcoins they can send me?
529 2013-01-11 20:59:02 <sipa> MC1984: i see providing validation service and providing archival data to the network as separate things, and requiring everyone who wants to do one to also do the other to be a bad thing (which isn't the same as not having the ability to do both, of course)
530 2013-01-11 20:59:37 <TD> testnet faucet is broken
531 2013-01-11 20:59:58 <MC1984> not requiring
532 2013-01-11 21:00:23 <MC1984> but if you can, why not
533 2013-01-11 21:00:27 <sipa> sure
534 2013-01-11 21:00:36 <TD> mg7WkQngYLPxUzpsqGCFGfpLGzAPGLYu5E
535 2013-01-11 21:00:43 <sipa> MC1984: oh, i definitely didn't mean deleting archive data *by default*
536 2013-01-11 21:01:40 <MC1984> i dont think computers would break a sweat doing both for the foreseeable future unless bitcoin EXPLODES
537 2013-01-11 21:02:28 <MC1984> and apart from battery concerns and shitty data caps i could even see mobile devices maybe being able to keep up the way things are going
538 2013-01-11 21:02:50 <sipa> they may, but i really doubt you want to serve history from a mobile
539 2013-01-11 21:03:06 <sipa> even stronger: i wouldn't want accidentally downloading from a mobile
540 2013-01-11 21:03:18 <MC1984> as i said, apart from data caps and battery etc
541 2013-01-11 21:03:32 <sipa> well, those are things to take into account when dealing with reality :)
542 2013-01-11 21:04:07 <MC1984> yeah im not saying make mobile clients full, just making a point about how fast things are advancing
543 2013-01-11 21:04:30 <MC1984> i think this android SPV client is just right
544 2013-01-11 21:05:05 <sipa> especially with bloom filtering added :)
545 2013-01-11 21:05:27 <MC1984> i thought that turned out to not work properly?
546 2013-01-11 21:05:35 <sipa> ?
547 2013-01-11 21:05:41 <Diapolo> TD: some coins are on the way
548 2013-01-11 21:05:48 <TD> thanks !
549 2013-01-11 21:06:21 <sipa> MC1984: it's only been in a state where it can be tested for the past days/weeks or so
550 2013-01-11 21:07:11 <TD> MC1984: it's working quite well
551 2013-01-11 21:07:28 <MC1984> oh well thats good
552 2013-01-11 21:07:35 <MC1984> everything is going to plan
553 2013-01-11 21:07:38 <TD> MC1984: it seems to give me a big speedup, it moves the bottleneck from slow crappy java mobile apps to solid C++ nodes
554 2013-01-11 21:07:48 <TD> and we can probably make it another 3-4x faster on top of that
555 2013-01-11 21:08:05 <TD> right now it seems to speed up sync from a local node by 10x which is pretty nice
556 2013-01-11 21:08:14 <MC1984> you mean its viable to run an SPV ish node on java phones?
557 2013-01-11 21:08:19 <TD> so with a bit more work maybe we can get to something like 40-50x faster than current android app is
558 2013-01-11 21:08:29 <TD> it's viable today, i do it all the time. it syncs at night
559 2013-01-11 21:08:38 <TD> so it only ever has <1 days worth of blocks to catch up with
560 2013-01-11 21:09:09 <TD> bloom filtering makes sync a lot faster for the days worth of traffic and of course, if you leave your phone/tablet switched off for a while, it makes it come back faster.
561 2013-01-11 21:09:14 <TD> also saves a ton of bandwidth on metered connections
562 2013-01-11 21:09:23 <MC1984> how can you do business day to day with only a nightly sync?
563 2013-01-11 21:09:32 <TD> the app still syncs when you open it
564 2013-01-11 21:09:36 <sipa> MC1984: not SPVish; SPV
565 2013-01-11 21:09:38 <TD> but it's never more than about 140 blocks behind
566 2013-01-11 21:09:49 <MC1984> oh
567 2013-01-11 21:10:13 <TD> so that catchup sync is pretty fast
568 2013-01-11 21:10:23 <TD> and yeah it's proper spv
569 2013-01-11 21:10:48 <Diapolo> what is the long form of SPV I've always asked me that ^^
570 2013-01-11 21:10:48 <MC1984> wow bitcoin might just be viable for places like africa and iran
571 2013-01-11 21:11:06 <sipa> Diapolo: simplified payment verification
572 2013-01-11 21:11:16 <sipa> d\tread satoshi?? paper :)
573 2013-01-11 21:11:24 <MC1984> other plaes where the national currency is hyperinflating and stuff
574 2013-01-11 21:11:35 <TD> i wish there was still a testnet block explorer site that worked
575 2013-01-11 21:11:57 <TD> MC1984: anywhere smart phones and cheap tablets can be found, we will be able to run proper p2p wallets
576 2013-01-11 21:12:01 <TD> no centralization
577 2013-01-11 21:12:04 <Diapolo> sipa: I could read weeks on Bitcoin core stuff I guess :D
578 2013-01-11 21:12:32 <MC1984> im talking about circa 2006 java "featurephones"
579 2013-01-11 21:12:59 <MC1984> though it won be too long before even africa and china is awash with cheap androids....
580 2013-01-11 21:13:11 <TD> those phones aren't powerful enough, no, but indeed, android is already taking over in even third world countries
581 2013-01-11 21:13:17 <sipa> MC1984: i really doubt those are finpowerful enough
582 2013-01-11 21:13:18 <TD> the actual limiting factor there is going to be data quota
583 2013-01-11 21:13:52 <MC1984> like i said, bitcoin happened exactly as soon as it could have :)
584 2013-01-11 21:13:58 <MC1984> really cool
585 2013-01-11 21:18:22 <gribble> 216163
586 2013-01-11 21:18:22 <sipa> ;;bc,blocks
587 2013-01-11 21:18:49 <TD> MC1984: for things to take off outside eu/na/russia will take a lot of work. bitcoin is very nerdy.
588 2013-01-11 21:21:05 <MC1984> i have every confidence
589 2013-01-11 21:21:17 <MC1984> look at the bittorrent adoption curve
590 2013-01-11 21:21:42 <TD> bittorrent is a totally different thing
591 2013-01-11 21:22:10 <MC1984> its nerdy
592 2013-01-11 21:22:23 <MC1984> but it solves a problem people might have not even known they had
593 2013-01-11 21:22:32 <TD> bittorrents value proposition is "get stuff for free that you want and you'd have to otherwise pay for"
594 2013-01-11 21:22:43 <TD> yes, surprise, that motivates people to use it
595 2013-01-11 21:22:48 <TD> bitcoin has no such proposition
596 2013-01-11 21:23:04 <MC1984> cough silk road
597 2013-01-11 21:23:07 <Diapolo> dear core devs, I would love to see some non-controversial and already ACKed pulls get merged, the list is getting long and im pushing quite some small pull-reqs these days ;)
598 2013-01-11 21:23:21 <sipa> Diapolo: ACK
599 2013-01-11 21:23:31 <Diapolo> (not talking about mine here as most are GUI stuff)
600 2013-01-11 21:23:37 <MC1984> also simply "transact on the internet WITHOUT paypal"
601 2013-01-11 21:24:01 <sipa> MC1984: what does transact on the internet without paypal give you, when paypal is working fine?
602 2013-01-11 21:24:21 <MC1984> paypl is not working fine
603 2013-01-11 21:24:26 <sipa> papal has its problems, but for consumers they are very limited
604 2013-01-11 21:24:36 <Diapolo> whoever trusts paypal should have zero problem to trust Bitcoin ^^
605 2013-01-11 21:25:15 <TD> we all know the reasons to use bitcoin, but basically, every single attempt to reform/improve online payments EXCEPT paypal has failed
606 2013-01-11 21:25:17 <sipa> gmaxwell, gavinandresen: around 800 MB for a by-txoutscript index
607 2013-01-11 21:25:26 <sipa> i expected worse
608 2013-01-11 21:25:30 <MC1984> lots of people at least know of someone who got fucked over by paypal. Plus bitcoin can undercut them so thats something
609 2013-01-11 21:25:41 <gmaxwell> sipa: whats your key?
610 2013-01-11 21:25:57 <sipa> gmaxwell: 64 bits of Hash160(scriptPubKey)
611 2013-01-11 21:26:04 <MC1984> paypal got big beause of the early partnership with ebay imo
612 2013-01-11 21:26:16 <MC1984> was like a synergysti success, thats why ebay bought them in the end
613 2013-01-11 21:26:38 <TD> ACTION waits for testnet blocks
614 2013-01-11 21:26:40 <MC1984> i was looking at ebid today and wondering, what if they set up thier own bitcoin escrow service?
615 2013-01-11 21:26:54 <MC1984> right now ebid funds a competitor by using paypal :/
616 2013-01-11 21:27:04 <sipa> gmaxwell: both inputs and outputs
617 2013-01-11 21:27:12 <Diapolo> TD: I have the internal miner running ^^ will take a few minutes :D
618 2013-01-11 21:27:28 <gmaxwell> okay, that explains why it's bigger than the full txn database.
619 2013-01-11 21:28:03 <gmaxwell> Still, I do wonder how big it is without the couple worst offenders.
620 2013-01-11 21:28:21 <TD> i think fireduck doesn't want to adopt compressed pubkeys
621 2013-01-11 21:28:32 <sipa> fireduck?
622 2013-01-11 21:28:39 <TD> the guy who runs sd
623 2013-01-11 21:28:49 <sipa> ... why not?
624 2013-01-11 21:28:52 <gmaxwell> TD: is the issue only that no one has written a vanity generator for them?
625 2013-01-11 21:29:19 <TD> he doesn't want to change his addresses. compared it to changing phone numbers for a business that takes all orders via phone. i'm trying to persuade him otherwise
626 2013-01-11 21:29:32 <gmaxwell> ...
627 2013-01-11 21:29:40 <sipa> he can keep using the old addresses
628 2013-01-11 21:29:44 <sipa> just publish new ones
629 2013-01-11 21:29:45 <gmaxwell> Yea, on the subject of peanalizing address reuse??? oy.
630 2013-01-11 21:30:01 <TD> i mentioned that
631 2013-01-11 21:30:25 <sipa> TD: does bitcoinj do compressed pubkeys now, actually?
632 2013-01-11 21:33:38 <Diapolo> How deep in the chain is considered save for that bloom pull-req? Just reading some text in the Wiki ^^.
633 2013-01-11 21:33:56 <sipa> Diapolo: it just filters blocks/transactions
634 2013-01-11 21:34:29 <sipa> in a way that the receiver can still validate the claimed resulting transactions are part of the block
635 2013-01-11 21:36:51 <Diapolo> from what I understand SPV mode is not as "safe" as a thick node, but much faster and more efficient... what decides if that is an acceptable approach in bitcoind / bitcoin-qt.exe or will the just server SPV nodes and not be ones?
636 2013-01-11 21:37:41 <MC1984> SPV nodes need full nodes to work
637 2013-01-11 21:37:58 <sipa> Diapolo: SPV doesn't allow full validation
638 2013-01-11 21:38:35 <amiller_> but it's possible to do full validation with something much lighter than a full node
639 2013-01-11 21:38:42 <TD> sipa: yeah
640 2013-01-11 21:38:46 <TD> sipa: i added it last week.
641 2013-01-11 21:38:48 <Diapolo> sipa: right I want to understand how our client behaves when the bloom pull is in
642 2013-01-11 21:39:06 <sipa> Diapolo: it means it is able to serve filtered blocks to SPV nodes that connect to it
643 2013-01-11 21:39:13 <BlueMatt> amiller_: its not possible without much less than ultraprune
644 2013-01-11 21:40:09 <sipa> amiller_: full validation? not with less cpu or less bandwith... less (trusted) storage is possible
645 2013-01-11 21:40:12 <Diapolo> sipa: but it's not able to be a SPV node?
646 2013-01-11 21:40:21 <sipa> Diapolo: oh no
647 2013-01-11 21:40:47 <sipa> Diapolo: that bloom filter pullreq just implements the server side of block/tx filtering
648 2013-01-11 21:40:49 <Diapolo> sipa: that was a fact unknown to me, as I didn't really dig into that
649 2013-01-11 21:41:01 <sipa> it doesn't allow it to become a lightweight client
650 2013-01-11 21:41:20 <Diapolo> understood
651 2013-01-11 21:55:41 <TD> has anyone got a testnet block explorer?
652 2013-01-11 21:58:00 <Scrat> hm http://blockexplorer.com/testnet
653 2013-01-11 21:58:40 <petertodd> scrat: note the date of the most recent block...
654 2013-01-11 22:00:49 <Scrat> ACTION hides back into his cave
655 2013-01-11 22:01:53 <Scrat> I swear I used it recently and it was working
656 2013-01-11 22:01:54 <Scrat> :/
657 2013-01-11 22:02:13 <petertodd> scrat: if you want to get a copy of the Abe block explorer running on testnet in that cave of yours we'd all appreciate it though :P
658 2013-01-11 22:03:14 <gmaxwell> TD: it would be nice if someone could make a list of blockexplorer features missing in the reference client. With the address index I think there should be no major gaps except a clickable ui.
659 2013-01-11 22:03:28 <TD> the clickable ui is useful though :)
660 2013-01-11 22:05:23 <sipa> idea!!
661 2013-01-11 22:05:40 <sipa> jgarzik had a pullreq some time ago to serve HTTP through the RPC port
662 2013-01-11 22:06:41 <petertodd> nice!
663 2013-01-11 22:06:57 <sipa> i think serving a blockexplorer like site though it would be neat
664 2013-01-11 22:07:45 <petertodd> done right it'd be significantly faster than blockchain and the like too
665 2013-01-11 22:08:04 <petertodd> and finally the satoshi client itself can include twitter bootstrap
666 2013-01-11 22:08:40 <D34TH> sipa: getting the data straight from the tap would be awesome
667 2013-01-11 22:08:46 <D34TH> or pipe as it may be
668 2013-01-11 22:10:08 <gmaxwell> The web stats UI on p2pool is nice, I like it a lot.
669 2013-01-11 22:10:19 <gmaxwell> And I've used the p2pool share explorer many times while troubleshooting things.
670 2013-01-11 22:10:58 <gmaxwell> (well, mostly I use it for the graphs)
671 2013-01-11 22:11:58 <gmaxwell> because of CSRF I'm not keen on exposing the RPC to a browser, but if it were someone could write a whole webui based on talking to the rpc.
672 2013-01-11 22:12:37 <sipa> gmaxwell: or run it on a separate port
673 2013-01-11 22:12:48 <TD> is there a way to get a human-readable tx dump given a hash?
674 2013-01-11 22:12:57 <TD> i don't think so, right
675 2013-01-11 22:12:58 <sipa> TD: getrawtransaction <hash> 1
676 2013-01-11 22:13:05 <TD> ah thanks
677 2013-01-11 22:13:08 <TD> it was the 1 i was missing
678 2013-01-11 22:13:20 <gmaxwell> The 1 seems to have low discoverability.
679 2013-01-11 22:13:21 <TD> ACTION puzzles
680 2013-01-11 22:13:22 <sipa> or decoderawtransaction(getrawtransaction <hash>)
681 2013-01-11 22:14:19 <TD> nLockTime has an off by one error?
682 2013-01-11 22:14:38 <petertodd> how so?
683 2013-01-11 22:15:34 <TD> http://pastebin.com/cMkacR7J
684 2013-01-11 22:15:44 <TD> compare the height of the block vs the lock time
685 2013-01-11 22:17:14 <sipa> :o
686 2013-01-11 22:19:34 <sipa> TD: if all inputs are final, a transaction is final
687 2013-01-11 22:19:40 <sipa> TD: despite having a locktime
688 2013-01-11 22:20:03 <sipa> and with nSequency==0xFFFFFFFF, that is always the case
689 2013-01-11 22:20:09 <TD> oh, of course
690 2013-01-11 22:20:12 <TD> how could i forget that
691 2013-01-11 22:20:16 <gmaxwell> yea, I had fun with this a while back and derpily opend an issue on it. :P
692 2013-01-11 22:29:10 <petertodd> it also needs a "max depth" argument, I figure 10 is probably pretty safe, and hitting max depth is an automatic not-finalizable
693 2013-01-11 22:29:19 <sipa> ?
694 2013-01-11 22:29:35 <petertodd> message to gmaxwell...
695 2013-01-11 22:30:56 <jgarzik> ground control to major tom
696 2013-01-11 22:42:11 <TD> sipa: https://github.com/sipa/bitcoin/commit/3e4655404a8839a03c241fdcf67e063940eb462b
697 2013-01-11 22:42:17 <TD> sipa: you use BN_sub not BN_mod_sub ?
698 2013-01-11 22:45:01 <sipa> TD: you calculate N-x, where x is known to be between 0 and N-1
699 2013-01-11 22:45:31 <sipa> between 1 and N-1 even
700 2013-01-11 22:46:09 <sipa> so N-x is also between 1 and N-1
701 2013-01-11 22:47:04 <TD> right
702 2013-01-11 23:11:38 <phantomcircuit> TD, you around
703 2013-01-11 23:12:00 <TD> for a little bit
704 2013-01-11 23:12:24 <TD> what's up
705 2013-01-11 23:14:01 <phantomcircuit> the google openid provider gives people temporary tokens, i need someway to have users list their old tokens (if they even exist) there used to be a page where they were displayed but it's changed to not show them anymore tl;dr where shoudl i ask about something liek that to actually get an answer?
706 2013-01-11 23:14:41 <TD> i thought there was a mailing list for discussing that stuff
707 2013-01-11 23:14:54 <TD> if you can't find one then mail hearn@google.com and i'll make sure it reaches the right guys
708 2013-01-11 23:15:09 <phantomcircuit> <3
709 2013-01-11 23:15:47 <phantomcircuit> https://groups.google.com/forum/?fromgroups#!forum/google-federated-login-api
710 2013-01-11 23:15:48 <phantomcircuit> derp
711 2013-01-11 23:19:21 <phantomcircuit> hmm yeah it looks like all the tokens are expired from this long ago
712 2013-01-11 23:19:24 <phantomcircuit> (they're really old)
713 2013-01-11 23:21:52 <sipa> anyone a suggestion for a shorter RPC name than getrawtransactionsbyaddress
714 2013-01-11 23:22:44 <phantomcircuit> sipa, grtba
715 2013-01-11 23:22:47 <phantomcircuit> ACTION runs
716 2013-01-11 23:23:08 <sipa> phantomcircuit: this is not fortran
717 2013-01-11 23:24:51 <phantomcircuit> aha
718 2013-01-11 23:25:53 <EasyAt> is getrawtxbyaddress bad?
719 2013-01-11 23:27:52 <gmaxwell> sipa: what is getrawtransactionsbyaddress and how is it not gettransactionsbyaddress?
720 2013-01-11 23:28:28 <sipa> gmaxwell: it returns results similar to getrawtransaction and not to gettransaction (it is not a wallet RPC)
721 2013-01-11 23:29:03 <gmaxwell> why not just have one returning txids?
722 2013-01-11 23:30:08 <sipa> because you're probably also interested in confirmations for example, which are already looked up anyway, and you can't find by txid (unless you also have the per-txid index)
723 2013-01-11 23:30:09 <gmaxwell> hm. I don't know which callers mostly need??? the txns themselves or just their ids.
724 2013-01-11 23:30:27 <gmaxwell> OKAY.
725 2013-01-11 23:31:19 <sipa> ACTION tries ./bitcoind getrawtransactionsbyaddress 1dice6wBxymYi3t94heUAG6MpG5eceLG1
726 2013-01-11 23:32:25 <sipa> (first waiting for 2500 blocks to be checked)
727 2013-01-11 23:32:45 <BlueMatt> can we decrease 2500 to something lower
728 2013-01-11 23:32:52 <sipa> yes!
729 2013-01-11 23:33:24 <sipa> 15:28:45 < sipa> gmaxwell: i'm in favor of reducing the default -checkblocks
730 2013-01-11 23:33:27 <sipa> 15:29:47 < sipa> 2500 takes quite a while if they need to be loaded from a slow disk, and corrupted blocks are no longer a threat to the network (as long as it's not in the range that is potentially reorganized)
731 2013-01-11 23:33:42 <sipa> hmmm... empty result :(
732 2013-01-11 23:34:47 <gmaxwell> sipa: are you allocating the result on the stack? :P
733 2013-01-11 23:35:42 <gmaxwell> speaking of loading, does the GUI really need to monopolize the screen with that popup at startup? I only use the GUI with testnet for testing on my laptop and even waiting for that irritates me.
734 2013-01-11 23:36:03 <sipa> nope, my iterator over the entries in the database started at addrid==0, and used a while (iter.addrid == addrid)
735 2013-01-11 23:36:07 <sipa> so it quit immediately
736 2013-01-11 23:37:56 <sipa> ok, an iter->Next() is also useful for those who want loops that run in finite time
737 2013-01-11 23:54:45 <sipa> gmaxwell: i can get up to 8500 transactions for a dice address
738 2013-01-11 23:54:50 <sipa> if i ask for more, JSON fails