1 2013-01-14 00:47:17 <MC-Eeepc> Basically we used to think double-spending a zero-confirmation transaction took some effort, and doing so could be detected by the receiver. It turns out that's not true.
2 2013-01-14 00:47:30 <MC-Eeepc> wow is that the nail in the coffin for zero conf
3 2013-01-14 00:47:58 <porquilho> what are you talking about
4 2013-01-14 00:48:18 <porquilho> idont know nothng about zero-conf
5 2013-01-14 00:48:36 <andytoshi> MC-Eeepc: elaborate? you still need to isolate part of the network
6 2013-01-14 00:48:44 <andytoshi> it's not hard, but certainly not trivial
7 2013-01-14 00:48:50 <MC-Eeepc> https://bitcointalk.org/index.php?topic=135985.20
8 2013-01-14 00:49:00 <MC-Eeepc> this guy with a new attack apparently
9 2013-01-14 00:49:38 <andytoshi> ACTION is reading
10 2013-01-14 00:50:03 <MC-Eeepc> only the devs know the details
11 2013-01-14 00:50:58 <andytoshi> yeah, that's what it looks like
12 2013-01-14 00:53:18 <andytoshi> interesting, i suppose us mortals will just have to wait and see
13 2013-01-14 00:53:54 <MC-Eeepc> serious enough that theyre doing the whole cve proces thing
14 2013-01-14 00:54:19 <porquilho> seems to me that is a problem that doesnt affect bitcoin fundamentaly
15 2013-01-14 00:56:17 <TradeFortress> Is there any logging of JSON-RPC calls?
16 2013-01-14 00:56:22 <TradeFortress> Coins stolen L/
17 2013-01-14 00:56:23 <TradeFortress> :/*
18 2013-01-14 00:57:34 <Cusipzzz> TradeFortress: debug.log - you allowed remote RPC?
19 2013-01-14 00:58:00 <TradeFortress> thanks, will look into debug.log
20 2013-01-14 00:58:46 <TradeFortress> Think attacker used curl or something, remote RPC isn't allowed
21 2013-01-14 00:59:36 <TradeFortress> no timestamps??
22 2013-01-14 01:00:46 <TradeFortress> and it doesn't show the parameters used?
23 2013-01-14 01:04:12 <gmaxwell> MC-Eeepc: I dunno who this "we" was that thought they could be detected, but it was never me.
24 2013-01-14 01:06:10 <MC-Eeepc> maybe
25 2013-01-14 01:06:23 <MC-Eeepc> but this guy claims its now utterly trivial to do and works every time
26 2013-01-14 01:06:57 <andytoshi> gmaxwell: there has been a lot of talk on IRC along the lines of "the 'first' transaction will go through"
27 2013-01-14 01:07:17 <andytoshi> and if you define 'first' using the blockchain temporal order, as "the one that goes through", that's correct
28 2013-01-14 01:07:20 <andytoshi> :P
29 2013-01-14 01:07:25 <andytoshi> but i think it's misleading
30 2013-01-14 01:07:43 <andytoshi> (not from any devs, mind you, just something i've seen on #bitcoin)
31 2013-01-14 01:16:27 <TradeFortress> what happens if you call move with one of the addresses being an empty string ('')
32 2013-01-14 01:23:02 <kjj> if you do, then you are in luck, because every wallet contains an account named ''
33 2013-01-14 01:23:38 <kjj> and if you do raw transactions, but want to keep your books straight, you and '' will become good friends in no time
34 2013-01-14 01:25:03 <gmaxwell> MC-Eeepc: mostly it's TD that is telling people that it's okay to accept unconfirmed transactions. I don't agree. And I think that when people talk about they need to start prefacing it with "Mike says".
35 2013-01-14 01:25:46 <gmaxwell> https://bitcointalk.org/index.php?topic=135985.msg1452599#msg1452599
36 2013-01-14 01:27:41 <MC-Eeepc> from a technical standpoint its either ok or its not
37 2013-01-14 01:27:52 <MC-Eeepc> why isnt there a consensus
38 2013-01-14 01:28:09 <MC-Eeepc> if its not ok, then its up to whoever to decide if the risk level is acceptable for the business they do
39 2013-01-14 01:28:27 <gmaxwell> MC-Eeepc: because the only people who think tecnical matters are simply "ok or its not" are people on the sidelines who've never done actual engineering. Everyhting is compromises.
40 2013-01-14 01:29:08 <MC-Eeepc> like i said, if its not ok then what is the risk level
41 2013-01-14 01:29:22 <MC-Eeepc> sounds like a difference of opinion over the risk level tbh
42 2013-01-14 01:30:02 <gmaxwell> I disagree with what TD says??? I think he both understates the risk, and also doesn't adequate overstate it, but he's not crazy. I would prefer to overstate the risk, becuase those who can handle the risk can reason it out for theselves and they don't need to listen to me saying do or don't.
43 2013-01-14 01:30:41 <gmaxwell> There are plenty of cases where its perfectly safe to accept unconfirmeds regardless of how risky you think they are.
44 2013-01-14 01:31:47 <MC-Eeepc> well the thing about the attack is lowering the threshold for a double spend yet again
45 2013-01-14 01:31:50 <MC-Eeepc> or increasing the risk
46 2013-01-14 01:32:21 <MC-Eeepc> id like it if zero conf was at an acceptable risk level for atleast maybe 10 dollars worth of value/goods :/
47 2013-01-14 01:32:50 <gmaxwell> MC-Eeepc: Basically whever this comes up I feel like TD responds to all examples of unconfirmed risk with a neverending series of evasions, often involving behavior no one takes and software which no one has written, which still wouldn't eliminate the risk.
48 2013-01-14 01:32:57 <gmaxwell> MC-Eeepc: thats not enough information.
49 2013-01-14 01:33:39 <gmaxwell> A $10 risk is fine if you can't iterate it. :P If I can steal a penny from a bank and automate it a zillion times an hour I can be rich before the operator returns to their desk from the weekend.
50 2013-01-14 01:34:13 <MC-Eeepc> yeah, well it depends on your business
51 2013-01-14 01:34:39 <MC-Eeepc> you could auto double spend an MP3 purchase a million times
52 2013-01-14 01:34:47 <MC-Eeepc> have you stolen a million dollars of value?
53 2013-01-14 01:35:00 <gmaxwell> Right. And even if you have? did you want to? :P
54 2013-01-14 01:35:29 <MC-Eeepc> the answer is no, but put that mp3 on bittorrent and the answer becomes yes. amirite
55 2013-01-14 01:35:45 <gmaxwell> So I just prefer to say they are flat out unsafe. ... and if you're okay with that, then you're a candidate for accepting them anyways.
56 2013-01-14 01:36:15 <MC-Eeepc> sounds like difference of perspective on the issue
57 2013-01-14 01:36:22 <MC-Eeepc> the engineer says this is unsafe
58 2013-01-14 01:36:35 <Luke-Jr> I accidentally double-spent the first 999,999 times. Every time after the first, I was trying to pay again because I messed up!
59 2013-01-14 01:36:41 <MC-Eeepc> the merchant says eh, theres money ti be made lets do it anyway
60 2013-01-14 01:36:43 <gmaxwell> E.g. First accept that they are unsafe. Then, if you accept that and don't care??? because of $other_reasons... then go ahead and accept them.
61 2013-01-14 01:37:09 <Luke-Jr> finally after the millionth time double-spent, I gave up :<
62 2013-01-14 01:37:50 <MC-Eeepc> to be fair no one has at any point said zero conf was anything close to safe
63 2013-01-14 01:38:11 <TradeFortress> is there a tutorial or something on multisig transactions with PHP?
64 2013-01-14 01:38:13 <gmaxwell> MC-Eeepc: yea, I have no beef with making a total risk analysis that lets you take them. I have a complaint about saying they are unsafe _before_ considering external security and business issues.
65 2013-01-14 01:38:29 <TradeFortress> I want to do something blockchain.info style where the server can't steal coins
66 2013-01-14 01:38:38 <gmaxwell> MC-Eeepc: sure, Mike has, and we even got an academic paper rebutting that position.
67 2013-01-14 01:38:42 <TradeFortress> with multisig transactions, so the client JS and server has to both sign.
68 2013-01-14 01:39:18 <gmaxwell> (sadly, I didn't think it was a great paper at the time??? since it was not news to me??? but I think in restrospect it's been far better than the average bitcoin paper)
69 2013-01-14 01:39:41 <Luke-Jr> TradeFortress: gavin is working on that
70 2013-01-14 01:39:56 <TradeFortress> so it's not usable now?
71 2013-01-14 01:40:00 <gmaxwell> MC-Eeepc: http://eprint.iacr.org/2012/248.pdf
72 2013-01-14 01:40:06 <Luke-Jr> TradeFortress: not with bitcoind or Bitcoin-Qt at least
73 2013-01-14 01:40:16 <gmaxwell> Luke-Jr: huh!?#@!
74 2013-01-14 01:40:24 <TradeFortress> not with RPC calls?
75 2013-01-14 01:40:25 <Luke-Jr> gmaxwell: raw transactions != usable
76 2013-01-14 01:40:27 <gmaxwell> Luke-Jr: he says "with PHP" meaning with the api. It's perfectly usable with the api.
77 2013-01-14 01:40:35 <Luke-Jr> TradeFortress: only if you do all the heavy lifting yourself
78 2013-01-14 01:40:45 <MC-Eeepc> this client is now totally stuck syncing on block 193000 exactly
79 2013-01-14 01:40:49 <Luke-Jr> gmaxwell: "perfectly usable"? :/
80 2013-01-14 01:40:52 <MC-Eeepc> what are the chances
81 2013-01-14 01:41:00 <gmaxwell> MC-Eeepc: whats in the log?
82 2013-01-14 01:41:13 <MC-Eeepc> i tell you when it opens
83 2013-01-14 01:41:35 <gmaxwell> Luke-Jr: okay, well, depends on what you're using it for.
84 2013-01-14 01:41:53 <gmaxwell> TradeFortress: what are you trying to do exactly?
85 2013-01-14 01:42:02 <porquilho> good pdf gmaxwell
86 2013-01-14 01:42:15 <Luke-Jr> to me it sounded like he wanted to run a site acting as the 2nd signature of a multisig wallet
87 2013-01-14 01:42:45 <MC-Eeepc> bool LoadExternalBlockFile(FILE*, CDiskBlockPos*)() : Deserialize or I/O error caught during load
88 2013-01-14 01:43:11 <MC-Eeepc> lots of shit i havent seen before
89 2013-01-14 01:43:33 <gmaxwell> MC-Eeepc: I guess you were using bootstrap?
90 2013-01-14 01:44:10 <MC-Eeepc> why do you say that
91 2013-01-14 01:44:37 <gmaxwell> LoadExternalBlockFile
92 2013-01-14 01:45:19 <MC-Eeepc> oh wait i did have bootstrap.dat in that directory
93 2013-01-14 01:45:30 <MC-Eeepc> i thought -cnnect override it
94 2013-01-14 01:46:04 <MC-Eeepc> also its now bootstrap.dat.old......
95 2013-01-14 01:46:04 <TradeFortress> gmaxwell: I want to make a online wallet service where the user supplies their own private key.
96 2013-01-14 01:46:16 <MC-Eeepc> does the bootstrap not work with the new db or what
97 2013-01-14 01:46:22 <TradeFortress> Coins sent will be to a multisig address 2 of 2
98 2013-01-14 01:47:49 <gmaxwell> MC-Eeepc: I just think there was some existing issue with bootstraps > 2gb where it breaks right at the end, should be harmless except for not reading the last of the blocks.
99 2013-01-14 01:48:04 <TradeFortress> Or is there an easy way to do what Blockchain.info is doing?
100 2013-01-14 01:48:13 <gmaxwell> That isn't what blockchain.info is doing.
101 2013-01-14 01:48:58 <TradeFortress> Yes, I know, blockchain.info makes the client sign TXes, etc locally with js
102 2013-01-14 01:49:43 <MC-Eeepc> thats not secure
103 2013-01-14 01:50:08 <MC-Eeepc> "use this code we just gave you to sign your super secret key lol"
104 2013-01-14 01:50:17 <MC-Eeepc> the new megaupload is doing the same thing
105 2013-01-14 01:50:31 <TradeFortress> MC-Eeepc: but the private key isn't sent to the server
106 2013-01-14 01:50:41 <MC-Eeepc> specifically for plausible deniability of the contents of files too
107 2013-01-14 01:51:19 <gmaxwell> TradeFortress: sure, but what happens when the server then sends updated JS that _does_ send it to the server?
108 2013-01-14 01:51:43 <gmaxwell> What happens when the servr lies about the value of the user's coins and causes them to spend them out to fees?
109 2013-01-14 01:51:43 <TradeFortress> gmaxwell: I'm working on a chrome extension that stores all JSes locally :)
110 2013-01-14 01:52:29 <TradeFortress> Yeah, there's still security risks, but if you don't use the service your coins can't get stolen at least.
111 2013-01-14 01:57:10 <gmaxwell> damnit grau
112 2013-01-14 01:57:45 <gmaxwell> WHY WILL NOT JUST RUN THE TEST OVER THE P2P PROTOCOL? There is no reason to convert it to JSON first.
113 2013-01-14 02:00:04 <kjj> yawn. that whole paper to describe an attack that requires the attacker to know your IP address in advance, and to tell us to relay doubles instead of dumping them
114 2013-01-14 02:04:49 <gmaxwell> kjj: we can't simply relay them.
115 2013-01-14 02:05:01 <gmaxwell> otherwise the dos attack is trivial. :(
116 2013-01-14 02:05:13 <gmaxwell> kjj: and the attacker knowing your IP is pretty reasonable.
117 2013-01-14 02:05:48 <kjj> only in the trivial case of a guy with a website and a wallet on the same box
118 2013-01-14 02:07:11 <kjj> and alerts have the same DOS problem
119 2013-01-14 02:09:09 <MC-Eeepc> whats the nick of the guy who runs blockchain.info
120 2013-01-14 02:09:15 <MC-Eeepc> is he in here
121 2013-01-14 02:09:40 <copumpkin> piuk I think, when he's around
122 2013-01-14 02:09:43 <copumpkin> or something like that
123 2013-01-14 02:10:47 <MC-Eeepc> his probes are not very identifiable
124 2013-01-14 02:11:26 <TradeFortress> he is piuk
125 2013-01-14 04:14:34 <MC-Eeepc> how can verification be multi threaded when verifying the chain is a linear operation?
126 2013-01-14 04:15:23 <kjj> heh. you want to think about it for a minute?
127 2013-01-14 04:18:31 <MC-Eeepc> txn verify can be multi thread
128 2013-01-14 04:18:47 <MC-Eeepc> but what about when its just headers before the checkpoint
129 2013-01-14 04:20:35 <jgarzik> it's not just headers before a checkpoint
130 2013-01-14 04:20:53 <jgarzik> bitcoin has to build the unspent transaction output (UTXO) dataset
131 2013-01-14 04:21:02 <jgarzik> that requires pre-checkpoint data
132 2013-01-14 04:21:16 <kjj> but even if it was just checking header hashes, that is totally parallelizable too
133 2013-01-14 04:22:12 <kjj> as in, you could dispatch a gang of hash jobs, and wait until they all get back before you compare them
134 2013-01-14 04:24:18 <MC-Eeepc> but if one fails, the works for the others is lost too if they were later
135 2013-01-14 04:24:29 <kjj> so?
136 2013-01-14 04:24:33 <MC-Eeepc> wait im stating the fkin obvious here
137 2013-01-14 04:51:07 <etotheipi_> whoa, super interesting!
138 2013-01-14 04:51:22 <etotheipi_> a 25.6 BTC bet to SD was reversed at zero-confirmations
139 2013-01-14 04:51:38 <etotheipi_> it was based on a tx that had 43 inputs, 7 kB
140 2013-01-14 04:51:43 <kjj> hey, did you get any more insights into the way listtransactions works?
141 2013-01-14 04:52:07 <etotheipi_> that tx was replaced by ... a *zero-fee* tx that was 83 inputs and 14 kB
142 2013-01-14 04:52:27 <etotheipi_> kjj: not yet
143 2013-01-14 04:53:02 <etotheipi_> doesn't that sound like a miner helped?
144 2013-01-14 04:55:25 <Cusipzzz> etotheipi_: they're changing it to not show wins/losses until confirmed. but yeah, an obvious target.
145 2013-01-14 04:56:43 <kjj> are you trying to make an RPC interface for armory, or are you trying to make sense of RPC calls to a satoshi client?
146 2013-01-14 04:58:18 <etotheipi_> kjj, trying to make an RPC interface for Armory
147 2013-01-14 04:58:28 <etotheipi_> and I thought I would try to match Satoshi client as close as possible
148 2013-01-14 04:58:51 <kjj> heh. I'm not sure that is wise
149 2013-01-14 04:59:11 <etotheipi_> well, I wanted to basically make something that was a superset of bitcoind functionality
150 2013-01-14 04:59:14 <kjj> I get the feeling that a lot of the RPC quirks just sort of fell out of the way the C++ code handles things
151 2013-01-14 04:59:17 <etotheipi_> but I'm not sure that's really feasible
152 2013-01-14 04:59:32 <etotheipi_> I might just go ahead and implement it my own way
153 2013-01-14 04:59:46 <kjj> like I think I have a decent understanding of how listtransactions works, but I haven't put it to much of a test
154 2013-01-14 04:59:57 <etotheipi_> there's a lot of things that will have to be different anyway (like all calls that are made to watching-only wallets)
155 2013-01-14 05:01:39 <kjj> basically, listtransactions works on the copies of transactions stored in the wallet
156 2013-01-14 05:02:13 <kjj> it iterates them, and for each secret that is also in the wallet, it spits out an entry, either send or recieve
157 2013-01-14 05:03:33 <kjj> oh, and somewhere along the way, it bunches them up. so like when I'm going consolidation transactions that redeem 10 inputs from one key and send it back to the same key, that shows up twice (once coming and once going)
158 2013-01-14 05:03:50 <etotheipi_> kjj: that's the part that's really confusing me
159 2013-01-14 05:03:59 <etotheipi_> if it has one entry for each output...
160 2013-01-14 05:04:23 <etotheipi_> is it one entry for the whole debit (if it's sending), and then one more for each non-change output?
161 2013-01-14 05:04:50 <kjj> I use different addresses for my p2pool mining nodes, so each block p2pool solves, I get several entries in my listtransactions, once for each key
162 2013-01-14 05:05:42 <etotheipi_> is there a reason I shouldn't use my LedgerEntry stuff, that's pretty much already done?
163 2013-01-14 05:05:44 <kjj> on the input side, I'm not so sure. it looks like it *should* list two "send" transactions
164 2013-01-14 05:06:33 <etotheipi_> it's txDir={send, receive, toself}, amount=BTC exchanged, and net=total-wallet-balance-movement
165 2013-01-14 05:06:50 <etotheipi_> and then I can nest some lists to show recipients
166 2013-01-14 05:07:08 <kjj> depends what your users want
167 2013-01-14 05:07:47 <etotheipi_> at least it will represent a solid partition of the space
168 2013-01-14 05:07:50 <kjj> what you get from listtransactions is kinda useful at a low level, but can be confusing
169 2013-01-14 05:08:04 <etotheipi_> thats' why I'm so confused by the listtransactions... because it seems it would be a mess to figure out your balance (if you didn't have getbalance)
170 2013-01-14 05:08:24 <kjj> the problem with a simple ledger is that bitcoin transactions aren't simple at all.
171 2013-01-14 05:08:33 <etotheipi_> I can include all the details
172 2013-01-14 05:08:37 <etotheipi_> via nesting
173 2013-01-14 05:08:45 <kjj> oh shit, I just realized change...
174 2013-01-14 05:09:07 <etotheipi_> change is complicated... but yeah I already got all that covered (like figuring out how much you sent yourself when you had to also send change)
175 2013-01-14 05:09:18 <kjj> I think that change is magicked away when you ask for the list, but I'm not sure how. probably just not shown
176 2013-01-14 05:09:35 <etotheipi_> basically... my ledger gives you a clean partition of all "events"
177 2013-01-14 05:09:48 <etotheipi_> and you can dig down into it if you want to...
178 2013-01-14 05:09:49 <kjj> this is why I always groan a bit when 2112 gets on his GASB soap box
179 2013-01-14 05:09:58 <etotheipi_> what is GASB?
180 2013-01-14 05:10:14 <kjj> Governmental Accounting Standards Board
181 2013-01-14 05:10:40 <kjj> he's always pissed that the stock client doesn't support standard accounting practices
182 2013-01-14 05:11:42 <etotheipi_> ahh
183 2013-01-14 05:12:04 <phantomcircuit> kjj, the gold medal of accounting is an append only journal
184 2013-01-14 05:12:17 <phantomcircuit> bitcoin is probably the closest people have ever gotten to that
185 2013-01-14 05:12:36 <kjj> yeah, if you need that, you can get it from the blockchain after 6 confirmations.
186 2013-01-14 05:12:50 <etotheipi_> fuck it... I'm doing this the way that makes the most sense to me (which would probably make 2112 happy)
187 2013-01-14 05:13:05 <etotheipi_> people can complain and/or help implement the other way if they really miss it
188 2013-01-14 05:13:59 <kjj> the satoshi client marks keys to denote change
189 2013-01-14 05:14:29 <etotheipi_> I can figure it out based on order of generation (in the instance of sent-to-self)
190 2013-01-14 05:14:32 <kjj> you don't even store keys, but you apparently retain similar state information
191 2013-01-14 05:15:19 <kjj> if you are deducing things, you'll have to revisit it if you ever allow unusual interaction
192 2013-01-14 05:15:26 <etotheipi_> unless you do something really creative,...
193 2013-01-14 05:15:41 <etotheipi_> but there's a point at which there is no correct answer anymore, once you go down that road
194 2013-01-14 05:15:57 <kjj> exactly
195 2013-01-14 05:16:58 <kjj> the way I see the relationship of bitcoin to accounting, is that bitcoin can prove that a transaction took place, provided that the accounting system already knows about it
196 2013-01-14 05:17:44 <kjj> as in, if you record a payment to someone, you can show evidence that it happened. but going in the other direction is very very hard
197 2013-01-14 05:19:35 <etotheipi_> https://bitcointalk.org/index.php?topic=80312.msg1452879#msg1452879
198 2013-01-14 05:20:37 <kjj> oh, if it wasn't the bet directly that was doubled, then it is far less interesting (but more clever)
199 2013-01-14 05:22:56 <etotheipi_> bedtime for me
200 2013-01-14 05:26:59 <andytoshi> devs, could you take a look at my letter to the libertarian party of canada?:
201 2013-01-14 05:27:00 <andytoshi> http://download.wpsoftware.net/libertarian-letter-bitcoin.txt
202 2013-01-14 06:12:31 <stealth222> I want to make some changes to some of the fields in the RPC but don't want to break any apps that rely on them. Is there a way we can get a census on how much they are actually being used>
203 2013-01-14 06:13:34 <stealth222> furthermore, even if they are still being used it would be possible to expose a backwards-compatibility mode to eventually be deprecated
204 2013-01-14 06:21:08 <jgarzik> stealth222: it's a judgement call. you can just create a new RPC and mark an old one as deprecated, if you want to radically change something
205 2013-01-14 06:21:44 <stealth222> but what about changing things like output format or field names?
206 2013-01-14 06:22:21 <stealth222> it seems excessive to create an entirely separate RPC call to change the format of a single field
207 2013-01-14 06:25:54 <stealth222> one specific example is the unlocked_until field
208 2013-01-14 06:26:18 <stealth222> unix timestamps are helpful for programmatic access - but they aren't particularly helpful to interactive users
209 2013-01-14 06:26:58 <stealth222> perhaps there should be both a unix timestamp and a formatted local time
210 2013-01-14 06:40:15 <jgarzik> stealth222: RPC isn't really for interactive users
211 2013-01-14 06:40:30 <stealth222> CLI uses the same format
212 2013-01-14 06:43:50 <jgarzik> that doesn't mean the CLI is meant to be a full blown client :)
213 2013-01-14 06:44:20 <jgarzik> to answer the question, you would probably either add a new pretty_date field or create a new RPC, rather than changing an existing field
214 2013-01-14 06:44:47 <jgarzik> but more generally, that gets into the realm of display preferences. seems more appropriate for a wrapper python script.
215 2013-01-14 07:21:36 <MC-Eeepc> when satoshi added tor support
216 2013-01-14 07:21:41 <MC-Eeepc> what does that actually mean
217 2013-01-14 07:21:58 <MC-Eeepc> audit for leaking identifying data and such?
218 2013-01-14 08:05:00 <stealth222> is the fact that the genesis block's coinbase is nonspendable part of the official bitcoin protocol? or is this just a fluke of the way the satoshi client is implemented?
219 2013-01-14 08:28:59 <petertodd> stealth222: the way the satoshi client is implemented isthe official bitcoin protocol
220 2013-01-14 08:30:52 <stealth222> petertodd: I am aware of that - which is why I was asking. It seems like a strange limitation
221 2013-01-14 08:31:15 <stealth222> I get that it would require to code for an entire separate case
222 2013-01-14 08:34:45 <petertodd> yeah, well, it's how it works and can't be changed
223 2013-01-14 08:35:13 <petertodd> possibly just an oversight by satoshi, the genesis block is handled specially after all, or he meant to do that for some reason
224 2013-01-14 08:36:51 <stealth222> it could be solved by keeping a pregenesis dummy block
225 2013-01-14 08:37:06 <stealth222> and not letting any other block connect to it
226 2013-01-14 08:37:19 <stealth222> except the genesis block
227 2013-01-14 08:37:41 <stealth222> but I guess it's satoshi's coins
228 2013-01-14 08:37:58 <stealth222> so nobody else really cares about that :)
229 2013-01-14 08:39:28 <stealth222> actually, come to think of it, the requirement that no other blocks be allowed to connect to it isn't even really an issue
230 2013-01-14 08:40:39 <stealth222> I guess at the time satoshi was writing it, 50 bitcoins didn't seem worth the price of coding up an exception
231 2013-01-14 08:41:56 <stealth222> the genesis block could have been defined as a blank header - with the exception that rather than using double sha, it just hashes to all zero
232 2013-01-14 08:43:14 <stealth222> you could still connect a block to it today - but then you'd be back at height 1
233 2013-01-14 08:44:32 <stealth222> actually, that exeption isn't even necessary
234 2013-01-14 08:44:53 <stealth222> whatever the hash of a blank header is - that could have been used as the prevBlock of the first block to contain a transaction
235 2013-01-14 08:45:09 <petertodd> ha, yeah, lots of ways to handle it, satoshi's approach is kinda nice because it gave an obvious place to put the times headline
236 2013-01-14 08:45:31 <petertodd> ultimately what's done is done
237 2013-01-14 08:46:31 <petertodd> rmember that the prevblock of the genesis block is set to zero's
238 2013-01-14 08:46:38 <stealth222> yes, I know
239 2013-01-14 08:46:45 <stealth222> so it already needs an exception
240 2013-01-14 08:46:57 <stealth222> the way I'm proposing (I know it's too late) there's no exception needed, really
241 2013-01-14 08:47:01 <petertodd> yup
242 2013-01-14 08:47:43 <petertodd> well, I just woke up myself, but yeah, I think you're right, so go start a scamcoin called "satoshi screwed up but I got this right"-coin
243 2013-01-14 08:47:47 <petertodd> :P
244 2013-01-14 08:47:53 <stealth222> haha
245 2013-01-14 08:48:21 <petertodd> the block reward should be a geometrically increasing function
246 2013-01-14 08:48:43 <stealth222> inflationary currency?
247 2013-01-14 08:49:01 <petertodd> yeah, Zimbabwe-coin
248 2013-01-14 08:49:05 <stealth222> lol
249 2013-01-14 08:49:25 <petertodd> but then, handle it in the UI by constantly re-denominating balances
250 2013-01-14 08:49:47 <petertodd> your logo could be $1,000,000,000,000 with the last 9 digits crossed out
251 2013-01-14 08:50:49 <petertodd> (shit, I gotta do this next April...)
252 2013-01-14 08:51:06 <stealth222> if satoshi would have just used the hash of a blank header for his prevBlockHash instead of all zeros :p
253 2013-01-14 08:51:39 <petertodd> heck, he could have just used the hash of his message...
254 2013-01-14 08:52:14 <stealth222> indeed :)
255 2013-01-14 08:52:24 <petertodd> btw, have you ever noticed that the genesis block has a significantly higher proof of work than difficulty 1?
256 2013-01-14 08:53:05 <petertodd> I'm suspicious that he waited for good headline, then spent the next week mining as hard a PoW as he could
257 2013-01-14 08:53:31 <stealth222> lol - doesn't look too much higher than the following blocks
258 2013-01-14 08:54:01 <stealth222> or wait...
259 2013-01-14 08:54:02 <stealth222> lol
260 2013-01-14 08:54:22 <stealth222> you're absolutely right
261 2013-01-14 08:54:31 <stealth222> by a couple orders of magnitude, in fact
262 2013-01-14 08:54:47 <petertodd> 2103 times the next block
263 2013-01-14 08:55:51 <petertodd> now, the timestamp of the next block is 771 blocks at 10min/block
264 2013-01-14 08:56:17 <petertodd> so possibly he had enough computer power to maintain the 10min/block interval, and got lucky
265 2013-01-14 08:56:35 <petertodd> by a factor of a bit under three
266 2013-01-14 08:58:35 <stealth222> he could have just been hashing away while he finished up coding up the thing :)
267 2013-01-14 08:58:59 <petertodd> hmm... yeah, actually that too, or finished testing it
268 2013-01-14 08:59:41 <petertodd> iirc back then an average computer would solve a block or two a day though, so he probably still had access to a lab, or for that matter, a bunch of ec2 computers
269 2013-01-14 09:00:05 <stealth222> I don't think he had a problem finding access to computing power
270 2013-01-14 09:00:23 <stealth222> I doubt he was using a laptop to hash it
271 2013-01-14 09:00:45 <petertodd> frankly we just don't know, honestly I doubt he was actually very computer savvy, in the "open source linux guru sense"
272 2013-01-14 09:01:13 <petertodd> it was released on windows first...
273 2013-01-14 09:01:31 <stealth222> hmmm
274 2013-01-14 09:02:05 <petertodd> probably an academic-ish cryptographer, or potentially a smart guy with an interest in crypto
275 2013-01-14 09:02:41 <stealth222> does anyone here actually know him? or are they not even allowed to talk about if if they do?
276 2013-01-14 09:02:42 <stealth222> lol
277 2013-01-14 09:03:27 <petertodd> I first heard about hashcash maybe 2002 or 2003, and I remember having a big discussion with my dad, an economist, about the interesting inflationary properties of it... I'm still kinda kicking myself for not coming up with Bitcoin :P
278 2013-01-14 09:03:33 <petertodd> I dunno, maybe gavin?
279 2013-01-14 09:04:00 <petertodd> maybe hal? maybe hal is satoshi?
280 2013-01-14 09:04:27 <stealth222> in any case, if I were to make an alt chain, this genesis block issue is not at the top of my priorities of things to fix :p
281 2013-01-14 09:04:45 <petertodd> deflation on the other hand... :P
282 2013-01-14 09:04:45 <stealth222> the "flip the chain" thing seems much more fundamental
283 2013-01-14 09:04:52 <petertodd> yes, that's a very good one
284 2013-01-14 09:06:10 <petertodd> that said, I actually do think it'd be good if the block reward bottomed out, if only because it would let you reason about miner rewards and how that influences their behavior
285 2013-01-14 09:07:23 <petertodd> flip the chain doesn't have to fully be a hardfork though
286 2013-01-14 09:07:58 <stealth222> etotheipi has a merged-mining proposal to construct a tree of unspent outputs
287 2013-01-14 09:08:20 <petertodd> exactly, it can be brought in gradually
288 2013-01-14 09:09:12 <petertodd> related: I have my own concept to make the blockchain better connected for timestamping, that would insert essentially hashes of merkle trees of every block into tx's used for merkle-style timestamping
289 2013-01-14 09:10:15 <stealth222> not sure I follow
290 2013-01-14 09:11:25 <petertodd> lets suppose you make a timestamp on block 100,000, and want to show the timestamp applies to the genesis tx in block 0, right now you need a "merkle path" with digests of every single block inbetween right?
291 2013-01-14 09:11:48 <stealth222> yes
292 2013-01-14 09:12:20 <petertodd> so take every block in the chain, make a merkle tree of the block hashes, and insert that top hash into a tx, a coinbase for instance, now you can use that tree to make a mcuh shorter proof, and the tree can be generated deterministically so you don't actually have to store the tree to use it later
293 2013-01-14 09:12:50 <stealth222> but the block tree has very short branches
294 2013-01-14 09:13:02 <petertodd> yes, but the block-to-block path doesn't
295 2013-01-14 09:13:35 <petertodd> and if you timestamp block header n, say with a non-bitcoin timestamping thing, you can't show block n-100 without 100 digests
296 2013-01-14 09:14:06 <stealth222> I see what you mean
297 2013-01-14 09:14:10 <stealth222> yeah, that's kinda neat
298 2013-01-14 09:14:14 <petertodd> also, it would let you show proofs of certain types of things to clients without those clients having full block header databases, just a few of the most recent block headers
299 2013-01-14 09:14:39 <petertodd> it's not a big deal, but I'm working on timestamping, so I might as well add in this feature in a standard way for everyone to use
300 2013-01-14 09:14:51 <stealth222> yeah, if you're not using it to generate coins and all you care about is relative time, you don't even need a genesis block
301 2013-01-14 09:15:20 <petertodd> yup, SPV clients could use it basically
302 2013-01-14 09:15:55 <petertodd> what's nice is a shitty implementation can be retrofitted now without even miner support
303 2013-01-14 09:16:38 <petertodd> the only cost is a few more steps in the path
304 2013-01-14 09:16:43 <sipa> stealth222: your question is really whether the nonspendability of the genesis is intentional or not... not whether it is part of the protocol (it obviously is)
305 2013-01-14 09:17:34 <sipa> stealth222: i don't know the answer, but in the way the client was coded at the time, it was certainly less code to make non spendable
306 2013-01-14 09:17:50 <stealth222> sipa: what about the idea of using a blank block as the genesis block?
307 2013-01-14 09:17:55 <stealth222> all zero header
308 2013-01-14 09:18:16 <stealth222> the first transaction appears on the next block
309 2013-01-14 09:18:46 <stealth222> doesn't seem like a lot more code - but at the same time it doesn't really matter :p
310 2013-01-14 09:18:57 <sipa> it could have been
311 2013-01-14 09:19:16 <sipa> the genesis block is introduced by the software and never actually checked
312 2013-01-14 09:19:27 <stealth222> right - so it still requires an exception
313 2013-01-14 09:19:40 <stealth222> if (IsGenesisBlock) accept
314 2013-01-14 09:19:53 <sipa> it's just esthetics to make it look like a real block!
315 2013-01-14 09:19:55 <sipa> no!
316 2013-01-14 09:20:13 <sipa> that's thr point, the genesis block is never "accepted"
317 2013-01-14 09:20:32 <sipa> it's just "if empty, add genesis block"
318 2013-01-14 09:21:03 <stealth222> the genesis block is just hardcoded
319 2013-01-14 09:21:12 <sipa> yes
320 2013-01-14 09:21:12 <stealth222> and given height 0
321 2013-01-14 09:21:43 <sipa> and it is at that point added to the block db (otherwise next blicks wouldn't find it)
322 2013-01-14 09:22:11 <sipa> but its coinbase is not added to the tx database (oversight, or just unneeded)
323 2013-01-14 09:22:20 <stealth222> but the protocol could have been that the all zero block is a valid block but has height 0
324 2013-01-14 09:22:35 <sipa> yes
325 2013-01-14 09:23:36 <sipa> but now it also functions to initialize difficulty and time
326 2013-01-14 09:23:44 <petertodd> hmm... you know, since the genesis block is a special case, not adding the coinbase means that you never have to test the special case of spending a transaction in the genesis block
327 2013-01-14 09:23:57 <petertodd> sipa: good point!
328 2013-01-14 09:24:37 <stealth222> yes....hmmm
329 2013-01-14 09:24:44 <sipa> petertodd and it allows the coins system i wrote to use height=0 as invalid :p
330 2013-01-14 09:24:55 <stealth222> lol
331 2013-01-14 09:25:20 <petertodd> ha, nice
332 2013-01-14 09:34:17 <petertodd> sipa: wait, so what exactly does your coins system do there? it just occured to me that potentially people are going to introduce a bug in their software related to "what block did we see address x in", because every tx sent to the genesis block after the coinbase can be spent
333 2013-01-14 09:35:14 <petertodd> I wonder if gavin saved the private key for the testnet genesis block... maybe testnet4 should use a well known private key for the genesis block tx, so everyone can test their code for spending it
334 2013-01-14 09:35:39 <stealth222> it wouldn't be too hard to just create a private testnet to test this
335 2013-01-14 09:36:45 <petertodd> for sure, I just want to make sure people will wind up testing this case against their will :P
336 2013-01-14 09:52:35 <sipa> petertodd: it's the utxo database used for verifying blocks/transactions in 0.8
337 2013-01-14 09:53:43 <petertodd> ah, so what, a tx isn't allowed to have been spent in block 0?
338 2013-01-14 09:54:13 <sipa> petertodd: a coin is an unspent transaction output
339 2013-01-14 09:54:34 <sipa> and its height is the height at which it was introduced in the currently active block chain
340 2013-01-14 09:54:38 <sipa> and this cannot be 0
341 2013-01-14 09:56:27 <petertodd> ah I see, yeah that's fine
342 2013-01-14 09:57:45 <sipa> this is used in the undo file format, which only encodes height/coinbaseness/version for the last output of a tx being spent
343 2013-01-14 09:58:03 <sipa> if the height field is zero, the other two aren't stored
344 2013-01-14 10:01:12 <petertodd> yup
345 2013-01-14 10:01:31 <petertodd> speaking of which, thank you for your new "spend tx" database, it's really useful
346 2013-01-14 10:01:46 <sipa> spend tx database?
347 2013-01-14 10:01:59 <petertodd> er, spent tx database, so getrawtx works on spent tx's
348 2013-01-14 10:02:10 <sipa> i hate it
349 2013-01-14 10:02:18 <petertodd> why?
350 2013-01-14 10:02:39 <sipa> because i hate services needing to depend on a history of all transactions ever
351 2013-01-14 10:02:59 <sipa> it's very useful for debugging, so i implemented it, though
352 2013-01-14 10:03:09 <sipa> but i fear it will be abused
353 2013-01-14 10:03:45 <petertodd> yeah, it's a good point, but it definitely does help debugging
354 2013-01-14 10:04:05 <petertodd> I've also got one minor use-case, which needs access to at least recently spent tx's for my timestamping project
355 2013-01-14 10:06:30 <stealth222> such a database is absolutely necessary somewhere - it probably shouldn't be part of a minimal verification/relay node...but adding it to the satoshi client will at least ensure the application has widespread distribution
356 2013-01-14 10:07:07 <stealth222> I had to build my own such database so as not to rely on sites like blockexplorer and blockchain.info
357 2013-01-14 10:07:39 <sipa> i've worked on a by-address database as well, which is probably even more useful, and also more prone to abuse
358 2013-01-14 10:07:48 <stealth222> abuse in what sense, sipa?
359 2013-01-14 10:08:02 <sipa> like people that would implement a wallet on top of it
360 2013-01-14 10:08:37 <stealth222> why is that a problem for us?
361 2013-01-14 10:08:51 <stealth222> you mean people will come to depend on it?
362 2013-01-14 10:08:57 <sipa> yes
363 2013-01-14 10:09:28 <stealth222> well, then perhaps there should be a disclaimer that these features are only for testing and not intended for production applications
364 2013-01-14 10:09:42 <stealth222> and could be discontinued at a later time
365 2013-01-14 10:10:25 <sipa> even a prerelaese build with a clear error being outputted "don't use for mining"... and p2pool has code to specifically ignore that warning
366 2013-01-14 10:11:09 <stealth222> the better solution is to release a serious opensource database application that is separate from bitcoind :)
367 2013-01-14 10:11:14 <petertodd> I've noticed that... p2pool really should only ignore with a non-default flag...
368 2013-01-14 10:12:14 <stealth222> tjere
369 2013-01-14 10:12:22 <sipa> stealth222: perhaps, but hiw will that prevent anyone from growing to depend on that
370 2013-01-14 10:12:22 <stealth222> there's certainly a need for such a database application, sipa
371 2013-01-14 10:12:30 <sipa> for some stuff it is unavoidable
372 2013-01-14 10:12:43 <stealth222> but I agree that it is a different application from the verification/relay engine
373 2013-01-14 10:12:58 <DJHenjin__> Hello Peoples
374 2013-01-14 10:13:08 <sipa> i don't care about whether it is part of that engine or not!
375 2013-01-14 10:13:14 <stealth222> the verification/relay engine should use structures optimized for doing just what is necessary to keep the network in operation
376 2013-01-14 10:13:17 <DJHenjin__> So I have a question regarding developing a web application for Bitcoin
377 2013-01-14 10:13:33 <sipa> if it has to exist, maybe it is better to be part of it, to at least guarantee consistency
378 2013-01-14 10:13:57 <sipa> but imho we should encourage people to build srrvices that do not depend on all history being easily available
379 2013-01-14 10:14:05 <stealth222> but the problem is that each application has very different needs and should probably be allowed to develop on a completely separate branch
380 2013-01-14 10:14:09 <DJHenjin__> When a user sends BTC to the site, into their 'recieve account' on the site, is there an easy way to verify the transaction has enough confirmations on the BTC network
381 2013-01-14 10:14:10 <sipa> and certainly not in an indexed form
382 2013-01-14 10:14:25 <stealth222> I'm not just talking about indices - I'm talking about a full SQL interface
383 2013-01-14 10:14:35 <stealth222> or perhaps a good subset
384 2013-01-14 10:15:10 <stealth222> but that clearly does NOT belong in the verification/relay node
385 2013-01-14 10:15:54 <stealth222> and releases of either product shouldn't depend on the state of the other
386 2013-01-14 10:15:58 <DJHenjin__> also another question, when using the RPC call move() to move from one account to another account on the same wallet, does a person still need to wait for confirmations? or will that transaction even be confirmed at all
387 2013-01-14 10:16:28 <sipa> DJHenjin__: move is purely a local operation, it subtrackts from one account, and adds to the other
388 2013-01-14 10:16:39 <sipa> DJHenjin__: there is no interaction with the network
389 2013-01-14 10:16:43 <stealth222> the move is 100% internal to the wallet, DJHenjin__ has nothign to do with the block chain
390 2013-01-14 10:16:44 <DJHenjin__> thank you sipa , and my other question?
391 2013-01-14 10:17:40 <sipa> doesn't getbalancr have a parameter to select the minimum confirmations?
392 2013-01-14 10:18:52 <DJHenjin__> ah, thanks sipa , did not see that before
393 2013-01-14 10:19:40 <DJHenjin__> so basically just getbalance('account',6) would check for a balance that has the requisite 6 confirmations
394 2013-01-14 10:20:20 <stealth222> yes
395 2013-01-14 10:20:43 <stealth222> and anything that has been confirmed more recently is not included
396 2013-01-14 10:21:02 <DJHenjin__> each confirmations taking ~ 10 minutes each, it takes about 1 hour to get 6 conf
397 2013-01-14 10:23:45 <DJHenjin__> Thank you sipa and stealth222
398 2013-01-14 10:26:10 <DJHenjin__> you two have helped me understand my issue much much better
399 2013-01-14 10:26:36 <stealth222> if you have any other questions, ask away :)
400 2013-01-14 10:26:54 <DJHenjin__> I intend to
401 2013-01-14 10:28:13 <DJHenjin__> ok, getaccountaddress() returns the same address every time, until there has been a transaction into that address, then returns a new address right?
402 2013-01-14 10:30:09 <DJHenjin__> my question is, is as follows, Is the old address returned by getaccountaddress() still usable to deposit into the same account
403 2013-01-14 10:30:17 <stealth222> yes
404 2013-01-14 10:30:27 <stealth222> the old addresses are never erased from the wallet
405 2013-01-14 10:30:53 <DJHenjin__> would it be bad practice to re-use an old recieve address?
406 2013-01-14 10:31:07 <stealth222> depends on what you're trying to accomplish :)
407 2013-01-14 10:31:38 <stealth222> reusing the same address again and again makes it easier to track transactions - but it also means wallet management is simpler
408 2013-01-14 10:31:39 <DJHenjin__> to confirm new transactions from the same user, such that they do not have to get a new recieve address from the site each time they send BTC
409 2013-01-14 10:32:22 <stealth222> depends on how concerned you are about privacy
410 2013-01-14 10:32:53 <DJHenjin__> if a person is even the slightest bit concerned about privacy it would be best to set a new recieve address per transaction
411 2013-01-14 10:34:26 <stealth222> to be quite honest, I wish the whole address thing were abstracted to a level where endusers only see contacts and balances
412 2013-01-14 10:34:41 <stealth222> it's moving in that direction but it's not quite there yet
413 2013-01-14 11:02:23 <DJHenjin__> So here is my dilemna stealth222 I want to make this as simplistic as possible, but still with a good amount of anonyminity
414 2013-01-14 11:03:21 <bitnumus> Hey, any UK developers here, skilled in PHP, SQL, JS and other web related languages , also familiar with working with bitcoin
415 2013-01-14 11:04:02 <DJHenjin__> bitnumus: skilled in PHP, SQL, and familiar enough with bitcoin, but not UK, canadian
416 2013-01-14 11:04:43 <DJHenjin__> what do you need?
417 2013-01-14 11:04:56 <stealth222> how much are you paying ?:)
418 2013-01-14 11:05:12 <stealth222> not a UK developer but for a really good price I might become one :p
419 2013-01-14 11:05:29 <DJHenjin__> same ;)
420 2013-01-14 11:05:55 <bitnumus> Well its quite a big project so would like someone local without the time difference issues
421 2013-01-14 11:06:10 <t7> im uk :3
422 2013-01-14 11:06:19 <DJHenjin__> Time difference is nothing to me, I adjust my schedule to accomodate my clients
423 2013-01-14 11:06:31 <bitnumus> t7 I have traded with you before I think :-)
424 2013-01-14 11:06:40 <t7> yeah hello shaun
425 2013-01-14 11:06:55 <bitnumus> Do I have you on gmail?
426 2013-01-14 11:07:04 <t7> yeah, what you building ?
427 2013-01-14 11:07:24 <bitnumus> Roy?
428 2013-01-14 11:07:27 <t7> Tom
429 2013-01-14 11:08:00 <bitnumus> Gotcha
430 2013-01-14 11:08:07 <stealth222> DJHenjin__: first understand that being truly "anonymous" on bitcoin requires a considerable amount of effort - and any determined foe will most likely be able to defeat even fairly sophisticated methods. Having said that, by using a new receiving address each time at least you make it a tiny bit harder for people to pull up your accounting records on blockchain.info
431 2013-01-14 11:27:30 <JayChristopher> Can you create unlimited accounts in a wallet? For instance, if I wanted to have a million accounts, would there be any problem with that?
432 2013-01-14 11:28:32 <kjj> if you think you need a million accounts, you are doing something horribly wrong. but there is no fixed limit on accounts, it just depends what your computer is capable of handling
433 2013-01-14 11:29:03 <JayChristopher> I don't now, but just trying to figure out the best way to set up a web wallet
434 2013-01-14 11:29:12 <JayChristopher> for scalability
435 2013-01-14 11:29:16 <kjj> ignore accounts, keep track internally
436 2013-01-14 11:29:39 <JayChristopher> Yeah okay i thought that might be so, i was just reading https://en.bitcoin.it/wiki/Accounts_explained and it seemed like it was built to be used that way
437 2013-01-14 11:30:55 <JayChristopher> I was thinking moreso than anything that it would be a good way to double check balance against the database for added security measure
438 2013-01-14 11:35:25 <DJHenjin__> JayChristopher: bit of an elementary idea, but, what about totaling all users balances in the DB, and testing the balance in the server, if there is a problem, it will be evident
439 2013-01-14 11:36:00 <JayChristopher> yeah i was planning to do that as well, nothing crazy just exploring options
440 2013-01-14 12:35:31 <Acciaio> hi all how can I calculate the exact fee of a transaction that I will send with bitcoind->sendmany before sending a transaction?
441 2013-01-14 13:05:44 <Luke-Jr> Acciaio: you can't.
442 2013-01-14 13:06:35 <Luke-Jr> Acciaio: that's at least partially intentional, since there is almost no legitimate need for it (if any at all)
443 2013-01-14 13:08:28 <Acciaio> Luke-Jr, yes there is in micropayments world fee can be greater than transaction
444 2013-01-14 13:09:47 <Luke-Jr> Acciaio: Bitcoin transactions aren't for micropayments.
445 2013-01-14 13:12:39 <Acciaio> should be!
446 2013-01-14 13:14:18 <epscy> Acciaio: if you are clever enough you can work it out
447 2013-01-14 13:14:28 <Luke-Jr> Acciaio: it's possible to extend it to do micropayments outside of the existing bitcoin network, but nobody has this as a focus right now AFAIK
448 2013-01-14 13:25:05 <stealth222> there could well be legitimate uses for it
449 2013-01-14 13:25:22 <Luke-Jr> stealth222: ?
450 2013-01-14 13:25:31 <stealth222> there have been a number of times where my balance showed x yet I couldn't send x because a fee was required
451 2013-01-14 13:25:57 <stealth222> sure, I'd get the error message AFTER calling send
452 2013-01-14 13:26:11 <stealth222> but what if I'm sending several transactions that must all go through - and I only have x
453 2013-01-14 13:26:16 <Luke-Jr> ???
454 2013-01-14 13:26:22 <Luke-Jr> then you're bankrupt? :P
455 2013-01-14 13:26:25 <stealth222> I won't know until the last transaction that I have insuffiient funds
456 2013-01-14 13:26:34 <Luke-Jr> you should sendmany ;)
457 2013-01-14 13:27:23 <stealth222> yeah, ok - I guess this was more an issue back when sendmany didn't exist
458 2013-01-14 13:31:14 <stealth222> I still could name some perhaps contrived sounding reasons why I would still want to send each one individually...but you're right...most users don't need it
459 2013-01-14 13:31:35 <epscy> stealth222: it would be pretty trivial to write as a third party program
460 2013-01-14 13:31:48 <stealth222> that's what I did to get around it
461 2013-01-14 13:31:52 <stealth222> lol
462 2013-01-14 13:31:57 <epscy> i wouldn't be surprised if there is something on github that already does it
463 2013-01-14 13:32:23 <epscy> and of course you can use the raw transaction stuff to bypass the fee rules
464 2013-01-14 13:32:43 <epscy> though you run the risk of never having your tx confirmed
465 2013-01-14 13:32:48 <stealth222> yes, when I did this there was no rawtransaction stuff - not even sendmany
466 2013-01-14 13:34:25 <stealth222> most of my reasons involved tinkering and experimenting with the bitcoin protocol
467 2013-01-14 13:34:56 <stealth222> and most of the amounts involved were small
468 2013-01-14 13:34:58 <stealth222> so I didn't particularly care
469 2013-01-14 13:35:13 <stealth222> about unconfirmed tx
470 2013-01-14 13:38:20 <stealth222> hell, I even gave away a few bitcoins to miners just to play around with the fee stuff :p
471 2013-01-14 13:39:27 <SomeoneWeird> lmao
472 2013-01-14 13:39:31 <SomeoneWeird> can i have some >.>
473 2013-01-14 13:39:42 <epscy> heh
474 2013-01-14 13:39:47 <epscy> i wouldn't say no either
475 2013-01-14 14:17:16 <TD> petertodd: does my explanation make sense?
476 2013-01-14 14:17:51 <petertodd> which explanation?
477 2013-01-14 14:17:59 <TD> the one i just sent you via email. about micropayments.
478 2013-01-14 14:18:27 <petertodd> oh, sorry, I haven't read it yet
479 2013-01-14 14:19:10 <TD> ok. if i found an explanation that works, i'll post it to the security ml thread too. and maybe write up a wiki page on the mechanism. because the same questions and concerns come up pretty frequently. like, incentives, etc.
480 2013-01-14 14:33:03 <petertodd> cool, btw I'm not on the security list TD
481 2013-01-14 14:33:53 <TD> right. i didn't realize that. we'll keep you CCd on that thread from now on
482 2013-01-14 14:34:58 <petertodd> TD: thanks
483 2013-01-14 14:35:21 <petertodd> TD: anyway, I gotta go to work, I'll be around on email, but I'm off irc until the evening
484 2013-01-14 14:35:28 <TD> have a good day
485 2013-01-14 14:49:35 <eckey> hello
486 2013-01-14 15:18:30 <stealth222> Any of the bitcoin-qt people around?
487 2013-01-14 15:18:43 <Diapolo> a little ^^
488 2013-01-14 15:18:49 <stealth222> hello, Diapolo :)
489 2013-01-14 15:19:03 <Diapolo> and WE are only 2 anyway :D stealth222: hi :)
490 2013-01-14 15:19:23 <stealth222> <insert timezone-appropriate salutation here>
491 2013-01-14 15:19:34 <stealth222> anyhow...
492 2013-01-14 15:19:48 <stealth222> so I'm looking to integrate the multiwallet stuff with qt - and there are a few possibilities
493 2013-01-14 15:19:53 <stealth222> one possibility is something like a tabbed view
494 2013-01-14 15:20:34 <stealth222> I'm wondering, though, how separate the different wallets should be in the GUI - like, should it be possible to merge transactions from multiple wallets into one view
495 2013-01-14 15:20:38 <Diapolo> this will get rather confusing when you have many wallets I guess
496 2013-01-14 15:20:57 <stealth222> the simplest approach of all is to just allow the user to load one wallet at a time
497 2013-01-14 15:20:59 <stealth222> but that's sort of lame :p
498 2013-01-14 15:21:02 <sipa> i think the most important question is how you think they will be used
499 2013-01-14 15:21:03 <Diapolo> perhaps a dropdown list on overviewpage and somewhere a global statistic
500 2013-01-14 15:21:04 <etotheipi_> stealth, you could look at how Armory does it
501 2013-01-14 15:21:11 <etotheipi_> there's a filter
502 2013-01-14 15:21:22 <sipa> if you consider them to be a sort of accounts, you probably want them in the same window, and easy interactions between them
503 2013-01-14 15:21:49 <sipa> if you consider them very separate (like professional and private), you probably want them in separate windows at at least
504 2013-01-14 15:22:05 <stealth222> or separate tabs?
505 2013-01-14 15:22:30 <Diapolo> my first thought was list only 1 (like currently) but make all selectable on the fly
506 2013-01-14 15:22:55 <gribble> The operation succeeded.
507 2013-01-14 15:22:55 <sipa> ;;later tell wumpus you probablty should talk to stealth222 about multi-wallet stuff in the GUI
508 2013-01-14 15:22:57 <stealth222> one at a time is by far the easiest integration - but...I sorta hate having to load and unload
509 2013-01-14 15:23:20 <etotheipi_> stealth222: have you used Armory with multiple wallets before/
510 2013-01-14 15:23:21 <etotheipi_> ?
511 2013-01-14 15:23:24 <stealth222> I'd like it to preserve each wallet's view state when you switch back and forth
512 2013-01-14 15:23:25 <Diapolo> this could also be a question of resource usage or?
513 2013-01-14 15:23:38 <stealth222> no, I haven't etotheipi
514 2013-01-14 15:23:49 <etotheipi_> it's got multiple wallets, full and watch-only
515 2013-01-14 15:24:01 <etotheipi_> no loading unloading
516 2013-01-14 15:24:07 <etotheipi_> you could look there for inspiration
517 2013-01-14 15:24:17 <stealth222> ok, I will :)
518 2013-01-14 15:24:20 <etotheipi_> I always wondered if there was a better way to do it...
519 2013-01-14 15:24:25 <etotheipi_> but so far no one has complained
520 2013-01-14 15:24:32 <stealth222> I've been meaning to check it out but have only gotten into GUI stuff now, etotheipi :p
521 2013-01-14 15:24:43 <etotheipi_> screenshot here: http://bitcoinarmory.com/
522 2013-01-14 15:24:58 <etotheipi_> you can see the "filter" on the bottom-left
523 2013-01-14 15:25:09 <stealth222> I see
524 2013-01-14 15:25:10 <etotheipi_> you can choose to have the Transactions tab only show your own wallets, watch-only, offline,
525 2013-01-14 15:25:18 <Diapolo> a scrollable list on overviewpage would look nice yeah
526 2013-01-14 15:25:19 <etotheipi_> but the top table always shows all wallets
527 2013-01-14 15:26:10 <etotheipi_> the thing that is most annoying is that I never knew what to do with the filter
528 2013-01-14 15:26:26 <etotheipi_> if I save the state of it between loads, then people will select 1 wallet and forget it's selected
529 2013-01-14 15:26:35 <etotheipi_> and then email me asking where all their transactions are
530 2013-01-14 15:26:40 <etotheipi_> (it's happened before)
531 2013-01-14 15:26:40 <stealth222> heh
532 2013-01-14 15:27:23 <etotheipi_> also
533 2013-01-14 15:27:32 <etotheipi_> I make sure to select "my wallets" for the default filter state
534 2013-01-14 15:27:53 <etotheipi_> that way "watching-only wallets" (that aren't marked as belonging to you) do now show up in the balance on the bottom right
535 2013-01-14 15:28:28 <stealth222> how have you been using the watch-only wallets typically? what's the use model?
536 2013-01-14 15:28:39 <etotheipi_> and watching-only wallets are always imported as not belong to you (there's an option in the wallet properties)
537 2013-01-14 15:28:58 <etotheipi_> stealth222: I assume you know what I mean by offline wallets
538 2013-01-14 15:29:04 <stealth222> yes
539 2013-01-14 15:29:10 <etotheipi_> (that is watching-only, just marked as "belongs to me")
540 2013-01-14 15:29:25 <stealth222> right, that's the use case I had in mind
541 2013-01-14 15:29:35 <stealth222> but you're also talking about watching-only that do not belong to you
542 2013-01-14 15:29:36 <etotheipi_> the reason for this was so that if someone convinces you (as a dumb user) to import a watch-only wallet
543 2013-01-14 15:29:39 <stealth222> so when would you use those?
544 2013-01-14 15:29:50 <etotheipi_> then you have to explicitly click a box that says "this wallet is mine!"
545 2013-01-14 15:29:53 <etotheipi_> which the user may find suspicious
546 2013-01-14 15:30:05 <etotheipi_> and if they don't do that, none of the tx to that wallet are displayed on the ledger or balance
547 2013-01-14 15:30:08 <etotheipi_> (unless you change the filter)
548 2013-01-14 15:30:27 <etotheipi_> stealth222: you would use them if you are collecting money for an organization
549 2013-01-14 15:30:47 <etotheipi_> or out in the field and collecting for yourself
550 2013-01-14 15:30:50 <etotheipi_> and don't want the full wallet
551 2013-01-14 15:31:07 <etotheipi_> think about if you work for a charity and someone contacts you and wants to make a donation
552 2013-01-14 15:31:25 <etotheipi_> you don't even have to tlak to the charity... open up your own instance of Armory with their watch-only wallet, and generate a new address for the donor
553 2013-01-14 15:31:49 <stealth222> are you using deterministic wallets or stored random keys?
554 2013-01-14 15:31:55 <etotheipi_> deterministic, type-2
555 2013-01-14 15:32:20 <etotheipi_> so you create the wallet offline, and transfer the watching-only wallet once
556 2013-01-14 15:32:28 <stealth222> I see - makes sense
557 2013-01-14 15:32:53 <etotheipi_> stealth222: you really should try the cold storage interface
558 2013-01-14 15:32:58 <etotheipi_> you don't even have to use two different computers
559 2013-01-14 15:33:22 <etotheipi_> just use one full wallet, and instead of sending, click "Create unsigned transaction"
560 2013-01-14 15:33:31 <etotheipi_> and then follow the process for offline signing
561 2013-01-14 15:34:30 <stealth222> what OS is the one you use most with it?
562 2013-01-14 15:34:41 <etotheipi_> Ubuntu
563 2013-01-14 15:34:48 <etotheipi_> but it's pretty easy on any linux
564 2013-01-14 15:34:53 <etotheipi_> the dependencies are versionless
565 2013-01-14 15:35:08 <stealth222> ok, so I'll set up a ubuntu box for it
566 2013-01-14 15:35:15 <etotheipi_> Windows works too
567 2013-01-14 15:35:39 <sipa> stealth222: what OS are you on?
568 2013-01-14 15:35:46 <stealth222> several :)
569 2013-01-14 15:36:01 <etotheipi_> stealth, if you use two computers, they can be any mix
570 2013-01-14 15:36:06 <stealth222> my main desktop runs OS X with several virtual machines inside
571 2013-01-14 15:36:09 <etotheipi_> the data moving between online and offline is OS-independent
572 2013-01-14 15:36:46 <stealth222> I develop mostly on ubuntu
573 2013-01-14 15:37:12 <stealth222> or at least test mostly on ubuntu
574 2013-01-14 15:37:45 <etotheipi_> stealth222: if you use Ubuntu or debian, you can just download the .deb package http://bitcoinarmory.com/index.php/get-armory
575 2013-01-14 15:38:46 <stealth222> I also have a windows VM that I use for testing - but I only use it once I've already built all the core in linux
576 2013-01-14 15:39:20 <etotheipi_> stealth222: there's a reason I just upgraded to 32 GB of RAM... it was so that I can run 5 VMs at once (linux 64, 32, windows 64,32 and OSX)
577 2013-01-14 15:39:23 <etotheipi_> :)
578 2013-01-14 15:39:32 <stealth222> yeah, it's nice having a lot of RAM :)
579 2013-01-14 15:40:04 <stealth222> now you just need to run an android simulator and an iOS simulator :)
580 2013-01-14 15:40:24 <sipa> stealth222: if you're able to easily test on several platforms, i have something for you to test
581 2013-01-14 15:40:58 <stealth222> uh oh... :p
582 2013-01-14 15:41:00 <sipa> stealth222: i've been looking at ECDSA verification speed closely when working on parallel sigcheck and hal's optimization
583 2013-01-14 15:41:22 <sipa> and with a gitian linux build of 32-bit and 64-bit of the same code, on the same machine
584 2013-01-14 15:41:27 <sipa> there's a factor 5 difference
585 2013-01-14 15:41:49 <etotheipi_> sipa: how many sig checks does Bitcoin-Qt do per sec?
586 2013-01-14 15:42:11 <stealth222> you mean just looping through openssl commands in a script?
587 2013-01-14 15:42:46 <sipa> stealth222: 2.5ms/txin single-threaded on 32-bit, 0.44ms/txin single-threaded on 64-bit
588 2013-01-14 15:42:46 <stealth222> to test verification speed?
589 2013-01-14 15:42:55 <sipa> stealth222: there's -benchmark for that :)
590 2013-01-14 15:43:07 <sipa> etotheipi_: ^
591 2013-01-14 15:43:46 <sipa> etotheipi_: that's on a i7 laptop at 2.2GHz, with hal's patch applied
592 2013-01-14 15:44:56 <stealth222> 5x is pretty significant
593 2013-01-14 15:45:38 <sipa> now, openssl has cpu-specific assembly for certain operations
594 2013-01-14 15:46:33 <sipa> in particular, EC field multiplication for prime-numbered fields uses that
595 2013-01-14 15:46:48 <sipa> which is probably our largest source of CPU usage
596 2013-01-14 15:48:48 <sipa> so a difference in those could explain a lot
597 2013-01-14 15:48:56 <sipa> but i did not expect a 5x difference
598 2013-01-14 15:49:35 <sipa> so if this is actually the case (and not because of a build problem that causes non-assembly versions to be used, for example), it explains why windows users typically report such slow sync speeds
599 2013-01-14 15:50:10 <stealth222> wouldn't it be possible to check that in a hex editor?
600 2013-01-14 15:50:32 <sipa> maybe
601 2013-01-14 15:51:04 <sipa> but the test i did was with a dynamically linked openssl in any case, so it would mean there's a problem in the provided openssl on ubuntu 12.04
602 2013-01-14 15:51:14 <stealth222> sure
603 2013-01-14 15:51:17 <sipa> (building was on 10.4, but executing was on 12.4)
604 2013-01-14 15:52:27 <sipa> anyway, some testing of a similar 32 vs 64 test in other contexts would be very useful
605 2013-01-14 15:55:48 <gavinandresen> sipa: I can test 32- versus 64- on my Mac fairly easily. What is the right -benchmark?
606 2013-01-14 15:57:12 <sipa> gavinandresen: -par=1 -benchmark -reindex, wait until after block 210000
607 2013-01-14 15:57:38 <gavinandresen> results reported in debug.log ?
608 2013-01-14 15:57:40 <sipa> gavinandresen: well, or don't use hal/parallel at all
609 2013-01-14 15:57:45 <sipa> yes, in debug.log
610 2013-01-14 15:58:00 <gavinandresen> ok.
611 2013-01-14 15:58:43 <sipa> it needs to be -reindex to avoid seeing the effect sigcaching
612 2013-01-14 15:58:47 <sipa> *of
613 2013-01-14 15:59:00 <stealth222> I don't have any 32-bit machines currently set up for testing, sipa
614 2013-01-14 15:59:24 <stealth222> but I could set them up - however, I can't do that right now :p
615 2013-01-14 16:00:02 <sipa> stealth222: not 32-bit machines - just 32-bit binaries
616 2013-01-14 16:00:09 <stealth222> oh...
617 2013-01-14 16:00:12 <gavinandresen> sipa: I could test on -testnet, right? ECDSA speed should be same test net or not....
618 2013-01-14 16:00:13 <sipa> you want it to be the same machine to test on
619 2013-01-14 16:00:38 <sipa> gavinandresen: i suppose, but testnet has weird stuff in some blocks that might disturb the measurements
620 2013-01-14 16:00:45 <sipa> gavinandresen: if you compare the same block on both, no problem
621 2013-01-14 16:02:47 <sipa> gavinandresen: but the numbers reported by -benchmark are fuzzy, so i just looked at which kind of number appeared frequently
622 2013-01-14 16:04:27 <gavinandresen> sipa: ok. I'll be sure to compare the same blocks, and will just get an order-of-magnitude estimate.
623 2013-01-14 16:05:14 <gavinandresen> How painful would it be to stop distributing 32-bit binaries?
624 2013-01-14 16:06:30 <sipa> gavinandresen: for windows? horrible
625 2013-01-14 16:07:05 <gavinandresen> sipa: for windows, mac, and linux???. if it is horribly slow, maybe we should tell people "don't do that"
626 2013-01-14 16:08:29 <BlueMatt> gmaxwell/sipa/TD: ack trolling for #1795 (Bloom) except for the MatchesTemplate commits
627 2013-01-14 16:09:18 <TD> BlueMatt: you can get an ACK from me once andreas finishes testing (and nflags is implemented on the java branch)
628 2013-01-14 16:10:45 <sipa> gavinandresen: so far, i don't think anyone ever built a 64-bit windows bitcoin
629 2013-01-14 16:11:03 <sipa> so if this is really a problem, we should look into w64 builds i guess
630 2013-01-14 16:11:04 <stealth222> lol - are you serious, sipa?
631 2013-01-14 16:11:54 <sipa> well we don't have a gitian setup for those, as that wasn't possible using the 10.04 envs we used until now
632 2013-01-14 16:11:56 <gavinandresen> sipa: on the Mac side of things, dropping support for OSX 10.5 and 32-bit Macs would make my life better.
633 2013-01-14 16:12:11 <stealth222> ack that, gavin :)
634 2013-01-14 16:12:57 <sipa> how old is 10.5?
635 2013-01-14 16:13:46 <gavinandresen> released October 2007
636 2013-01-14 16:14:34 <sipa> i suppose the ultimate test would be doing a w64 build (which may be painful, as it means getting all dependencies right and stuff, though at first we can forgot binary repeatability), and see how it performs compared to an otherwise identical 32 build, on the same 64-bit OS
637 2013-01-14 16:14:50 <sipa> but it may of course be that i screwed and we're worrying about nothing :)
638 2013-01-14 16:15:38 <jgarzik> IMO Windows definitely needs a 32-bit build for a while yet
639 2013-01-14 16:16:05 <stealth222> but there should be a 64-bit build
640 2013-01-14 16:16:12 <sipa> oh let's just ship with an x86_64 emulator, shall we?
641 2013-01-14 16:16:15 <sipa> :p
642 2013-01-14 16:16:22 <stealth222> lol
643 2013-01-14 16:16:40 <TD> nanotube: hey, was it you who pinged me about the android wifi bug?
644 2013-01-14 16:16:46 <jgarzik> w64 build would be nice, yet
645 2013-01-14 16:16:50 <jgarzik> *yes
646 2013-01-14 16:17:06 <jgarzik> ACTION tries to recall what Firefox did recently
647 2013-01-14 16:17:33 <sipa> jgarzik: only non-official w64 builds, afaik
648 2013-01-14 16:17:48 <BlueMatt> jgarzik: announced it was giving up on 64-bit, then retracted that and continued shipping alphas that many devs dont care about
649 2013-01-14 16:18:04 <jgarzik> that's it
650 2013-01-14 16:25:25 <nanotube> TD: nope, not me.
651 2013-01-14 16:25:38 <TD> darn
652 2013-01-14 16:25:40 <TD> i wonder who did it then
653 2013-01-14 16:25:42 <TD> ok never mind
654 2013-01-14 17:08:21 <jgarzik> gavinandresen: RE code-signing... I hope that B.F. has internally discussed how code-signing apps might induce some amount of legal targeted / potential liability in the eyes of some lawyers?
655 2013-01-14 17:08:32 <jgarzik> *targetting
656 2013-01-14 17:08:37 <jgarzik> *targeting
657 2013-01-14 17:09:15 <jgarzik> If I were doing code-signing, at a minimum, I would add a click-through license disclaimer in the installer.
658 2013-01-14 17:09:47 <gavinandresen> jgarzik: nope, hasn't been discussed at all.
659 2013-01-14 17:10:31 <gavinandresen> jgarzik: and there is no installer on the mac, it is open up .dmg file, drag to Applications. Done.
660 2013-01-14 17:11:45 <BlueMatt> gavinandresen: well, throw a by opening you agree to ToS in the background image of the dmg
661 2013-01-14 17:12:16 <jgarzik> Call me paranoid, but I would add a click-through in the app :)
662 2013-01-14 17:12:48 <gavinandresen> jgarzik: you're paranoid
663 2013-01-14 17:12:56 <Cusipzzz> you're paranoid :)
664 2013-01-14 17:13:19 <BlueMatt> he may very well not be, sadly
665 2013-01-14 17:13:33 <jgarzik> gavinandresen: anyway, IMO it is definitely worth thinking about. Red Hat and other open source companies obsessively make sure you click through the warranty disclaimers (as well as GPL)
666 2013-01-14 17:13:59 <gavinandresen> let me guess??? and they get sued anyway?
667 2013-01-14 17:14:19 <jgarzik> everybody gets sued. but not for the reasons clicked-through, at least :)
668 2013-01-14 17:14:43 <jgarzik> BF code-signing is far better than one of us devs doing it, at any rate
669 2013-01-14 17:15:18 <jgarzik> code-signing definitely brings about an element of contractual obligations, though they tend to be quite minimal at the base level
670 2013-01-14 17:15:30 <BlueMatt> has anyone written that stuff that supposedly strips out the constant space reserved in .exes for code signing?
671 2013-01-14 17:18:50 <gavinandresen> BlueMatt: why do you ask? You thinking of gitian process?
672 2013-01-14 17:20:23 <gavinandresen> BlueMatt: Next on my TODO is figuring out the windows code-signing stuff. I believe just the setup.exe will be signed, and I assumed we'd live with the setup.exe that is distributed not being titian-comparable (but it would be nice to teach gitian to zero the signature to compare....)
673 2013-01-14 17:20:42 <BlueMatt> i just prefer to not throw up yet more hurdles in getting auto-update merged, though I know no one has any real motivation to do that anyway
674 2013-01-14 17:23:19 <BlueMatt> gavinandresen: yes, setup.exe isnt gonna be gitian verified to begin with...
675 2013-01-14 17:24:20 <gavinandresen> great, then we're done. (auto-update updates the bitcoin-qt.exe ? )
676 2013-01-14 17:24:26 <BlueMatt> yes
677 2013-01-14 17:32:45 <phantomcircuit> gavinandresen, liability waiver in bold text plus indemnification
678 2013-01-14 17:33:05 <phantomcircuit> of course someone will sue anyways but they wont have a leg to stand on
679 2013-01-14 17:36:05 <gavinandresen> About Bitcoin already CLEARLY states "Distributed under the MIT/X11 software license." If y'all are concerned, then please start a conversation with Patrick Murck, but leave me out of it, I have too many other things on my TODO list
680 2013-01-14 17:36:42 <phantomcircuit> gavinandresen, the issue isn't so much the license it's distributed under
681 2013-01-14 17:37:00 <gavinandresen> ACTION puts his fingers in his ears and goes lalalalalalalalala
682 2013-01-14 17:37:02 <phantomcircuit> it's more like there is some fatal bug nobody has found yet and someone flips out when it gets triggered and sues all the devs
683 2013-01-14 17:37:05 <jgarzik> legally they try to get the user to agree to the license, an affirmative step on the part of the user
684 2013-01-14 17:37:07 <jgarzik> hehe
685 2013-01-14 17:37:19 <phantomcircuit> there is certainly a non-zero chance of that happening
686 2013-01-14 17:38:32 <BlueMatt> jgarzik: thanks for the reminder, Ill throw in a spend genesis block test in pull-tester later
687 2013-01-14 17:39:04 <BlueMatt> that is, after all, one of the few things I missed on bitcoinj full verification that sipa caught immediately
688 2013-01-14 17:45:15 <grau_> BlueMatt: how does bitcoind get the chain of the pull tester ?
689 2013-01-14 17:46:27 <BlueMatt> it gets sent over p2p
690 2013-01-14 17:46:37 <BlueMatt> testnet in a box-style
691 2013-01-14 17:46:45 <grau_> I do not see that from the script
692 2013-01-14 17:46:59 <grau_> i thought it reads in a file
693 2013-01-14 17:47:19 <BlueMatt> it does not
694 2013-01-14 17:47:31 <grau_> Where is the main that would drive that process?
695 2013-01-14 17:48:18 <BlueMatt> for now its a program
696 2013-01-14 17:48:18 <BlueMatt> it should in the future
697 2013-01-14 17:48:25 <BlueMatt> https://code.google.com/r/bluemattme-bitcoinj/source/detail?r=8d318e905036be89d34cb543b347edde53f2cf40&name=newscripts
698 2013-01-14 17:49:47 <grau_> That program verifies, but I am looking for the one that feeds into bitcoind
699 2013-01-14 17:57:40 <grau_> BlueMatt: I see there is a class in bitcoinj generating the chain, then there is your class (as re-sent before) doing the comparison after downloading from bitcoind. Still missing the piece how the chain gets into bitcoind.
700 2013-01-14 17:58:24 <BlueMatt> bitcoind.sendMessage(block.block);
701 2013-01-14 18:00:04 <grau_> That must be in some other code.
702 2013-01-14 18:00:36 <BlueMatt> lin 169
703 2013-01-14 18:00:37 <BlueMatt> e
704 2013-01-14 18:01:08 <grau_> Thanks I was blind.
705 2013-01-14 18:01:17 <BlueMatt> cntrl-f is your friend ;)
706 2013-01-14 18:11:20 <grau> BlueMatt: Your tests assume that blocks that e.g. double spend still connect. This is IMHO not part of the protocol just how it works with bitcoinj or bitcoind the tests should not assume that behaviour
707 2013-01-14 18:12:08 <grau> BlueMatt: it also assumes that if blocks arrive out of order they resemble, I think this is also not a protocol requirement
708 2013-01-14 18:13:20 <gavinandresen> out-of-order blocks is certainly a protocol requiremnt
709 2013-01-14 18:13:20 <gavinandresen> t
710 2013-01-14 18:13:37 <grau> Why ?
711 2013-01-14 18:14:04 <gavinandresen> because the mesh network does not guarantee that you'll get all messages
712 2013-01-14 18:15:04 <grau> I mean the scenario that I get a block before its previous, am I in your opinion obliged to cache it and wait for the predecessor. I think not
713 2013-01-14 18:15:20 <grau> This imposes cache on lightweight clients and opens DoS
714 2013-01-14 18:15:41 <gmaxwell> Yes. you are ??? or rather, obligated to go get it.
715 2013-01-14 18:15:53 <gmaxwell> otherwise you may reject the true longest chain.
716 2013-01-14 18:16:20 <grau> There is no guarentee I will get i. It might not even exist just because a block says it has a previous that does not mean it exists
717 2013-01-14 18:16:20 <sipa> gmaxwell: i don't think there is a problem with grau's approach
718 2013-01-14 18:16:38 <sipa> it's just less lazy, and therefor maybe more prone to a dos attack
719 2013-01-14 18:16:54 <sipa> but i don't think there is a problem with validating a chain before it becomes the best chain
720 2013-01-14 18:17:42 <grau> The result is the same, but the test behaviour differs.
721 2013-01-14 18:17:43 <gmaxwell> sipa: not talking about validating it???
722 2013-01-14 18:17:55 <gmaxwell> talking about not even attempting because of what order you got handed blocks in.
723 2013-01-14 18:18:30 <grau> gmaxwell: I am talking about several issues that expose different behaviour under test but in my opinion not protocol requirements
724 2013-01-14 18:18:33 <gavinandresen> yes, if longest chain is A->B->C, and you didn't happen to see the broadcast of "A", then when you see B you need to ask for A.
725 2013-01-14 18:18:35 <gmaxwell> E.g. you connct to the network. You get told of block X and you don't have block X-1. You must go try to connect X (by attempting to fetch X-1) or you may never converge.
726 2013-01-14 18:19:16 <gmaxwell> grau: I'm somewhat skeptcial that bluematt's tester can actually be exposing non-mandatory behavior here, but I'm not actually sure what the behavior is that you're talking about.
727 2013-01-14 18:19:28 <gavinandresen> grau is correct, you might not get A. But when you see C, you need to ask for A AGAIN??? etc...
728 2013-01-14 18:20:41 <gmaxwell> grau: what is actually the behavior you're seeing it test that isn't required?
729 2013-01-14 18:21:34 <grau> A minute I reconstruct precisely...
730 2013-01-14 18:21:43 <gmaxwell> Take your time.
731 2013-01-14 18:22:43 <gmaxwell> If there is some non-normative behavior with blocks visible on the p2p port from bitcoind then we might want to remove it to avoid something from depending on it.
732 2013-01-14 18:23:30 <sipa> gmaxwell: from what i understand about what grau told me yesterday, he validates (as in: Connect Block like checks, signatures, prevouts available, ...) blocks that are in a side chain at the moment they are received
733 2013-01-14 18:23:42 <sipa> grau: is this what you're talking about now, or something else?
734 2013-01-14 18:24:01 <grau> The simpler difference is: if a block contains double spend but connects such that it does not immediatelly get to longest chain, then bitcoind/j store it and return if queried, while bitsofproof rejects it immediatelly.
735 2013-01-14 18:24:28 <sipa> right, so what i said
736 2013-01-14 18:24:35 <sipa> i consider that dangerous and unnecessary, but not _wrong_
737 2013-01-14 18:25:01 <grau> I consider it simpler to implement and happy if it is not wrong
738 2013-01-14 18:25:03 <gmaxwell> sipa: how is this visible to the block ester htough?
739 2013-01-14 18:25:16 <meLon> https://github.com/m0mchil/poclbm/issues/55
740 2013-01-14 18:25:17 <sipa> it shouldn't be observable, imho
741 2013-01-14 18:25:19 <gmaxwell> We shouldn't be returning blocks not on the longest chain.
742 2013-01-14 18:25:37 <sipa> actually, it is
743 2013-01-14 18:25:47 <sipa> say you have chain A->B->C
744 2013-01-14 18:26:03 <sipa> then you publish a B' which does a spend of something already in A
745 2013-01-14 18:26:16 <sipa> no, i'm wrong - sorry
746 2013-01-14 18:26:40 <gmaxwell> Yea... don't see how this is visible, I'm not _sure_ it isn't but if it is we should consider fixing that.
747 2013-01-14 18:26:42 <sipa> i thought it wouldn't query a C' that builds on B' while bitcoind/j would, but it still will
748 2013-01-14 18:27:00 <sipa> unless it uses getheaders first
749 2013-01-14 18:27:06 <sipa> in that case it is observable
750 2013-01-14 18:27:49 <sipa> as it will know C' is invalid before seeing the TX data
751 2013-01-14 18:27:50 <sipa> grau: do you use getheaders?
752 2013-01-14 18:28:27 <gmaxwell> sipa: I could see that as a case where non-normative validation would be visible from he p2p port... though I doubt thats the case here.
753 2013-01-14 18:29:25 <grau> Not what I use. I see that the tester checks at least if running against bitcoinj that blocks connect to side chain even if double spend. BlueMatt would be able to confirm if it does the same against bitcoind
754 2013-01-14 18:30:15 <grau> https://code.google.com/r/bluemattme-bitcoinj/source/browse/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java?spec=svn8d318e905036be89d34cb543b347edde53f2cf40&name=newscripts&r=8d318e905036be89d34cb543b347edde53f2cf40
755 2013-01-14 18:31:14 <sipa> grau: they are placed in the block tree yes, but that's not something you should be able to observe from the P2P communication
756 2013-01-14 18:31:32 <grau> sends a block to bitcoind then queries if its there and it uses P2P to connect to bitcoind
757 2013-01-14 18:32:24 <grau> The tester sends blocks which it think they should connect or not and tests if it receives them back.
758 2013-01-14 18:32:53 <gmaxwell> Hm? We shouldn't be returning non-connected blocks.
759 2013-01-14 18:33:15 <grau> I have not confirmed this, but this is it looks to me
760 2013-01-14 18:33:29 <grau> the blck is connected
761 2013-01-14 18:33:33 <grau> it just double spends
762 2013-01-14 18:33:38 <gmaxwell> Have you actually run this tool against your system? Not some rewrite extraction, but the tool itself?
763 2013-01-14 18:34:32 <grau> No, because I already run into these problems running it direct calls from java
764 2013-01-14 18:37:01 <grau> As far as I understand the code, it creates a block chain and has two flags for each block "connect" and "exception" it feeds to bitcoinj with java calls or into bitcoind with P2P, then does a download and checks for connected blocks that they are there
765 2013-01-14 18:37:24 <grau> Thereby it considers blocks connected if they are on side chain with double spends
766 2013-01-14 18:38:00 <gmaxwell> grau: it is my belief and understanding that bitcoind will not return blocks on a sidechain.
767 2013-01-14 18:38:31 <grau> I hope you are right.
768 2013-01-14 18:40:31 <grau> The tester uses getheaders explicitelly specifying the hash it looks for. sipa: please validate if it does or not return from side chain
769 2013-01-14 18:41:41 <sipa> grau: it only announces blocks that become part of the new best chain
770 2013-01-14 18:42:56 <sipa> i *think*
771 2013-01-14 18:42:59 <sipa> let me check
772 2013-01-14 18:43:26 <grau> please check as it really looks from the test it would also confirm the existence of side chain blocks
773 2013-01-14 18:43:38 <sipa> yes, end of AcceptBlock()
774 2013-01-14 18:43:51 <BlueMatt> grau: the connects/throws is truly bitcoinj only, it is not a network construct, read the code carefully, the only thing it checks is what bitcoind's best-chain is after each block is sent
775 2013-01-14 18:44:10 <sipa> it only announces blocks that become the tip of the chain
776 2013-01-14 18:44:56 <grau> line 147 ?
777 2013-01-14 18:45:04 <gmaxwell> BlueMatt: thanks.
778 2013-01-14 18:45:22 <BlueMatt> grau: read it more carefully that is just checking bitcoinj's behavior
779 2013-01-14 18:45:34 <gmaxwell> grau: Easy and understandable misunderstandings like this is why its important to also just run the tool.
780 2013-01-14 18:46:25 <BlueMatt> grau: the only interface with bitcoind is when it calls either bitcoind.something() or in the event listener added to the peergroup
781 2013-01-14 18:53:32 <grau> I see now, the tool tests bitcoinj and bitcoind the same time and this check only applies to bitcoinj.
782 2013-01-14 18:54:03 <BlueMatt> yes
783 2013-01-14 18:55:59 <grau> I have an other question to the test case of b12
784 2013-01-14 18:56:05 <BlueMatt> shoot
785 2013-01-14 18:57:16 <grau> here you assume that in a sequence b13->b14-> where b13 is not connecting anywhere but b12 sent later that connects the client will remember b13 and b14
786 2013-01-14 18:57:26 <grau> and build a new longest chain
787 2013-01-14 18:57:59 <grau> this is correct, but I am not sure a protocol requirement
788 2013-01-14 18:58:03 <grau> to cache
789 2013-01-14 18:58:16 <BlueMatt> it is
790 2013-01-14 18:58:29 <BlueMatt> if you receive an orphan, you must attempt to connect it
791 2013-01-14 18:58:41 <sipa> to cache: not really - but if it receives a block whose ancestry is unknown, it must request the parent
792 2013-01-14 18:58:43 <grau> how long and how many ?
793 2013-01-14 18:59:17 <grau> I think it is questionable as generic rule
794 2013-01-14 18:59:48 <BlueMatt> and because the protocol is stateless, any reasonably well-coded network implementation should probably ask for the previous block, and then get it in the next+1 message, so it should easily reconnect that
795 2013-01-14 19:00:39 <sipa> the protocol is far from stateless :)
796 2013-01-14 19:00:54 <BlueMatt> well, semi-stateless
797 2013-01-14 19:00:55 <grau> yes, it is resonable to do so but is it required. You can be DoS-d by receiving blocks that have no previous
798 2013-01-14 19:01:07 <BlueMatt> its not clearly defined ask request-reply, etc
799 2013-01-14 19:01:25 <grau> That is why I question if it should be part of the test assumption
800 2013-01-14 19:01:33 <sipa> grau: there are checks you can do on difficulty/timestamp compared to the chain tip to see whether it is a viable candidate
801 2013-01-14 19:01:37 <grau> It is reasonable but is it a requirement ?
802 2013-01-14 19:01:41 <BlueMatt> grau: no you cant, as long as you take simple DoS precautions
803 2013-01-14 19:01:51 <sipa> grau: but yes, you can't be expected to keep an infinite cache of received orphan blocks
804 2013-01-14 19:02:04 <grau> thats the point.
805 2013-01-14 19:02:15 <sipa> grau: still, if you receive a block whose parent is unknown to you, you should try to connect it by requesting the parents
806 2013-01-14 19:02:26 <grau> yes
807 2013-01-14 19:02:33 <sipa> if you do that, there is no problem
808 2013-01-14 19:02:39 <sipa> caching only prevents some re-requesting
809 2013-01-14 19:02:40 <grau> It is reasonable, but is it part of the test to check reaorg ? I think not
810 2013-01-14 19:02:54 <BlueMatt> grau: protocol rule: "orphan blocks may only be discarded in cases where it is clear that the node providing those blocks is performing a DoS attack and those blocks will not be a part of the best chain"
811 2013-01-14 19:03:35 <grau> So this should be part of a DoS test, not reorg test