1 2013-06-29 00:27:44 <Morblias> in bitcoin-qt i ran importprivkey (private key), it froze for a good 3 minutes, then looked like it was finished, but the address didn't show up in receive tab. i ran it again and got Error adding key to wallet (code -4), however, now it shows up
2 2013-06-29 00:27:54 <Morblias> any idea why i had to run it twice to get it to show up?
3 2013-06-29 00:30:06 <gmaxwell> I had no idea that it would display there in the first place. That whole tab should probably go away for the confusion it creates.
4 2013-06-29 02:19:04 <imd23> hey guys
5 2013-06-29 02:19:09 <imd23> I still need to get a list of transactions given an address
6 2013-06-29 03:13:57 <maaku> imd23: if it's your address, list your transactions and filter
7 2013-06-29 04:09:12 <imd23> maaku: no, I need to ask about any addrs
8 2013-06-29 05:15:19 <midnightmagic> ryan-c: warner wrote it, here: https://github.com/warner/python-ecdsa
9 2013-06-29 05:15:46 <ryan-c> midnightmagic: Isn't that one pure perl?
10 2013-06-29 05:15:52 <ryan-c> er
11 2013-06-29 05:15:55 <ryan-c> pure python?
12 2013-06-29 05:16:04 <ryan-c> ACTION checks
13 2013-06-29 05:16:20 <midnightmagic> ah I thought by "native code" you actually meant native to the language.
14 2013-06-29 05:16:32 <ryan-c> No, I meant C/C++.
15 2013-06-29 05:16:37 <midnightmagic> ah
16 2013-06-29 05:16:48 <ryan-c> I need speed
17 2013-06-29 05:17:16 <midnightmagic> crypto++ then, so pycryptopp by zooko et al
18 2013-06-29 05:17:32 <midnightmagic> some of that stuff is written in assembly actually.
19 2013-06-29 05:17:33 <ryan-c> does it have python bindings?
20 2013-06-29 05:17:43 <ryan-c> asm is fine by me
21 2013-06-29 05:17:47 <midnightmagic> yeah that's why it's called pycryptopp. I run one of the buildslaves.
22 2013-06-29 05:18:00 <midnightmagic> :)
23 2013-06-29 05:19:02 <midnightmagic> they use it in tahoe-lafs. What I'm not sure of is whether it wraps the *entirety* of crypto++. I know there is a slight issue with /dev/random on platforms that block long enough to make crypto++ complain.
24 2013-06-29 09:33:10 <BW^-> btcd 0.8.1 takes 715MB RAM. so that is because of the networking stack more than anything, you say?
25 2013-06-29 09:33:12 <BW^-> (its networking)
26 2013-06-29 09:35:31 <sipa> use 0.8.2 or above
27 2013-06-29 09:35:44 <sipa> it has significant memory usage improvements
28 2013-06-29 09:43:14 <BW^-> sipa: aha noted
29 2013-06-29 10:31:35 <skfax> After receiving a transaction. Is there any point in "claiming" the outputs of the transaction sent to me further, by making a new transaction to myself with those outputs? Or are they already "safe" and "fully mine" without making a new transaction to myself with them?
30 2013-06-29 10:34:02 <sipa> if you're the only one with the private keys (and you should be), they're fully yours
31 2013-06-29 10:35:12 <skfax> cool, thanks
32 2013-06-29 10:35:31 <chmod755> MagicalTux, what happened to the wiki?
33 2013-06-29 10:36:54 <SomeoneWeird> chmod755, it ded
34 2013-06-29 10:37:04 <chmod755> NOOOOOO
35 2013-06-29 10:37:32 <chmod755> SomeoneWeird, but I paid the editing fee :(
36 2013-06-29 10:47:03 <rdymac> no plan on getting the wiki back?
37 2013-06-29 12:06:29 <tholenst> The current coverage of the unit tests: http://hex.ch/bitcoin/coverage-html/
38 2013-06-29 12:22:10 <tholenst> (i think this is probably wrong for header files, but for .c files it should correctly show the lines which are executed in one of the unit tests)
39 2013-06-29 13:38:57 <shamoon> i'm running: ./bitcoind -datadir=/mnt/myvol
40 2013-06-29 13:39:00 <shamoon> but when i then try to run ./bitcoind getinfo, i get an error
41 2013-06-29 13:39:09 <shamoon> i already set up a bitcoin.conf in /mnt/myvol
42 2013-06-29 13:41:43 <sipa> what error
43 2013-06-29 14:44:23 <maaku> why does WalletDB use the EC_KEY structure instead of DER encoding?
44 2013-06-29 14:53:01 <sipa> maaku: where?
45 2013-06-29 14:54:03 <maaku> ReadKeyValue(), strType == "key"
46 2013-06-29 14:54:31 <maaku> CPrivKey is an openssl EC_KEY structure, not a standards compliant DER string
47 2013-06-29 14:55:00 <sipa> EC_KEY is not a serialized data structure
48 2013-06-29 14:55:13 <sipa> they don't live in the same namespace
49 2013-06-29 14:55:25 <sipa> what is serialized is a DER private key
50 2013-06-29 14:55:42 <sipa> in wallet.dat
51 2013-06-29 14:56:25 <maaku> ah ok, i misunderstood what i2d_ECPrivateKey() was doing in key.cpp
52 2013-06-29 14:56:31 <maaku> CPrivKey is a DER structure
53 2013-06-29 14:56:33 <maaku> sorry
54 2013-06-29 14:56:36 <bmcgee> Hi all. I'm trying to understand block verification in a pool server, specifically what does a pool server need to calculate in order to verify a block. I've found some info online, nothing concrete.
55 2013-06-29 14:57:33 <maaku> bmcgee: send it to bitcoind and check if it was accepted
56 2013-06-29 14:57:45 <bmcgee> if you can point me in the direction of the relevant articles I'm happy to continue hunting.
57 2013-06-29 14:58:30 <bmcgee> maaku: I'm talking about verifying a block met the lower difficulty requirements of the pool server as proof of work, sending it to bitcoind every team seems redundant?
58 2013-06-29 14:58:44 <maaku> hash256(block) < target ?
59 2013-06-29 14:58:47 <maaku> it's a one-line check
60 2013-06-29 14:58:50 <sipa> bmcgee: that's the only thing that happens for shares: check the PoW
61 2013-06-29 14:59:04 <sipa> for non-full-block shares
62 2013-06-29 14:59:14 <bmcgee> so just hash the block data that was submitted thats all?
63 2013-06-29 14:59:30 <bmcgee> nothing extra or fancy?
64 2013-06-29 14:59:35 <maaku> nope
65 2013-06-29 14:59:38 <bmcgee> sweet
66 2013-06-29 15:00:14 <bmcgee> then as maaku pointed out if i find one that meets the full difficulty requirements punt it off to bitcoind
67 2013-06-29 15:00:28 <maaku> yes
68 2013-06-29 15:00:45 <bmcgee> grand. Easier than i thought it was going to be
69 2013-06-29 15:01:10 <maaku> it could still be rejected because you made a mistake in creating the block in the first place, or be stale because someone else found a block already
70 2013-06-29 15:02:04 <bmcgee> maaku yeah i get that, just makes pool impl easier for checking the proof of work if it's simply hash the submitted block data, rinse and repeat
71 2013-06-29 15:02:31 <bmcgee> for some reason i was expecting more work than that
72 2013-06-29 15:02:43 <bmcgee> maybe sacrifice a goat or some thing ;)
73 2013-06-29 15:11:31 <maaku> so SignCompact actually adds data to create a self-validating signature, yes?
74 2013-06-29 15:14:29 <sipa> indeed
75 2013-06-29 15:20:48 <petertodd> sipa: (filenum, blockoffset, txoffset, height) <- why do you need height? can't you get by from the block index?
76 2013-06-29 15:23:55 <sipa> petertodd: that would mean reading all transactions and the headers of the blocks they are in from disk, for every pagination
77 2013-06-29 15:24:12 <sipa> maybe that's acceptablr
78 2013-06-29 15:24:16 <sipa> *acceptable
79 2013-06-29 15:24:35 <sipa> but for 1dice addresses that probably means many seconds
80 2013-06-29 15:26:19 <petertodd> Oh ok, so the height is what provides the ordering. So filenum/blockoffset give your index to the on-disk blocks, txoffset is then the offset within the block, and height is what you use to iterate in the correct order right?
81 2013-06-29 15:48:40 <sipa> petertodd: right, it's just a way for doing an ahead-of-time ordering
82 2013-06-29 15:50:25 <petertodd> sipa: We have no nice way of maintaining an on-disk sorted list do we? Some kind of tree implementation or something?
83 2013-06-29 15:50:46 <sipa> petertodd: how would that help?
84 2013-06-29 15:50:56 <sipa> the point is avoiding touching the blocks on that
85 2013-06-29 15:51:05 <sipa> *disk
86 2013-06-29 15:51:55 <petertodd> sipa: Well you could have sorted transactions lists for every indexed "address", although that is pandering to re-use.
87 2013-06-29 15:53:17 <maaku> petertodd: the utxo index will have that
88 2013-06-29 15:53:45 <sipa> petertodd: well they are ordered on disk
89 2013-06-29 15:53:55 <sipa> petertodd: but you need something to order them by
90 2013-06-29 15:54:22 <petertodd> maaku: good point!
91 2013-06-29 15:54:27 <sipa> you can't sort by data that's not in the database
92 2013-06-29 15:54:34 <sipa> so you'd need to have the height stored
93 2013-06-29 15:55:26 <petertodd> sipa: right, brainfart... Yeah, well the full (filenum, blockoffset, txoffset, height) seems pretty reasonable, go for it.
94 2013-06-29 15:57:01 <petertodd> sipa: Might as well give enough features that we get people thinking about the awesome twitter bootstrap interface blockexplorer they can code up in just a bit of work. :)
95 2013-06-29 15:57:57 <petertodd> sipa: Oh, reminds me, there should also be a search mempool option too; implementing that inefficiently is probably fine.
96 2013-06-29 16:01:51 <sipa> petertodd: just linear iteration through the mempool is likely faster than any disk lookup :p
97 2013-06-29 16:02:05 <petertodd> sipa: Exactly!
98 2013-06-29 16:03:06 <sipa> ... for now
99 2013-06-29 19:38:25 <BW^-> did anyone write a patch to BTCD so that it creates an index with balance on every btc "address"?
100 2013-06-29 19:38:41 <BW^-> would be interested to unsterstand what's needed for that to happen.
101 2013-06-29 19:39:48 <nsh> what's BTCD?
102 2013-06-29 19:39:50 <nsh> bitcoind?
103 2013-06-29 19:39:51 <michagogo> BW^-: I think sipa had something like that
104 2013-06-29 19:40:02 <michagogo> ;;google bitcoin addrindex
105 2013-06-29 19:40:03 <gribble> sipa pushed to addrindex at sipa/bitcoin - GitHub: <https://github.com/sipa/bitcoin/compare/39cc8bb3ba...48f219b7a9>
106 2013-06-29 19:40:27 <michagogo> https://github.com/sipa/bitcoin/tree/addrindex
107 2013-06-29 19:41:12 <gmaxwell> michagogo: wrong answer, you should have said that he needed to donate 1 BTC to sipa. :P
108 2013-06-29 19:41:24 <michagogo> gmaxwell: lol?
109 2013-06-29 19:41:52 <sipa> technically, not a balance of every address
110 2013-06-29 19:42:11 <sipa> just an index to fimd all tramsactions affecting an address
111 2013-06-29 19:43:31 <sipa> petertodd: if i add heights, i might as well add vout indices
112 2013-06-29 19:54:39 <BW^-> nsh: yeah
113 2013-06-29 19:55:08 <nsh> right, thanks
114 2013-06-29 19:55:10 <BW^-> sipa: how far is this from having the balance like that?
115 2013-06-29 19:55:11 <nsh> (
116 2013-06-29 19:57:26 <BW^-> cool to see that it's there. now, i need to do some general digging to understand things. :)
117 2013-06-29 19:59:26 <BW^-> sipa: wow, that's an incredible amount of branches you have, what are all of them for?
118 2013-06-29 19:59:59 <BW^-> just different nice things that happened not to have gotten further upstream yet?
119 2013-06-29 20:01:54 <BW^-> gmaxwell: i'm glad to learn to know the thing, and will be happy to do that when there's opportunity.
120 2013-06-29 20:04:36 <sipa> BW^-: most are merged
121 2013-06-29 20:04:43 <sipa> i forget to clean them up
122 2013-06-29 20:05:38 <sipa> and i dislike the idea of "balance of an address"
123 2013-06-29 20:05:52 <sipa> you shouldnt reuse addresses
124 2013-06-29 20:06:41 <sipa> though you could iterate all transactions affecting an address, and compute their summed effect
125 2013-06-29 20:07:14 <sipa> though an address-imdexed UTXO set would be much more efficient even
126 2013-06-29 20:07:17 <gmaxwell> a 'balance' is a utxo operation in any case, not a historical index operation.
127 2013-06-29 20:09:39 <BW^-> sipa: note made on idea of reusing
128 2013-06-29 20:10:39 <BW^-> sipa: ah - wait - and this you made here is, in contrast, an index over which?
129 2013-06-29 20:11:15 <BW^-> gr8 to see the RAM use decrease in 0.8.2 btw, it went down by another 60% with this release.
130 2013-06-29 20:11:50 <jouke> Hmmm, interesting sipa :) Does it include mempool transactions as well?
131 2013-06-29 20:13:05 <BW^-> how does mining software interface btcd, via the JSON RPC somehow?
132 2013-06-29 20:14:19 <sipa> yes
133 2013-06-29 20:14:34 <sipa> rpc is the only way to interact with it
134 2013-06-29 20:14:39 <sipa> jouke: no
135 2013-06-29 20:15:02 <sipa> jouke: though thats easy to add
136 2013-06-29 20:15:40 <BW^-> sipa: except for if you're in the QT compile right?
137 2013-06-29 20:15:40 <sipa> BW^-: also it is really not called btcd but bitcoind
138 2013-06-29 20:15:45 <BW^-> ok
139 2013-06-29 20:15:50 <BW^-> just wanted to abbreviate :))
140 2013-06-29 20:15:56 <sipa> humans are not sha256 hashers
141 2013-06-29 20:16:03 <sipa> only hu,ams use the gui
142 2013-06-29 20:16:08 <nsh> speak for yourself sipa
143 2013-06-29 20:16:14 <nsh> my liver does 7 GH/s
144 2013-06-29 20:16:30 <sipa> i never claimed your liver was a human
145 2013-06-29 20:16:37 <xenland> to bad your brain only does 2kh/s on bitcoin mining
146 2013-06-29 20:16:51 <xenland> (:P)
147 2013-06-29 20:17:28 <nsh> :(
148 2013-06-29 20:17:28 <sipa> nsh: if claim your liver does use the GUI, well go to a hospital
149 2013-06-29 20:17:54 <nsh> every time i go to hospital they want to show me off at a medical convention
150 2013-06-29 20:24:45 <BW^-> is there a tutorial anywhere for how to make a full cycle of use with the RPC - create account/wallet, create and retrieve public address, receive transaction, check it got there, send to third party, close ?
151 2013-06-29 20:25:36 <xenland> BW^ Theres many paths to using the RPC for just doing one type of transaction, there would be quiet a bit, BUT you gave me a great idea to add to my Bitcoindevkit.com website
152 2013-06-29 20:26:52 <gmaxwell> BW^-: what you're asking there doesn't even make sense to me.
153 2013-06-29 20:27:08 <gmaxwell> "create and retrieve public address" what?
154 2013-06-29 20:27:09 <BW^-> xenland: could you explain to me now how this is done? =))) i'm quite eager
155 2013-06-29 20:27:21 <BW^-> gmaxwell: bitcoind does public address generation for you right?
156 2013-06-29 20:27:35 <BW^-> gmaxwell: i was looking for that, how do you create a private/public pair with it and then get it
157 2013-06-29 20:27:41 <xenland> BW^- Are you using windows or linux?
158 2013-06-29 20:27:49 <BW^-> xenland: linux
159 2013-06-29 20:27:55 <BW^-> but the RPC is the same on both
160 2013-06-29 20:28:00 <BW^-> i mean, just in terms of rpc calls
161 2013-06-29 20:28:01 <xenland> And you already know how to send commands to the btc rpc?
162 2013-06-29 20:28:17 <gmaxwell> BW^-: it sounds like you're expecting to use it in a way that its not intended to be used.
163 2013-06-29 20:28:18 <xenland> first you should memorize ./bitcoind list
164 2013-06-29 20:28:22 <k9quaint> gmaxwell: you made a new friend
165 2013-06-29 20:28:26 <BW^-> gmaxwell: what's the intended use of the RPC?
166 2013-06-29 20:28:28 <gmaxwell> Bitcoind manages a single wallet.
167 2013-06-29 20:28:47 <gmaxwell> A wallet contains many addresses, each address is intended to be used once.
168 2013-06-29 20:28:51 <BW^-> xenland: yes, i know how to invoke the JSON RPC over HTTP.
169 2013-06-29 20:28:56 <gmaxwell> k9quaint: hm?
170 2013-06-29 20:29:01 <k9quaint> gmaxwell: his name is stamit, and he has a great love for you and your body of work
171 2013-06-29 20:29:37 <k9quaint> he offered me BTC to slander you
172 2013-06-29 20:29:41 <k9quaint> I accepted of course
173 2013-06-29 20:29:54 <gmaxwell> sweet.
174 2013-06-29 20:30:23 <k9quaint> not gonna split it with you, if that is what you are thinking
175 2013-06-29 20:30:24 <gmaxwell> k9quaint: can you get him to pay me the 10 BTC he promised?
176 2013-06-29 20:30:45 <gmaxwell> k9quaint: if you get him to pay the 10 BTC I'll split it with you as a collection fee.
177 2013-06-29 20:30:49 <k9quaint> gmaxwell: I do not think he is open to further suggestions from me ;)
178 2013-06-29 20:30:50 <Luke-Jr> lol
179 2013-06-29 20:30:53 <Luke-Jr> good luck
180 2013-06-29 20:31:15 <Luke-Jr> gmaxwell: he's offering monetary rewards to anyone doing us physical or reputational harm
181 2013-06-29 20:31:24 <Luke-Jr> us = gmaxwell or luke-jr
182 2013-06-29 20:31:25 <k9quaint> in his defense, some of my suggestions may have been anatomically impossible
183 2013-06-29 20:31:49 <gmaxwell> Luke-Jr: why you?!
184 2013-06-29 20:32:03 <k9quaint> Luke-Jr dinged him in reputation on btc-otc
185 2013-06-29 20:32:07 <gmaxwell> ...
186 2013-06-29 20:32:08 <Luke-Jr> gmaxwell: I guess because every time he starts, I try to wake up an op to ban him? dunno
187 2013-06-29 20:32:11 <BW^-> gmaxwell: single wallet - yep i'm all pro that. addresses not reusable - aha. is the way the RPC is made today, hardwired to addresses being singe-use?
188 2013-06-29 20:32:35 <Luke-Jr> oh yeah that too
189 2013-06-29 20:32:37 <Luke-Jr> I negrated him lol
190 2013-06-29 20:32:43 <gmaxwell> BW^-: indirectly.
191 2013-06-29 20:33:15 <BW^-> gmaxwell: how?
192 2013-06-29 20:33:30 <BW^-> xenland: what would you do "bitcoind list" for?? i don't see any "list" option, closest is "-listen"?
193 2013-06-29 20:33:37 <gmaxwell> k9quaint: you know, if everyone who has observed him being a psycho negrated him he'd have less reason to fixate on just the few people courageous enough to do it.
194 2013-06-29 20:34:59 <k9quaint> gmaxwell: the site wanted me to login to do it, so I lost interest
195 2013-06-29 20:35:24 <gmaxwell> All that is necessary for the triumph of evil is that good men do nothing.
196 2013-06-29 20:35:39 <k9quaint> plus, if I was to click on every pyscho in the bitcoin landscape I wouldn't have time to watch Downton Abbey
197 2013-06-29 20:35:52 <gmaxwell> hah
198 2013-06-29 20:36:08 <BW^-> xenland: ah, that issues a "list" rpc call; oh, that seems to make my bitcoind SIGSEGV!
199 2013-06-29 20:36:09 <BW^-> hm
200 2013-06-29 20:36:12 <k9quaint> gmaxwell: I can be evil if I work at it, so I can hedge my bets if good men get lazy
201 2013-06-29 20:36:19 <gmaxwell> BW^-: perhaps he meant "help"
202 2013-06-29 20:36:27 <gmaxwell> BW^-: wtf bitcoind are you running?!
203 2013-06-29 20:36:30 <BW^-> gmaxwell: hm yeah
204 2013-06-29 20:36:36 <BW^-> gmaxwell: 0.8.3, OBSD port
205 2013-06-29 20:36:40 <Luke-Jr> ironically, I think my negrating on stamit is only -2 or -3
206 2013-06-29 20:36:48 <BW^-> let's try once more
207 2013-06-29 20:37:01 <BW^-> in gdb
208 2013-06-29 20:37:01 <gmaxwell> BW^-: fwiw, I wouldn't recommend running bitcoind on openbsd. It's pratically untested there.
209 2013-06-29 20:37:27 <Vinnie_win> gmaxwell: What about FreeBSD ?
210 2013-06-29 20:37:30 <gmaxwell> (well, otoh, if you're willing to run in gdb and fix bugs! by all means, use openbsd!)
211 2013-06-29 20:37:32 <BW^-> gmaxwell: thanks for pointing out, well i know it's useless for mining there anyhow. we'll see if it shows to be stable, i'd kind-of guess it does.
212 2013-06-29 20:37:38 <gmaxwell> Vinnie_win: Same deal.
213 2013-06-29 20:37:50 <Vinnie_win> gmaxwell: I've been dealing with FreeBSD lately. It's a PITA.
214 2013-06-29 20:38:01 <BW^-> gmaxwell: how are public addresses indirectly intended for single use, by the RPC?
215 2013-06-29 20:38:06 <gmaxwell> I'm sorry for anyone who has to use freebsd. :P
216 2013-06-29 20:38:09 <BW^-> vinnie_win: how PITA?
217 2013-06-29 20:38:21 <Vinnie_win> BW^-: They have to do everything their own "special" way.
218 2013-06-29 20:38:51 <BW^-> vinnie_win: like how?
219 2013-06-29 20:39:12 <BW^-> gmaxwell: on OBSD at least it downloads and verifies all tx:es correctly , so it does run well.
220 2013-06-29 20:39:20 <BW^-> gmaxwell: i do have an impression there's some people using it
221 2013-06-29 20:39:23 <Vinnie_win> BW^-: Some APIs are different, so every application under the sun has to be "ported" which means manually jiggering up some patches or something so that the application can be compiled.
222 2013-06-29 20:39:34 <gmaxwell> BW^-: there is a lot to correctness beyond starts up and runs though.
223 2013-06-29 20:39:38 <Vinnie_win> BW^-: If there is no "port" for your system then you might be S.O.L.
224 2013-06-29 20:39:51 <BW^-> vinnie_win: there's a port.
225 2013-06-29 20:39:52 <gmaxwell> BW^-: all change is sent to new addresess, there are no good facilities to manage 'old' addresses, no real facilities to control which coins you spend on a address oriented basis, ... and no plans to add any of that to the rpc because address reuse undermines part of the bitcoin security model.
226 2013-06-29 20:40:41 <BW^-> gmaxwell: how does address reuse undermine the security model, beyond that it increases the relative theoretical possibility that someone would get hold of your privkey just because it exists?
227 2013-06-29 20:40:50 <gmaxwell> Vinnie_win: I'm all for writing highly portable software, and I think its desirable that bitcoind work well on all systems... but that doesn't mean I'd generally recommend it. :)
228 2013-06-29 20:41:01 <sipa> s/security model/privacy model/
229 2013-06-29 20:41:08 <gmaxwell> BW^-: because it makes it far clearer which coins are owned by which people.
230 2013-06-29 20:41:15 <sipa> though i guess privacy is part of security in the general sense
231 2013-06-29 20:41:23 <BW^-> gmaxwell,vinnie_win: bitcoind is implemented fundamentally in a portable-friendly way. making it stable on F/OBSD for non-mining purposes should not be a big deal.
232 2013-06-29 20:41:23 <gmaxwell> Yea, I meant it in the general sense.
233 2013-06-29 20:41:48 <BW^-> gmaxwell: in the sense i just described after "beyond "?
234 2013-06-29 20:42:01 <BW^-> kinda solely?
235 2013-06-29 20:42:06 <gmaxwell> BW^-: Its actually pretty unportable.
236 2013-06-29 20:42:16 <gmaxwell> I invite you to go try to run it on a sparc box.
237 2013-06-29 20:42:19 <gmaxwell> :P
238 2013-06-29 20:42:24 <BW^-> :))
239 2013-06-29 20:42:27 <sipa> BW^-: the change of someone getting a private key randomly is negligable
240 2013-06-29 20:42:31 <BW^-> gmaxwell: how? i see boost and leveldb as deps. maybe depends on endinaness?
241 2013-06-29 20:42:42 <sipa> BW^-: but not losing coins is not the only property
242 2013-06-29 20:42:52 <sipa> BW^-: you also want privacy
243 2013-06-29 20:42:53 <gmaxwell> BW^-: leveldb as a dep?! has your openbsd port unbundled leveldb?!
244 2013-06-29 20:43:40 <BW^-> gmaxwell: correct.
245 2013-06-29 20:43:45 <BW^-> gmaxwell: ah yes, indeed it is a dep there.
246 2013-06-29 20:43:47 <gmaxwell> Privacy has deep implications. If bitcoin is inadaqutely private it breaks fungibility. There become incentives to coerce miners to filter and blacklist particular addresses that wouldn't exist otherwise.
247 2013-06-29 20:43:47 <sipa> bah
248 2013-06-29 20:43:53 <Vinnie_win> ACTION frowns on deps
249 2013-06-29 20:44:02 <BW^-> sipa,gmaxwell: may that be a problem?
250 2013-06-29 20:44:12 <sipa> BW^-: leveldb is in our source tree for a reason
251 2013-06-29 20:44:16 <BW^-> sipa,gmaxwell: https://github.com/jasperla/openbsd-wip/tree/master/net/bitcoin
252 2013-06-29 20:44:33 <BW^-> sipa: aha. like.. is it patched or anything?
253 2013-06-29 20:44:52 <gmaxwell> BW^-: not that we _currently_ know. But leveldb has made fixes in the past that may have caused chain forking if nodes in the network were mixed versions.
254 2013-06-29 20:45:06 <Vinnie_win> Any patches that make leveldb compile on <whatever>BSD should be applied into the LevelDB tree so that it works anywhere.
255 2013-06-29 20:45:13 <gmaxwell> BW^-: it is patched, in fact, though I don't believe any are relelvant for openbsd.
256 2013-06-29 20:45:18 <sipa> indeed
257 2013-06-29 20:45:21 <gmaxwell> Vinnie_win: and that too.
258 2013-06-29 20:45:40 <sipa> gmaxwell, Vinnie_win: when i first tested my addrindex patch, leveldb broke, by the way
259 2013-06-29 20:45:49 <Vinnie_win> ACTION sighs
260 2013-06-29 20:45:58 <sipa> i tried 1.12 then, and it was solved
261 2013-06-29 20:45:58 <Vinnie_win> sipa: Do you have a stand alone repo that can repro the defect?
262 2013-06-29 20:46:04 <Vinnie_win> oh! /phew
263 2013-06-29 20:46:35 <BW^-> sipa: so.. if i want to run the addrindex patch, I need to *not* use the bundled levelDB?
264 2013-06-29 20:46:48 <sipa> BW^-: that has nothing to do with it
265 2013-06-29 20:46:49 <gmaxwell> BW^-: the concern is that effectively the database behavior is part of the protocol rules which must be uniform in the network. Leveldb's authors aren't concerned about maintaining a level of uniform behavior which is sufficient for our needs??? not that they'd intentionally break us, but they're probably not vigilant enough.
266 2013-06-29 20:47:25 <Vinnie_win> gmaxwell: I'm at a loss to imagine how the behavior of the database could possibly affect the network...unless there's a data corruption bug...
267 2013-06-29 20:47:48 <BW^-> ok
268 2013-06-29 20:47:51 <gmaxwell> Vinnie_win: for example. say leveldb has a bug that makes it not able to find transaction 0xDEADBEEF. Then they fix it.
269 2013-06-29 20:47:55 <sipa> well, something like bdb before, where there was a limited number of locks, was not excepted either
270 2013-06-29 20:48:03 <BW^-> gmaxwell: now, back to how to use the RPC for creating a wallet, receiving to it, and sending from it. where can i learn this?
271 2013-06-29 20:48:16 <Vinnie_win_n> ACTION has just returned from a disconnect
272 2013-06-29 20:48:17 <sipa> BW^-: creating a wallet... done at first startup
273 2013-06-29 20:48:18 <BW^-> just to know that i certainly got it. :))
274 2013-06-29 20:48:28 <sipa> BW^-: receiving coins: getnewaddress and ask people to send to it
275 2013-06-29 20:48:34 <Vinnie_win_n> gmaxwell: I'm at a loss to imagine how the behavior of the database could possibly affect the network...unless there's a data corruption bug...
276 2013-06-29 20:48:36 <gmaxwell> An example of a leveldb fix before we started using it was that it used to run into file descriptor limits and then silently fail to return answers.
277 2013-06-29 20:48:39 <sipa> BW^-: sending coins: sendtoaddress <amount> <address>
278 2013-06-29 20:48:43 <sipa> BW^-: anything else? :p
279 2013-06-29 20:48:46 <Vinnie_win_n> gmaxwell: Oh my...
280 2013-06-29 20:48:49 <gmaxwell> 15:44 < gmaxwell> Vinnie_win: for example. say leveldb has a bug that makes it not able to find transaction 0xDEADBEEF. Then they fix it.
281 2013-06-29 20:48:59 <Vinnie_win_n> ACTION facepalms
282 2013-06-29 20:49:01 <gmaxwell> (I said that while you were gone)
283 2013-06-29 20:49:41 <BW^-> sipa: cool. how check if anything was received to the particular public address, like, number of confirmations?
284 2013-06-29 20:49:41 <gmaxwell> So thats how database behavior can cause forking in the network??? some nodes will accept blocks that others wont??? and this can be the result of _fixing_ a _clear_ bug.
285 2013-06-29 20:49:48 <sipa> BW^-: listtransactions
286 2013-06-29 20:50:26 <Vinnie_win> gmaxwell: I see, I see. This is pretty lame
287 2013-06-29 20:50:33 <gmaxwell> Vinnie_win_n: ideally we should handle leveldb in a 'suspicious enough' manner that its hard for them to undermine us like this??? the current code does an okay job, I think. The older code prior to us using leveldb was too trusting.
288 2013-06-29 20:50:48 <BW^-> sipa: great. what's the "account" abstraction within the wallet?
289 2013-06-29 20:50:53 <sipa> BW^-: ignore it
290 2013-06-29 20:50:58 <BW^-> sipa: so, the wallet is the global realm of use within the RPC
291 2013-06-29 20:51:09 <BW^-> sipa: just pass "0" ass account always? why ignore it, is it not implemented?
292 2013-06-29 20:51:15 <Vinnie_win> gmaxwell: I'll add "implement robust key/value store database" to my todo
293 2013-06-29 20:51:34 <BW^-> sipa: now, after having learned this, i want to understand the code path of sending and receving, fully through the backend, as to have this great enlightenment-aha experience :))))
294 2013-06-29 20:51:34 <gmaxwell> BW^-: the account abstraction is just a bookeeping feature. It allows you to split out your balance amount into differen groups... but really has nothing much to do with addresses.
295 2013-06-29 20:51:40 <sipa> BW^-: it is implemented, and it works, but unless you have a very specific use case, it's likely not to do what you expect
296 2013-06-29 20:51:46 <sipa> BW^-: and not what you need
297 2013-06-29 20:52:03 <BW^-> gmaxwell: yeah i know, though if it's needed for using the RPC, it's time for me to understand that now :)
298 2013-06-29 20:52:06 <gmaxwell> Vinnie_win: and it has to be stupidly fast, and survive abusive use like unclean shutdowns that corrupt the most recently written data.
299 2013-06-29 20:52:20 <BW^-> sipa: aha, so i better just use "0" for this?
300 2013-06-29 20:52:20 <sipa> BW^-: you don't need to use it
301 2013-06-29 20:52:23 <BW^-> aha
302 2013-06-29 20:52:33 <Vinnie_win> gmaxwell: Yep. sqlite's low level block / journal interface is pretty solid so its definitely doable.
303 2013-06-29 20:52:48 <gmaxwell> Vinnie_win: sqllite itself is slow as shit (compared to leveldb)
304 2013-06-29 20:52:52 <gmaxwell> :(
305 2013-06-29 20:53:03 <BW^-> sipa: maybe i'd be happy to understand this now -
306 2013-06-29 20:53:04 <Vinnie_win> gmaxwell: I'm referring to the low level block routines. Yes the relational part will of course be slower
307 2013-06-29 20:53:14 <BW^-> sipa: so are accounts basically subdivisioning of the wallet into "subwallets"?
308 2013-06-29 20:53:29 <BW^-> sipa: so that received coins are accumulated in those respective "subwallets"?
309 2013-06-29 20:53:47 <sipa> BW^-: NO
310 2013-06-29 20:53:50 <sipa> no subwallets
311 2013-06-29 20:53:59 <sipa> coins belong to the wallet, not to an account
312 2013-06-29 20:54:03 <gmaxwell> Vinnie_win: I suspect that leveldb's robustness to unclean shutdown is not good on win32 or osx. (we get a lot of database corruption reports there which seem to be mostly absent on linux??? and I've tried like hell to corrupt mine and never had luck)
313 2013-06-29 20:54:05 <sipa> an account is really just a number
314 2013-06-29 20:54:31 <gmaxwell> ^ a balance number, just like making memos in your checkbook.
315 2013-06-29 20:54:50 <gmaxwell> "These funds are for groceries, these funds are for rent. These funds are from my lawn mowing business."
316 2013-06-29 20:54:55 <sipa> BW^-: it's useful if you want to run a shared wallet service, with per-user balances
317 2013-06-29 20:55:19 <BW^-> aha
318 2013-06-29 20:55:43 <sipa> BW^-: the rules are this
319 2013-06-29 20:56:16 <sipa> * if an address A has label L, then any transaction crediting A, will increase the account with name L's balance
320 2013-06-29 20:56:24 <Vinnie_win> http://en.wikipedia.org/wiki/Data_cleansing
321 2013-06-29 20:56:44 <sipa> * sendtoaddress will always decrease the balance of account ""
322 2013-06-29 20:56:52 <sipa> * sendfrom will decrease the specified account
323 2013-06-29 20:57:03 <sipa> * move will deduct from one account and add to another
324 2013-06-29 20:57:31 <sipa> and accounts can ge negative, no problem
325 2013-06-29 20:57:39 <sipa> their sum can't be negative, though
326 2013-06-29 20:58:26 <BW^-> sipa: what do you mean by that acocunts can be negative but sum can't be negative - ah - you mean that, on the RPC call, sum must be positive
327 2013-06-29 20:58:38 <BW^-> sipa: though, as long as there's coins in the wallet..
328 2013-06-29 20:58:49 <gmaxwell> Vinnie_win: its annoying that the utxo set can't currently be incrementally tested. So you can't really tell if yours is right without scanning the whole thing.
329 2013-06-29 20:58:51 <BW^-> sipa: then it's no problem how far below zero an individual contained account's balance goes?
330 2013-06-29 20:59:15 <sipa> BW^-: well the sum of all accounts corresponds to the balance of the wallet
331 2013-06-29 20:59:20 <Vinnie_win> gmaxwell: I was thinking along the lines of a background task, randomly test portions of the database against information from peers? Is that not possible because of the structure of the data?
332 2013-06-29 20:59:25 <sipa> BW^-: wallets can't have negative coins :)
333 2013-06-29 20:59:37 <BW^-> right.
334 2013-06-29 20:59:52 <BW^-> sipa: aha, so <account> is of type string?
335 2013-06-29 20:59:54 <sipa> yes
336 2013-06-29 21:00:02 <Vinnie_win> gmaxwell: How about using two databases. The current LevelDB database with full data, and then a side database which is robust (SQLite for example) for just the hashes / chain information?
337 2013-06-29 21:00:03 <sipa> scanning the whole UTXO set takes... a few seconds
338 2013-06-29 21:00:04 <gmaxwell> Vinnie_win: not currently very possible. In the future it may be.
339 2013-06-29 21:00:20 <BW^-> cool
340 2013-06-29 21:00:20 <gmaxwell> Vinnie_win: 2x storage, 2x working set size... meh, pretty high cost. :(
341 2013-06-29 21:00:34 <sipa> extra dependency, extra chances for inconsistency, ...
342 2013-06-29 21:00:37 <Vinnie_win> gmaxwell: Well if the alternative is to have no data cleansing, its at least useful to have as an option.
343 2013-06-29 21:00:39 <BW^-> sipa: the move operation is only abstract and does not actually lead to any operation on the bitcoin network, right?
344 2013-06-29 21:00:43 <gmaxwell> Vinnie_win: if we merkelize the utxo set then you'd be able to test your database, and then to compare with peers you just need to compare the roots.
345 2013-06-29 21:00:45 <sipa> BW^-: correct
346 2013-06-29 21:00:50 <BW^-> it's only an internal restructuring within the wallet. aha noted.
347 2013-06-29 21:01:09 <Vinnie_win> When I say 2 db I mean that the second one would be only for cleansing, not to store a redundant copy of everything
348 2013-06-29 21:01:14 <BW^-> sipa: then, like a big question: is there Any way that I can easily import cold stored wallets using privkey-pubkey pairs into my wallet?
349 2013-06-29 21:01:17 <gmaxwell> Vinnie_win: well we do have data clensing, in that at startup we undo and reapply the last 144 blocks. So any corruption that is at all related to them will be reliably detected.
350 2013-06-29 21:01:27 <sipa> BW^-: importprivkey
351 2013-06-29 21:01:30 <BW^-> sipa: did you or anyone implement an index for this so that that is done real fast - that's what your addrindex is about right?
352 2013-06-29 21:01:34 <Vinnie_win> gmaxwell: That's pretty smart
353 2013-06-29 21:01:50 <gmaxwell> Vinnie_win: the theory was that corruption was most likely to be in the most recent blocks.
354 2013-06-29 21:02:12 <BW^-> sipa: any way to make it indexed (as in, not need to scan all these 8GB of info for each such operation)
355 2013-06-29 21:02:12 <sipa> BW^-: it could be used for that, but i really dislike that
356 2013-06-29 21:02:19 <BW^-> sipa: why is that?
357 2013-06-29 21:02:22 <BW^-> that you dislike that
358 2013-06-29 21:02:24 <sipa> BW^-: because there is no need for it
359 2013-06-29 21:02:31 <sipa> you shouldn't be dealing with individual addresses
360 2013-06-29 21:02:38 <Luke-Jr> gmaxwell: I wonder if that's actually the case
361 2013-06-29 21:02:40 <sipa> just work with wallets
362 2013-06-29 21:02:46 <Luke-Jr> does it tell the user if it finds/fixes a problem?
363 2013-06-29 21:02:47 <gmaxwell> We could go further back, but it delays startup, so there is the tradeoff.. doesn't really work well in the background, unless we wanted to snapshot the state... and can only be validated linearly not randomly.
364 2013-06-29 21:03:00 <sipa> Luke-Jr: it will tell the user to reindex
365 2013-06-29 21:03:05 <Luke-Jr> don't we already snapshot the state for mining?
366 2013-06-29 21:03:08 <BW^-> sipa: well, that would provide a way for things to be a bit more "plug and play"
367 2013-06-29 21:03:29 <BW^-> sipa: also, the privkey-pubkey pairs is like the hard information, while wallets are functions of those+ the blockchain db content, so they do have sense
368 2013-06-29 21:03:29 <gmaxwell> Luke-Jr: and we've seen it happening??? thats partly why we know that its not reliable for some people.
369 2013-06-29 21:03:40 <sipa> BW^-: and building infrastructure that relies on a fully-indexed history of forever to be ever available
370 2013-06-29 21:03:46 <gmaxwell> (a few people have reported it randomly getting stuck, but most of the reports have been it self-detecting errors)
371 2013-06-29 21:03:55 <sipa> BW^-: i want bitcoin to scale
372 2013-06-29 21:04:08 <BW^-> sipa: hm. well, yeah, that might be an interesting point. hm.
373 2013-06-29 21:04:22 <sipa> and wallets are more than just keypairs
374 2013-06-29 21:04:29 <sipa> you want to give labels to your addresses
375 2013-06-29 21:04:36 <BW^-> sipa: yeah, they're the past TX:es relating to them too, right, and that's it?
376 2013-06-29 21:04:55 <sipa> and perhaps have metadata like signed invoices associated with them
377 2013-06-29 21:04:59 <gmaxwell> lol "The best thing about UDP jokes is that you don't have to care if nobody gets them."
378 2013-06-29 21:05:03 <sipa> and payment descriptors
379 2013-06-29 21:05:23 <sipa> i think as we progress, we'll move away more and more from the idea that a wallet is just keys
380 2013-06-29 21:05:26 <Luke-Jr> lol
381 2013-06-29 21:05:43 <sipa> and losing a wallet is a problem in any case, even if you don't lose the keys
382 2013-06-29 21:06:41 <BW^-> sipa: why is it currently a problem, beyond that you'd need to reimport the keys?
383 2013-06-29 21:07:04 <sipa> BW^-: what is currently a problem?
384 2013-06-29 21:07:35 <sipa> i think we're hurting our growth by building infrastructure that relies on being able to easily import keys
385 2013-06-29 21:07:43 <gmaxwell> BW^-: because you lose any of your metadata??? account info, unconfirmed transactions, labels, comments.
386 2013-06-29 21:08:01 <sipa> if you have the keys, you won't lose money
387 2013-06-29 21:08:09 <sipa> but a wallet is often more than just money
388 2013-06-29 21:08:30 <sipa> so, you need to have backups of your wallet anyway
389 2013-06-29 21:08:35 <BW^-> gmaxwell: what about unconfirmed transactions, those get confirmed by the system itself, so they're not sensitive to reconstruction of wallet out of privkey-pubkey pairs no?
390 2013-06-29 21:08:42 <BW^-> sipa: yep i follow you
391 2013-06-29 21:09:14 <BW^-> the "list" rpc call on OBSD 5.2 sigsegv produces this https://pastee.org/y3sbv , looks like I need to compile bitcoind with debug symbols!
392 2013-06-29 21:09:14 <gmaxwell> Bitcoind takes up 10gb of space instead of 1.5gb space because of being able to import keys.
393 2013-06-29 21:09:27 <BW^-> gmaxwell: you mean disk space?
394 2013-06-29 21:09:32 <gmaxwell> Yes.
395 2013-06-29 21:09:33 <sipa> ... there is no 'list' RPC call
396 2013-06-29 21:09:46 <BW^-> gmaxwell: wait - you mean that today, this is how it is?
397 2013-06-29 21:09:56 <gmaxwell> BW^-: If your txn is not confirmed yet its up to you to keep rebroadcasting it until it gets confirmed.
398 2013-06-29 21:09:57 <sipa> yes
399 2013-06-29 21:10:38 <sipa> not surprisingly, boost
400 2013-06-29 21:10:41 <BW^-> sipa: em, that makes the sigsegv funnier, no, as the rpc call should just be ignored?
401 2013-06-29 21:10:44 <gmaxwell> BW^-: that backtrace isn't super useful, :(
402 2013-06-29 21:10:53 <BW^-> gmaxwell: yeah, i should compile with debug symbols on
403 2013-06-29 21:10:57 <gmaxwell> what version of boost do you have?
404 2013-06-29 21:11:01 <sipa> BW^-: it should return "method not found"
405 2013-06-29 21:11:06 <BW^-> when making bitcoind, using what arg is that done?
406 2013-06-29 21:11:16 <sipa> ?
407 2013-06-29 21:11:34 <BW^-> sipa: on compilation, how do i instruct the make script to compile with debug symbols on?
408 2013-06-29 21:11:37 <BW^-> \\enabled\\
409 2013-06-29 21:11:39 <gmaxwell> our makefiles include debug symbols by default, IIRC. god knows what the obsd port has done. :(
410 2013-06-29 21:12:26 <BW^-> gmaxwell: yeah, the obsd port currently wipes out your /dev/null so you need to create it from scratch too :)))
411 2013-06-29 21:12:33 <BW^-> gmaxwell: so there is something left to get in place clearly :)
412 2013-06-29 21:12:50 <BW^-> confirmed - the obsd bitcoind binary is without debug symbols, i checked separately.
413 2013-06-29 21:12:51 <gmaxwell> !@#
414 2013-06-29 21:12:51 <gribble> Error: "@#" is not a valid command.
415 2013-06-29 21:13:09 <gmaxwell> maybe they just want you to not build things as root? :P
416 2013-06-29 21:13:13 <BW^-> hehe
417 2013-06-29 21:13:17 <BW^-> maybe it's the make install part
418 2013-06-29 21:13:49 <BW^-> aha, i just tried a "listtransactions" RPC call and it properly returned [\\n]
419 2013-06-29 21:14:20 <sipa> my guess: a problem with exception handling
420 2013-06-29 21:14:32 <sipa> in particular across libraries
421 2013-06-29 21:14:49 <BW^-> sipa: that does makes sense, I have seen issues in that area before.
422 2013-06-29 21:15:17 <BW^-> when mixing g++ versions in particular, which i do at least.
423 2013-06-29 21:16:40 <BW^-> sipa: for each RPC call, one OS thread is created right?
424 2013-06-29 21:16:46 <sipa> i hope not
425 2013-06-29 21:17:01 <sipa> i think there are just a few rpc handler threads
426 2013-06-29 21:17:15 <sipa> but i haven't touched that code lately
427 2013-06-29 21:18:03 <BW^-> sipa: why would it be a few, i mean, why have more than an idling listener thread, when there is no RPC activity going on?
428 2013-06-29 21:18:32 <gmaxwell> sipa: did you figure out why leveldb was failing for your addrindex stuff?
429 2013-06-29 21:22:05 <sipa> BW^-: starting threads is expensive, waking threads is cheap
430 2013-06-29 21:22:14 <sipa> gmaxwell: no
431 2013-06-29 21:22:49 <sipa> i assume just because of the amount of data being written in one batch
432 2013-06-29 21:24:18 <gmaxwell> ACTION shakes his fist at the suckyness of the universe.
433 2013-06-29 21:27:38 <BW^-> sipa: good point.
434 2013-06-29 21:29:02 <BW^-> gmaxwell: when you said 1.5GB vs 10GB, did you then mean that this is so currently, in order for privkey imports to be possible at all, currently?
435 2013-06-29 21:30:51 <gmaxwell> BW^-: yes, currently. Actually 1.5 GB is an overestimate.
436 2013-06-29 21:31:03 <BW^-> sipa: is there any recollection anywhere of which are bitcoind's totality of global variables? they are listed in the .h files indeed, though it's not obvious if something is to keep state or is a constant etc.
437 2013-06-29 21:31:18 <BW^-> gmaxwell: really, so the blockchain today is less than 1.5GB really - what's the rest for?
438 2013-06-29 21:31:49 <gmaxwell> BW^-: the blockchain is over 8gb now, but a full node doesn't need the blockchain it just needs the utxo set (and some recent blocks)
439 2013-06-29 21:31:50 <BW^-> sipa: ah, so i meant, global variables that keep state :))
440 2013-06-29 21:32:17 <gmaxwell> But you need the full blockchain to import keys.
441 2013-06-29 21:32:21 <BW^-> gmaxwell: ah, and those are what takes less than 1.5GB
442 2013-06-29 21:32:33 <BW^-> aha understood
443 2013-06-29 21:33:47 <gmaxwell> the utxo set itself is about 250 mbytes at the moment.
444 2013-06-29 21:37:14 <phantomcircuit> gmaxwell, well you dont really need them to import keys if you dont need to know about spent outputs
445 2013-06-29 21:38:10 <gmaxwell> god knows what stuff you'll break randomly denying the wallet knoweldge of earlier transactions.
446 2013-06-29 21:39:41 <BW^-> :))
447 2013-06-29 21:39:53 <BW^-> gmaxwell: if you have any clue re which are all the global variables that keep state, i'd be listening :))
448 2013-06-29 21:40:00 <BW^-> that would give a nice overview kind of thing
449 2013-06-29 21:40:39 <BW^-> just anything other than constant values and procedures/methods
450 2013-06-29 21:41:45 <sipa> BW^-: i think i know what most do
451 2013-06-29 21:42:43 <nsh> BW^-, there is no state. bitcoin is written entirely in functional programming style for maximum efficiency
452 2013-06-29 21:42:49 <nsh> :)
453 2013-06-29 21:43:00 <nsh> ACTION tries to imagine a haskell bitcoin node
454 2013-06-29 21:43:08 <nsh> ok, brain hurts now
455 2013-06-29 21:44:09 <sipa> nsh: https://github.com/laanwj/Purecoin
456 2013-06-29 21:44:27 <sipa> questions -> roconnor
457 2013-06-29 21:44:45 <nsh> wonders never cease :)
458 2013-06-29 21:44:50 <nsh> ty
459 2013-06-29 21:45:29 <BW^-> =)
460 2013-06-29 21:45:59 <BW^-> sipa: so like, what are the main global state variables?
461 2013-06-29 21:46:08 <BW^-> so, the thread instances to start with
462 2013-06-29 21:46:15 <sipa> dude
463 2013-06-29 21:46:18 <BW^-> i just ask this as it would provide a great perspective to study from
464 2013-06-29 21:46:25 <BW^-> yeah, it might just be too much and i better just dig into the source
465 2013-06-29 21:46:30 <sipa> that's like an exam question "ok, math. explain briefly"
466 2013-06-29 21:46:39 <BW^-> =))
467 2013-06-29 21:46:44 <gmaxwell> hahahaha
468 2013-06-29 21:48:28 <BW^-> hm. the core ones shouldn't be too many
469 2013-06-29 21:48:48 <BW^-> i guess that would be, the main threads and mutexes, and then the root instance objects used for all the logics
470 2013-06-29 21:49:12 <sipa> hahaha
471 2013-06-29 21:49:40 <sipa> you give satoshi (and those refactoring the code afterwards) way too much credit
472 2013-06-29 21:49:45 <sipa> go sit down
473 2013-06-29 21:49:49 <sipa> have a drink
474 2013-06-29 21:49:51 <sipa> you'll need it
475 2013-06-29 21:49:56 <sipa> now slowly
476 2013-06-29 21:49:58 <sipa> *slowly*
477 2013-06-29 21:50:01 <sipa> open main.cpp
478 2013-06-29 21:50:21 <BW^-> =)
479 2013-06-29 21:50:28 <BW^-> hehe
480 2013-06-29 21:50:45 <BW^-> sipa: are you giving a hint at that there's Way More than that :))
481 2013-06-29 21:51:04 <BW^-> ..then one for the wallet, pwalletMain
482 2013-06-29 21:52:50 <sipa> thankfully that is abstracted out :)
483 2013-06-29 21:52:56 <sipa> (it used to be part of main.cpp too)
484 2013-06-29 21:54:58 <BW^-> : )
485 2013-06-29 22:00:32 <BW^-> is there any algorithm for detecting what fee is required for a transaction to succeed?
486 2013-06-29 22:00:44 <BW^-> what if the fee is too low, could you get any kind of weird situation from this?
487 2013-06-29 22:02:18 <BW^-> hm cool, i'm starting to actually understand something. great.
488 2013-06-29 22:07:36 <nsh> BW^-, drink deep or taste not the Pierian spring...
489 2013-06-29 22:10:33 <CodeShark> BW^-: miners can set their own policies for what to include, relay nodes can set their own policies for what to relay, and wallets can set their own policy for what to send.
490 2013-06-29 22:11:04 <CodeShark> your safest bet is to be at least as strict as the default relay setting for bitcoind
491 2013-06-29 22:12:15 <CodeShark> search for GetMinFee in main.cpp
492 2013-06-29 22:12:25 <BW^-> codeshark: how is it - for your transaction to get registered in the blockchain (and thus the transaction formally happening, and confirmations start ticking and the doublespending becoming impossible), it needs to be registered in the next block that a miner mines, and it's the miner that will determine independently if it accepts your transaction or not, depending on the fee you offer?
493 2013-06-29 22:12:30 <BW^-> codeshark: noted
494 2013-06-29 22:12:30 <zebedee_> Have details of the recent DDOS been made public?
495 2013-06-29 22:12:50 <nsh> hmm?
496 2013-06-29 22:14:12 <zebedee_> I understood a network DDOS was responsible for the release of 0.8.3; wondering if there were details
497 2013-06-29 22:14:36 <CodeShark> BW^-: it is indeed up to the miner to decide whether or not to include your transaction
498 2013-06-29 22:14:56 <CodeShark> they don't have to include your transaction in their next block, though - they could do it several blocks later
499 2013-06-29 22:15:14 <CodeShark> miners prioritize transactions and make blocks accordingly
500 2013-06-29 22:16:33 <BW^-> codeshark: prioritize based on fee offered for instance, so it could happen a transaction would never get committed?
501 2013-06-29 22:16:44 <BW^-> codeshark: is there any reliable way to cancel a pending transaction?
502 2013-06-29 22:17:25 <CodeShark> BW^-: yes to your first question, as to your second - unfortunately, no
503 2013-06-29 22:19:23 <BW^-> codeshark: so the best way to "cancel" such a tx would be to.. send out another one with the same ID but with a higher transaction fee, that sends the funds back to you?
504 2013-06-29 22:19:41 <BW^-> codeshark: and then, to omit doublespending, if the second one would ever be committed, at least it'd be considered invalid?
505 2013-06-29 22:19:59 <CodeShark> yeah, you could do that
506 2013-06-29 22:20:23 <CodeShark> only problem is that as long as other nodes still have a copy of the first one they won't relay the second (at least with the current logic in bitcoind)
507 2013-06-29 22:20:38 <BW^-> ouch.
508 2013-06-29 22:21:09 <BW^-> codeshark: so.. for this to work, you'd need to have magic fingers as to know what node will create the next block, as to send directly to it?
509 2013-06-29 22:21:16 <BW^-> that is too difficult to ever happen indeed.
510 2013-06-29 22:21:35 <CodeShark> very few nodes are actively creating blocks
511 2013-06-29 22:22:05 <CodeShark> you could send the transaction directly to miners/mining pool operators, but it would be better if there were a way to flood updates to the network
512 2013-06-29 22:23:28 <BW^-> mhm
513 2013-06-29 22:23:58 <CodeShark> you can also wait until enough nodes no longer have your tx in their mempool
514 2013-06-29 22:24:04 <CodeShark> and then try flooding the update
515 2013-06-29 22:24:06 <BW^-> the size of a transaction you commit, is influenced by the number of transaction inputs you used, right? so say that someone had the kindness to send you a zillion of 0.0001 BTC transactions -
516 2013-06-29 22:24:33 <CodeShark> number of inputs AND number of outputs
517 2013-06-29 22:24:42 <BW^-> then due to how these make your send of 1BTC take several kilobytes, suddenly your transaction fee will become noticable right?
518 2013-06-29 22:24:47 <BW^-> codeshark: right
519 2013-06-29 22:38:47 <enigmuriatic> it's well-known that there are two txs with the same hash (d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599), right?
520 2013-06-29 22:41:14 <IanCormac> https://bitcointalk.org/index.php?topic=1814.0
521 2013-06-29 22:42:45 <enigmuriatic> thanks
522 2013-06-29 22:42:49 <IanCormac> np
523 2013-06-29 22:42:55 <IanCormac> Basically, a miner fucked up
524 2013-06-29 22:45:18 <nsh> (that's the cover-story. actually ECDSA is broken and the sky is falling on our heads)
525 2013-06-29 23:00:31 <jaekwon> is there a reason why C++ adopts pass-by-reference as opposed to forcing pass-by-pointer? seems like pass-by-reference removes the need for an ampersand when calling, but makes the code harder to read
526 2013-06-29 23:01:11 <jaekwon> cuz you always have to check the method signature to see whether your variable is going to change
527 2013-06-29 23:01:50 <IanCormac> I makes the code cleaner, I guess
528 2013-06-29 23:02:53 <IanCormac> Because you're not going to pass objects by value (i.e. copy them), so there would be a lot of ugly stars and ampersands
529 2013-06-29 23:03:00 <HM2> references aren't addressable themselves
530 2013-06-29 23:03:06 <IanCormac> but you raise a good point
531 2013-06-29 23:03:07 <HM2> &ptr is the address of the pointer
532 2013-06-29 23:03:16 <HM2> &reference is the address of the referenced object
533 2013-06-29 23:03:30 <IanCormac> we know
534 2013-06-29 23:10:47 <HM2> C++ adopts references primarily for operator overloading
535 2013-06-29 23:12:01 <HM2> because putting aside the above and immutable binding or whatever you call it, using pointers for operator overloading would be inconsistent
536 2013-06-29 23:12:33 <HM2> some operators return one of their arguments
537 2013-06-29 23:13:08 <HM2> (by reference)
538 2013-06-29 23:13:59 <HM2> operator+(Foo*, Foo*) would mean you couldn't have an operator overload for both Foo's and Foo*'s
539 2013-06-29 23:14:49 <jaekwon> (i'm brushing up on my C++ to learn the bitcoind source) Also, without pass-by-reference, you'd *always* have to pass by pointer to prevent a copy construction
540 2013-06-29 23:14:55 <HM2> it's also handy not to have a null so you can do throwing dynamic_casts
541 2013-06-29 23:15:28 <HM2> you also ditch the pesky void*
542 2013-06-29 23:19:55 <HM2> jaekwon, what code are you looking at where non-const references are passed?
543 2013-06-29 23:30:43 <jaekwon> HM2: oh, er, just a call to boost. in allocators.h:
544 2013-06-29 23:30:46 <jaekwon> boost::mutex::scoped_lock lock(mutex);
545 2013-06-29 23:31:11 <BW^-> the TBD decentralized voting system, which is that?
546 2013-06-29 23:31:16 <jaekwon> actually i'm not sure what that line is doing. i figured mutex is a non-const reference.
547 2013-06-29 23:32:30 <HM2> jaekwon, yeah it's just a RAII wrapper for obtaining locks
548 2013-06-29 23:32:53 <HM2> it calls mutex.lock() on construction and mutex.unlock() on destruction
549 2013-06-29 23:33:09 <HM2> that way if your code throws an exception you don't leak the lock
550 2013-06-29 23:34:04 <jaekwon> ok, so "lock" there is just the variable name in a constructor for type "scoped_lock"?
551 2013-06-29 23:34:29 <HM2> yep
552 2013-06-29 23:34:40 <jaekwon> and separate matter, as you asking me about non-const references in the code because they are to be avoided?
553 2013-06-29 23:34:44 <jaekwon> (thanks!)
554 2013-06-29 23:35:45 <HM2> not necessarily avoided
555 2013-06-29 23:36:50 <IanCormac> They're just as dangerous as passing pointers
556 2013-06-29 23:36:59 <IanCormac> So they're useful, but not always a good idea
557 2013-06-29 23:38:46 <HM2> I find most of my new C++ code these days uses smart pointers almost exclusively, references for operator overloads and template
558 2013-06-29 23:38:51 <HM2> templated coded
559 2013-06-29 23:39:04 <HM2> code*. good grief
560 2013-06-29 23:39:27 <HM2> I should be up at this hour ;)
561 2013-06-29 23:39:57 <BW^-> how much would an index take, that checks the "balance" of every bitcoin address/transactions ?
562 2013-06-29 23:40:06 <BW^-> how much space would such an index take
563 2013-06-29 23:40:47 <BW^-> or.. indeed, just knowing what transactions were made on them, may be enough
564 2013-06-29 23:41:27 <BW^-> sipa: with your addrindex , import of a private key is clearly fast, is it not?
565 2013-06-29 23:52:07 <xenland> BW^ the balance depends on the amount of the complexity of the transaction history
566 2013-06-29 23:52:40 <xenland> if there was 11 btc that has never moved except its generation probubly 1 second if however microbits have been sent to make those 11 btc then it may take a while to do verifications.
567 2013-06-29 23:52:52 <xenland> for every address, it would be a constant speed
568 2013-06-29 23:53:04 <xenland> but would take longer as time went on or more precisly the blockchain gained size.
569 2013-06-29 23:53:08 <xenland> .
570 2013-06-29 23:53:13 <BW^-> xenland: hm
571 2013-06-29 23:53:21 <xenland> sorry i put the balance depends on
572 2013-06-29 23:53:23 <xenland> i ment
573 2013-06-29 23:53:24 <BW^-> xenland: with default bitcoind, a whole-blockchain scan is needed, right?
574 2013-06-29 23:53:25 <xenland> the balance checking speed
575 2013-06-29 23:53:39 <BW^-> xenland: with this https://github.com/sipa/bitcoin/tree/addrindex , there's an index of all transactions made, per public address -
576 2013-06-29 23:53:40 <xenland> Umm i think with bitcoind yes
577 2013-06-29 23:54:00 <BW^-> xenland: so just looking them up and summing up incoming - outgoing should give you the present balance??
578 2013-06-29 23:54:15 <xenland> I don't understand
579 2013-06-29 23:54:17 <BW^-> xenland: "with bitcoind yes", you meant that you are of the same understanding
580 2013-06-29 23:54:39 <xenland> Why not just look at the blockchain instead of a static github listing?
581 2013-06-29 23:55:00 <xenland> Oh i must go i'll be back in some hours
582 2013-06-29 23:55:05 <BW^-> xenland: ah - my question is, how determine the current balance in a *faster* way than by reading all the blockchain
583 2013-06-29 23:55:16 <BW^-> xenland: ah - ok - i'll be offline then.
584 2013-06-29 23:55:23 <BW^-> very well, l8r.
585 2013-06-29 23:56:26 <xenland> BW^: Um faster could be perhaps you could precompute the blockchain into a precomputed "database" but you couldn't rely on that database when trading (UNLESS you were constnatly recomputing it/appending the recomputations)
586 2013-06-29 23:56:28 <xenland> cheers :D
587 2013-06-29 23:57:07 <BW^-> :)
588 2013-06-29 23:57:24 <BW^-> xenland: yeah, and what if there'd ever be a chain split
589 2013-06-29 23:57:36 <BW^-> i mean, tha twon't happen, though to be algorithmically complete there'd need to be handling of that