1 2013-04-25 00:05:12 <gmaxwell> BlueMatt: you could hop in #tor-dev and help them out if you like. They seemed to be having some problems making firefox builds determinstic.
2 2013-04-25 00:05:51 <BlueMatt> gmaxwell: oh gawd, Im sure they are...I'd love to, though I have an exam tomorrow morning :(
3 2013-04-25 00:06:18 <BlueMatt> gmaxwell: ehh, there is one person there
4 2013-04-25 00:07:07 <saracen> bah, the mention of "exam". You've broken my concentration on procrastination :(
5 2013-04-25 00:07:11 <BlueMatt> ahh, oftc
6 2013-04-25 00:08:09 <BlueMatt> you're welcome :)
7 2013-04-25 00:12:28 <etotheipi_> sipa: how much trouble did you have getting leveldb working on windows?
8 2013-04-25 00:19:59 <saivann> BlueMatt : The website is not updated correctly anymore. The github API returns "403 Forbidden" and causes FTBFS only on the dedicated server, most probably because we spam them since we don't use their webhook thing anymore.
9 2013-04-25 00:20:21 <jspilman> interesting blog post from the guys behind Convergence pretty negative (I guess not surprisingly) on DNSSEC: http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
10 2013-04-25 00:20:38 <saivann> BlueMatt : I can contact github to ask them to remove us of their blacklist, and adapt the script to only build with jekyll if it detects a new commit. What do you think of that?
11 2013-04-25 00:22:20 <BlueMatt> saivann: ask tcatm? I dunno much about how that vm actually works, I just run the vm host
12 2013-04-25 00:22:31 <jspilman> if their concerns are valid, does (eventual) DNSSEC support in Payment Protocol really solving anything?
13 2013-04-25 00:22:34 <saivann> BlueMatt : Ok
14 2013-04-25 00:22:51 <saivann> tcatm : ping
15 2013-04-25 00:32:44 <saivann> tcatm : I will be away, but I contacted github. Most probably that we'll be able to know if any change in the script is required from their answer.
16 2013-04-25 00:33:36 <BlueMatt> I know there is an automatic limit for api calls per time, though
17 2013-04-25 00:33:49 <BlueMatt> I was under the impression the thing polled every 15 minutes or something, though?
18 2013-04-25 00:33:57 <BlueMatt> (isnt that what we guessed from vm cpu usage?)
19 2013-04-25 00:33:59 <BlueMatt> or was it 5?
20 2013-04-25 00:34:27 <BlueMatt> saivann: ^
21 2013-04-25 00:34:51 <saivann> BlueMatt : 15 minutes, and it worked for a long time. It stopped working only today
22 2013-04-25 00:35:07 <BlueMatt> strange...whatever Ill let you do it then
23 2013-04-25 00:35:30 <lianj> polling? why not using their webhook feature?
24 2013-04-25 00:35:37 <saivann> My last commit is 11 hours ago.. so it seems like we are not temporarily banned
25 2013-04-25 00:36:05 <BlueMatt> lianj: because...lazy?
26 2013-04-25 00:36:15 <saivann> lianj : I think they were using it before, but it stopped working properly right before the chain fork event
27 2013-04-25 00:36:49 <lianj> saivann: they changed their allowed ips, other than that it works pretty stable. at least for me
28 2013-04-25 00:37:33 <saivann> lianj : I don't have access to this anyway as I only have pull access to the repository, no admin access
29 2013-04-25 00:37:59 <lianj> ah ok
30 2013-04-25 00:38:14 <saivann> But I remember someone saying there "github screwed their APIs.."
31 2013-04-25 00:39:05 <lianj> not really, the webhooks still work fine, you just have to fetch their allowed src ips from https://api.github.com/meta now. but anyhow???
32 2013-04-25 00:40:27 <saivann> lianj : In any case, that sounds less hackish to work with their API. But I let tcatm looking into this. Meanwhile, perhaps github will un-blacklist us.
33 2013-04-25 00:40:52 <lianj> they blocked you from doing too much git fetch ?
34 2013-04-25 00:41:30 <saivann> lianj : in /var/log/syslog, we have a bunch of 403 forbidden errors from github
35 2013-04-25 00:41:41 <saivann> jekyll fails to build due to this
36 2013-04-25 00:41:59 <lianj> aw
37 2013-04-25 00:42:16 <saivann> We call this API to create the contributors list : https://api.github.com/repos/bitcoin/bitcoin/contributors
38 2013-04-25 00:42:24 <saivann> That is the one that is not working anymore
39 2013-04-25 00:43:00 <saivann> (git clone still works fine)
40 2013-04-25 00:43:42 <lianj> maybe just do `git shortlog -s -n` instead
41 2013-04-25 00:47:03 <saivann> lianj : The contributors list is for the bitcoin-qt project, so we can't extract contributors from the git log of the bitcoin.org website
42 2013-04-25 00:47:44 <lianj> ah, makes sense
43 2013-04-25 00:47:49 <saivann> Otherwise it would have been nice :-)
44 2013-04-25 00:50:23 <Luke-Jr> ACTION lightly pushes to include all bitcoin projects in the list
45 2013-04-25 00:51:40 <petertodd> yes, that list has some weird effects, like how relatively highly ranked I am on it compared to other much more deserving people
46 2013-04-25 00:51:57 <petertodd> or even people listed as core developers...
47 2013-04-25 00:52:02 <BlueMatt> ACTION isnt sure that list belongs there
48 2013-04-25 00:52:57 <petertodd> well, I like the core dev list for a lot of reasons, including it makes it easy to figure out who to contact about a security hole
49 2013-04-25 00:53:08 <Luke-Jr> petertodd: there is a security mailing list
50 2013-04-25 00:53:15 <BlueMatt> the whole development tab is very satoshi-centric, which seems out of place on the new site
51 2013-04-25 00:53:21 <petertodd> yes, but that's not obvious to an outsider
52 2013-04-25 00:53:33 <Luke-Jr> perhaps that should be addressed.
53 2013-04-25 00:53:46 <petertodd> explicit instructions on responsible disclosure could be nice
54 2013-04-25 00:54:01 <petertodd> gavin mentioned it with my nLockTime thing a few months back
55 2013-04-25 00:54:49 <BlueMatt> ACTION votes for retitling "Developers" to "Bitcoin-Qt Developers" or equivalent
56 2013-04-25 00:55:24 <petertodd> oh, actually, I vote for s/Developers/Core Developers/ - it's the most obvious thing to do
57 2013-04-25 00:55:28 <saivann> Aren't we always saying "Core developers"?
58 2013-04-25 00:55:31 <BlueMatt> that works
59 2013-04-25 00:55:34 <BlueMatt> go for it
60 2013-04-25 00:55:39 <saivann> Will do
61 2013-04-25 00:55:51 <BlueMatt> same with Contributors, probably
62 2013-04-25 00:56:16 <saivann> Core contributors?
63 2013-04-25 00:56:50 <petertodd> no, that I would say 'Bitcoin-QT contributors'
64 2013-04-25 00:56:53 <BlueMatt> or Bitcoin-Qt contributors
65 2013-04-25 00:57:06 <petertodd> I see 'Core Developers' implying some amount of authority on the overall direction of bitcoin
66 2013-04-25 00:57:56 <BlueMatt> ack
67 2013-04-25 00:58:06 <Luke-Jr> seems nobody knows what "Core developers" means these days
68 2013-04-25 00:58:08 <saivann> Noted
69 2013-04-25 00:58:11 <saracen> Regarding the API link not working, the ban should only be temporary no, like, a day?
70 2013-04-25 00:58:13 <saivann> Indeed
71 2013-04-25 00:58:30 <BlueMatt> Luke-Jr: just what petertodd said
72 2013-04-25 00:58:38 <Luke-Jr> ACTION votes nix the whole manual-names list and just order commit authors to all bitcoin projects
73 2013-04-25 00:58:52 <saivann> saracen : I've been banned temporarily some times when I was aggressively working on the website. But these were 5 minutes ban. Presently, we are banned since 11 hours.
74 2013-04-25 00:59:17 <petertodd> But that's weird too - look at my commits, a bunch of one line documentation changes, and then some really fundemental one line changes, that get rejected. :P
75 2013-04-25 00:59:47 <petertodd> I think the consensus on the current 'core dev' list is fine, although, who the !@#$ is Nils...
76 2013-04-25 00:59:58 <Luke-Jr> tcatm
77 2013-04-25 00:59:59 <BlueMatt> tcatm is nils
78 2013-04-25 01:00:13 <BlueMatt> not that he does much coding anymore...
79 2013-04-25 01:00:31 <saivann> The contributors plugin is actually made by tcatm and I'm not so got with ruby.. So I can try to change something if required, but I might lose a lot of time on this.
80 2013-04-25 01:00:40 <petertodd> ah, see the irc/github nickname/real name thing is confusing
81 2013-04-25 01:00:46 <BlueMatt> meh, probably not worth it
82 2013-04-25 01:01:00 <saivann> s/so got/so good/
83 2013-04-25 01:01:02 <BlueMatt> and if you start, Id bet it will be bikeshedded into oblivion ;)
84 2013-04-25 01:01:07 <Luke-Jr> I think I had a script to count commits globally..
85 2013-04-25 01:01:24 <BlueMatt> and the discussion of which projects to include/not would be......ugly
86 2013-04-25 01:01:39 <Luke-Jr> BlueMatt: why exclude any? as long as we're just listing people, meh
87 2013-04-25 01:01:58 <saivann> Indeed, the real point I think is to show "Hay, a lot of contributors". And that is nice looking.
88 2013-04-25 01:05:07 <Luke-Jr> oh, my script was actually counting active lines of code
89 2013-04-25 01:05:15 <Luke-Jr> and doesn't work with latest git :/
90 2013-04-25 01:05:27 <petertodd> and lines of code doesn't help much anyway
91 2013-04-25 01:06:04 <BlueMatt> if you are adding a shitton of repos, just list people, no counts, ordered by name/username/random
92 2013-04-25 01:15:02 <gmaxwell> petertodd: who _else_ is actively working on the system? It seems a bit honest to sort of imply these people aren't.
93 2013-04-25 01:16:42 <petertodd> gmaxwell: Indeed. In fact, a good test would be to ask if they are contributing more to Bitcoin core development than me, and because I don't think of myself as a core developer, leave them off the list...
94 2013-04-25 01:17:13 <petertodd> All you have to do is watch IRC and it's pretty clear that the 'core dev' list is accurate
95 2013-04-25 01:17:49 <saivann> BlueMatt : Uh, how do you type characters that requires to use the ALT key in your VM console?
96 2013-04-25 01:17:56 <petertodd> The only person who I might add to that list is Mike really - bloom filters/leveldb
97 2013-04-25 01:18:05 <gmaxwell> saivann: yea, the point of the big list is "lots of people involved" ... if github isn't working we can get similar data from ohloh instead, https://www.ohloh.net/p/bitcoin/contributors?sort=latest_commit&time_span=12+months though their counting is a bit wonker that github's I think.
98 2013-04-25 01:18:39 <BlueMatt> saivann: there should be a button with all the fancy cntl-alt-f1, cntl-alt-del combos, alt should work as-is other than that
99 2013-04-25 01:19:10 <gmaxwell> petertodd: the leveldb code we have was not written by Mike, not that it matters, just obpedantry
100 2013-04-25 01:19:15 <saivann> gmaxwell : github just answered me that they now requires us to send a user-agent header. So I'm going to try first
101 2013-04-25 01:19:44 <saivann> BlueMatt : I actually requires to type a punctuation mark
102 2013-04-25 01:20:19 <saivann> And typing ALT produces characters on the screen, trying to use the arrows on the keyboard does the same
103 2013-04-25 01:20:31 <petertodd> gmaxwell: Ah, still. Anyway, no particular reason to change it. Like I said about security, I think the most useful part of having the core-dev list is knowing who can probably be trusted.
104 2013-04-25 01:20:58 <BlueMatt> saivann: honestly, I have no idea, I usually avoid the vm console like the plague and get ssh setup first-thing...
105 2013-04-25 01:21:03 <petertodd> gmaxwell: The process for coming to consensus on patches is pretty good right now - if in part because it's slow.
106 2013-04-25 01:21:06 <BlueMatt> (but thats also because openjdk is broken)
107 2013-04-25 01:21:13 <saivann> BlueMatt: :)
108 2013-04-25 01:21:18 <saivann> Yes it lags a lot..
109 2013-04-25 01:21:42 <BlueMatt> ACTION -> early sleep for early exams :P
110 2013-04-25 01:21:52 <gmaxwell> petertodd: our review levels are inadequate.
111 2013-04-25 01:22:19 <petertodd> gmaxwell: sure, but that's a manpower, not process issue
112 2013-04-25 01:22:43 <gmaxwell> I agree the process basically works.
113 2013-04-25 01:23:34 <petertodd> It's not easy to get up to speed - I've been a hanger-on seriously for about a year and a half now, and I can't effectively review anything outside of the core blockchain rules really.
114 2013-04-25 01:24:03 <gmaxwell> I'm not quite sure how inadequate review is, because we do objectively find some serious bugs in review, and I think much of what we know we missed wouldn't be found by simply doubling the review.
115 2013-04-25 01:24:24 <gmaxwell> But I have a pretty strong impression that we're no better than right at the edge of adequacy.
116 2013-04-25 01:24:34 <petertodd> On the other hand, think of how little has actually changed.
117 2013-04-25 01:25:44 <gmaxwell> or another point: I don't think our process works very well for large patches.
118 2013-04-25 01:26:19 <Luke-Jr> or vice-versa..
119 2013-04-25 01:26:28 <Luke-Jr> large patches are hard to review period, best avoid them
120 2013-04-25 01:27:11 <petertodd> We've got a bunch of them in the pipeline that are important. re-thinking mempool behavior, re-thinking the wallet, separating core and wallet...
121 2013-04-25 01:27:21 <petertodd> Let alone more speculative stuff
122 2013-04-25 01:27:50 <gmaxwell> the wallet changes are at least partially breakable.. but yea, I was specifically thinking of the mempool behavior resulting in big hard to review attack exposed network behavior critical changes.
123 2013-04-25 01:28:05 <gmaxwell> Some of it is a bit hard to test too.
124 2013-04-25 01:28:33 <petertodd> FWIW my attempt at it is including at least some unittests, but equally I doubt it's going to lead to something mergable soon if ever
125 2013-04-25 01:28:40 <gmaxwell> E.g. our coin selection tests mostly check to make sure you haven't changed the coin selection behavior, and mostly only test a very small set of toy cases.
126 2013-04-25 01:29:18 <petertodd> We don't have good failsafes in the code too to check that fees are sane and txouts are going to sane places
127 2013-04-25 01:29:59 <gmaxwell> perhaps that would make some of this easier to change.
128 2013-04-25 01:30:13 <petertodd> true
129 2013-04-25 01:30:23 <gmaxwell> I know thats why I've not made pull requests on things like dust sweeping. Changing that code gives me hives.
130 2013-04-25 01:30:42 <petertodd> indeed
131 2013-04-25 01:30:59 <petertodd> we *know* people use bitcoin-qt for txouts worth millions
132 2013-04-25 01:31:11 <wamatt> unittests are a great idea imo
133 2013-04-25 01:31:30 <gmaxwell> We have unit tests.
134 2013-04-25 01:31:48 <gmaxwell> That doesn't mean that they're all that good or complete or whatever.
135 2013-04-25 01:31:48 <lianj> yep, i like how bitcoind started trying to enforce testing over time. great job!
136 2013-04-25 01:42:43 <wamatt> gmaxwell: cool. what framework do you use for testing?
137 2013-04-25 01:48:41 <Luke-Jr> wamatt: boost
138 2013-04-25 01:48:53 <saivann> ... I highly recommand having SSH access to the jekyll console (or never shutdown the console).. I needed to simulate my keyboard with xdotool in order to login
139 2013-04-25 01:50:28 <wamatt> ta luke. i want to play around with the code. does it matter if i pull it from SF or GH?
140 2013-04-25 01:50:58 <Luke-Jr> wamatt: SF is no longer used except for releases
141 2013-04-25 01:51:40 <wamatt> k, sometimes project do repo mirroring so wanted to check first
142 2013-04-25 01:51:43 <wamatt> projects
143 2013-04-25 01:52:07 <wamatt> if i had a bitcoin for evey typo i mke ???. :D
144 2013-04-25 01:53:27 <richcollins> anyone know what's up with https://en.bitcoin.it/wiki/ ?
145 2013-04-25 01:58:43 <Belxjander> richcollins: no idea... maybe the DDoS freaks are just trying to hammer everything?
146 2013-04-25 01:58:59 <richcollins> trying to read bitcoin-d docs
147 2013-04-25 04:11:32 <saivann> tcatm : The website problem has been fixed. It was indeed the github API now requiring a User-Agent header that ruby 1.8 didn't generate automatically.
148 2013-04-25 04:17:18 <tcatm> saivann: what was the Problem?
149 2013-04-25 04:18:05 <saivann> tcatm : The website was not updating anymore because the contributors.rb plugin always got a 403 error from github.
150 2013-04-25 04:26:14 <dino__> \t Does anybody know of a Python library to talk to bitcoind?
151 2013-04-25 04:27:33 <amiller> dino__, use pynode and python-bitcoinlib
152 2013-04-25 04:27:44 <dino__> amiller, Thanks!
153 2013-04-25 04:28:07 <dino__> Also found bitcoin-python is that any good?
154 2013-04-25 04:32:26 <amiller> dino__, hm, i think bitcoin-python is probably a better choice and way simpler
155 2013-04-25 04:32:53 <dino__> amiller - thanks. It looks like it will do what I want.
156 2013-04-25 04:33:06 <dino__> Need to send a transaction, then monitor wallet for any incoming transactions.
157 2013-04-25 04:33:15 <dino__> Should be trivial with that library
158 2013-04-25 04:33:49 <amiller> hm
159 2013-04-25 04:34:02 <amiller> does the bitcoinrpc protocol let me longpoll and just wait for notifications that way
160 2013-04-25 04:36:29 <dino__> Not sure. May just have to query wallet every 30 seconds and check for new transactions. Its a pain, but would work
161 2013-04-25 05:18:42 <coingenuity> sipa: non-canonical encodings?
162 2013-04-25 06:03:50 <sipa> coingenuity: see my mail to the mailinglist about that
163 2013-04-25 06:04:29 <coingenuity> have a link handy, by chance?
164 2013-04-25 06:11:28 <Lolcust> Hello! sipa - a small (possibly not very smart) question regarding your Ultraprune : if one uses it, has coins database, and retains only block headers and (for sheer paranoia) a few thousands "terminal" blocks (just to accomodate reorgs and whatnot, I s'pose), one should be for all practical intents as secure as if he was a "real full node" ?
165 2013-04-25 06:15:11 <sipa> etotheipi_: quite some work, but it works now
166 2013-04-25 06:17:20 <kronicd_> sipa: just read up on ultraprune, it is now in the client by default?
167 2013-04-25 06:17:24 <kronicd_> well bitcoind anyhow
168 2013-04-25 06:19:04 <gmaxwell> Lolcust: you're confused, it doesn't prune anything.
169 2013-04-25 06:19:26 <sipa> kronicd_: i've stopped using that name as it does not prune
170 2013-04-25 06:19:30 <kronicd_> ah
171 2013-04-25 06:19:42 <gmaxwell> Lolcust: its behaviorally indistinguishable from the older software except for being much faster.
172 2013-04-25 06:20:01 <Lolcust> gmaxwell , I am aware that block pruning is not implemented
173 2013-04-25 06:20:06 <sipa> what ut does, is use a pruned _copy_ for almost all operations, so it is faster
174 2013-04-25 06:20:13 <kronicd_> are you aware of any branches/ports/efforts that do prune? I'm working on some applications where the 8GB blockchain is a significant hurdle
175 2013-04-25 06:20:26 <gmaxwell> kronicd_: why are you not using a SPV node?
176 2013-04-25 06:20:26 <Lolcust> But IIRC sipa mentioned that it can be implemented (in the relevant git) hence my question
177 2013-04-25 06:20:40 <sipa> it can indeed easily be implemented
178 2013-04-25 06:20:51 <kronicd_> gmaxwell: can SPV nodes still mine?
179 2013-04-25 06:20:58 <kronicd_> I was under the impression they could not
180 2013-04-25 06:21:42 <gmaxwell> kronicd_: uh, can you elaborate on what your application is for controlling mining from a node that can't take 8gb storage?
181 2013-04-25 06:21:57 <Lolcust> well, hence my question - if it were implemented, but in a manner that retains the header and a few thousands most recent blocks (which makes sense - there may be a legitimate reorg after all ), would that be as "good" as "vanilla blockchain retention" ?
182 2013-04-25 06:22:03 <gmaxwell> Eventually the coins database will be that big??? thats an awful tight constraint.
183 2013-04-25 06:22:19 <kronicd_> gmaxwell: I've got some boxes with 5 GPUs each, quite nice. I'm adding some more and dont want to add hard disks :P
184 2013-04-25 06:22:32 <kronicd_> wanting to run off onboard flash, ideally a UEFI module
185 2013-04-25 06:22:36 <gmaxwell> Lolcust: if you are unable to handle a reorg of size X and one of size X happens then your network will fragment and never converge again.
186 2013-04-25 06:23:04 <sipa> but this hasn't happened because of some roadblocks (how to make sure new nodes still can find those that do have the historical chain still)
187 2013-04-25 06:23:09 <Lolcust> well, we can reasonably assume that a reorg say 2000 blocks deep is not something that is supposed to happen naturally, gmaxwell
188 2013-04-25 06:23:19 <gmaxwell> kronicd_: mining is not normally run on the same system running bitcoind. You generally have one copy of bitcoind that support some large number of systems.
189 2013-04-25 06:23:31 <Lolcust> hey, you know what
190 2013-04-25 06:23:42 <sipa> Lolcust: you need to store block index, utxo set, and recent blocks and undo data
191 2013-04-25 06:23:52 <sipa> Lolcust: the utxo set also grows
192 2013-04-25 06:24:05 <kronicd_> gmaxwell: I am aware, but I don't mind riding averages and I can't always guarentee they'll be able to connect to eachother.. I'm starting to realise this sounds increidbly dodgy
193 2013-04-25 06:24:09 <kronicd_> it isnt though :P
194 2013-04-25 06:24:15 <Lolcust> sipa well, it grows - but it is probably smaller than "entire chain, from the beginning of history".
195 2013-04-25 06:24:24 <sipa> absolutely
196 2013-04-25 06:24:44 <Lolcust> Also, there are hardcoded checkpoints right ? you can retain full blocks up to most recent hardcoded checkpoint
197 2013-04-25 06:24:47 <gmaxwell> kronicd_: then have them connect to some remote pool??? if they can't connect to the network then they can't mine in any case.
198 2013-04-25 06:24:56 <Lolcust> and skeletonize the rest down to headers
199 2013-04-25 06:25:24 <kronicd_> gmaxwell: fair call, I guess the question I was mainly looking at was "is there a way to reduce blockchain size on a bitcoind and still mine" I'm guessing the answer is "not really" at the moment
200 2013-04-25 06:25:34 <sipa> Lolcust: there is no skeletonization... you need all block headers and the utxo set
201 2013-04-25 06:26:09 <sipa> Lolcust: apart from that, you need full blocks for reorganisation, rescanning wallets or serving to other nodes
202 2013-04-25 06:26:11 <gmaxwell> kronicd_: the answer is to use a remote pool, and otherwise no.
203 2013-04-25 06:26:26 <kronicd_> understood
204 2013-04-25 06:26:53 <sipa> coingenuity: eh let's see
205 2013-04-25 06:27:19 <coingenuity> appreciate it sipa
206 2013-04-25 06:27:27 <coingenuity> rebuilding my tx systems again
207 2013-04-25 06:27:31 <Lolcust> "skeletonization" as "if block pruning is implemented, (and relevant option is set), don't store full blocks "below" most recent lock-in". That would prevent block pruning from accidentally messing with legitimate reorgs, since well, you can't reorg away a hardcoded checkpoint
208 2013-04-25 06:27:43 <Lolcust> rescanning for wallets might be a problem tho
209 2013-04-25 06:27:59 <kronicd_> I'm going to look into it a bit more, mainly because I can't understand (at this point) why one couldn't mine with the last few hundred blocks + a list of unspent outputs
210 2013-04-25 06:28:11 <kronicd_> I'm sure there is a good reason that is beyond my understanding at the moment though
211 2013-04-25 06:28:49 <sipa> Lolcust: i hope we can drop checkpoints at some point
212 2013-04-25 06:28:54 <gmaxwell> kronicd_: because software hasn't been written for that.
213 2013-04-25 06:29:04 <sipa> coingenuity: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01965.html
214 2013-04-25 06:29:15 <coingenuity> sipa: thanks very much!
215 2013-04-25 06:29:24 <sipa> coingenuity: last mail in the thread gives the exact new rules
216 2013-04-25 06:29:46 <kronicd_> gmaxwell: thats fine, I can code and am willing to play with it. I was talking about technical reasons why it couldn't work, rather than that it hasn't been done
217 2013-04-25 06:30:12 <coingenuity> perfect, i will give it a good read
218 2013-04-25 06:30:19 <coingenuity> thanks much :D
219 2013-04-25 06:30:36 <sipa> Lolcust: what i mean is: it's not that if you prune a block, you retain some reduced form of it
220 2013-04-25 06:30:43 <gmaxwell> kronicd_: the software is written now to make it possible, prior to 0.8 it was deeply impossible because of how the validation was performed.
221 2013-04-25 06:31:26 <sipa> Lolcust: the reducdd parts (headers and utxos) are always maintained separately
222 2013-04-25 06:31:34 <gmaxwell> kronicd_: but basically no one but skechy computer use theieves normally cares about non-pooled mining or at least is unable to run their own mining server....
223 2013-04-25 06:31:46 <Lolcust> Well, I kinda understood that you still keep headers
224 2013-04-25 06:32:02 <sipa> Lolcust: sure
225 2013-04-25 06:32:07 <Lolcust> I thought utxo though are something you have to "read out" of the full chain and put in a separate DB
226 2013-04-25 06:32:38 <sipa> i mean... when you prune, you don't store anything that you wouldn't if you had the full block
227 2013-04-25 06:33:17 <sipa> utxo and undo data is built when you process/verify/connect the chain
228 2013-04-25 06:33:19 <kronicd_> gmaxwell: tbqh regular pooled mining makes me uncomfortable (there are an alarmingly low number of nodes publishing blocks), and I'm looking towards the future in terms of disk usage. I do understand what you're saying and why the dodgy fellows would want something similar. I'm sure those guys just use bitcoind's hosted out of romania or something though
229 2013-04-25 06:33:20 <Lolcust> So the process of using a "skeletonized" client would be "startup -> get full chain -> build utxo / update wallet / etc. -> prune blocks to depth "X" while retaining their headers
230 2013-04-25 06:33:51 <sipa> just delete old blocks on the fly
231 2013-04-25 06:33:53 <kronicd_> business mode criminals are much more likely to go with efficient quick solutions than try to dev something to solve an already solved issue
232 2013-04-25 06:34:06 <Lolcust> sipa: ah, indeed. makes sense
233 2013-04-25 06:34:14 <sipa> Lolcust: as i said, you always store the headers, whether you prune or no
234 2013-04-25 06:34:22 <gmaxwell> kronicd_: if you can't take 8gb then you won't be able to mine in the future even with dropping the historical data.
235 2013-04-25 06:34:39 <sipa> and you always maintain the unspent outputs, whether you prune or not
236 2013-04-25 06:34:49 <kronicd_> gmaxwell: that is a damn good point.
237 2013-04-25 06:35:52 <Lolcust> sipa yeah, that I understand. I just wondered whether prunning blocks to a given depth X would have any risks beyond not being able to handle reorgs of X+1 and not being able to feed other nodes blocks at below X
238 2013-04-25 06:36:36 <Lolcust> kronicd_ pardon my... Ignorance, I guess... but what prevents you from just pointing your machinery at a pool ?
239 2013-04-25 06:37:10 <sipa> Lolcust: rescanning
240 2013-04-25 06:37:11 <gmaxwell> No thats it, thats the only distinction. Though those both have considerable implications. e.g. if too many nodes do it you won't be able to bootstrap a new node easily.
241 2013-04-25 06:37:17 <gmaxwell> oh damn, stupid wallets.
242 2013-04-25 06:37:21 <kronicd_> Lolcust: For large pools... I don't like pools, due to the low number of hosts actually pushing blocks
243 2013-04-25 06:37:31 <gmaxwell> ACTION puts brown paper bag on his head
244 2013-04-25 06:37:33 <kronicd_> for this purpose, I could run a single bitcoind, I was just exploring other options
245 2013-04-25 06:37:38 <gmaxwell> kronicd_: "pushing blocks"?
246 2013-04-25 06:37:56 <kronicd_> gmaxwell: eh wrong usage of the lingo I guess. publishing blocks? :P
247 2013-04-25 06:38:13 <Lolcust> sipa ah, indeed. if wallet gets borked I'll need the full chain
248 2013-04-25 06:38:19 <gmaxwell> I'm certantly in favor of fewer large pools??? but p2pool is the sort of canonical answer there, though it doesn't address your unusual constraints.
249 2013-04-25 06:38:31 <sipa> Lolcust: that's why i loke the spv model for wallets
250 2013-04-25 06:39:10 <sipa> Lolcust: especially with bloom filtering, it may actually be cheaper to have your wallet separately than built into the full nodr
251 2013-04-25 06:39:11 <kronicd_> gmaxwell: I'm not overly worried about addressing anything. I'm just fiddling with it looking for solutions, they mine pointing at a bitcoind at the moment
252 2013-04-25 06:39:21 <Lolcust> sipa could you link ? I was out of the coinloop for quite a while ?
253 2013-04-25 06:39:35 <sipa> Lolcust: bip37
254 2013-04-25 06:39:42 <kronicd_> I've already learnt way more about bitcoin than I knew before by modifying the client and I'm still learning more
255 2013-04-25 06:39:45 <kronicd_> its a good outcome.
256 2013-04-25 06:40:26 <sipa> kronicd_: to answer your question: technically it is possible to have a pruning miner node, which retains headers, utxo and recent blocks/undo data only
257 2013-04-25 06:42:09 <kronicd_> sipa: thanks, I couldnt figure out why that wouldnt be the case
258 2013-04-25 06:42:55 <gmaxwell> I answered that above. :( < gmaxwell> kronicd_: the software is written now to make it possible,
259 2013-04-25 06:43:06 <sipa> i missed that
260 2013-04-25 06:43:13 <gmaxwell> apparently kronicd_ did too! :)
261 2013-04-25 06:43:17 <gmaxwell> it's all good.
262 2013-04-25 06:43:27 <kronicd_> I rmemeber reading it now, kinda just flew by though :P
263 2013-04-25 06:44:05 <gmaxwell> I still don't know what you're doing to do when the utxo + headers + recent blocks is bigger than your storage that can't take 8gb (really?!) :)
264 2013-04-25 06:44:27 <Graet> buy a 64gb usb stick?
265 2013-04-25 06:44:29 <kronicd_> that's future kronicd's problem
266 2013-04-25 06:44:31 <kronicd_> I hate that guy.
267 2013-04-25 06:44:35 <Graet> prices are coming down ;)
268 2013-04-25 06:45:13 <kronicd_> hrmm, right angled USB header --> USB port adapter would be cool
269 2013-04-25 06:45:16 <kronicd_> wonder if anyone makes them
270 2013-04-25 06:45:38 <kronicd_> http://www.logicsupply.com/images/photos/adapters/AFAP-082USB_big.jpg
271 2013-04-25 06:45:41 <kronicd_> yep. its a thing
272 2013-04-25 06:51:00 <Guest37484> so what happened all of a sudden with proportional payout?
273 2013-04-25 07:04:20 <Lolcust> sipa so, bloom filters would allow one to "rescan" a wallet from just utxo data ?
274 2013-04-25 07:05:14 <sipa> Lolcust: not at all
275 2013-04-25 07:05:34 <sipa> Lolcust: they just allow the p2p connection to be filtered
276 2013-04-25 07:05:44 <sipa> so you only receive transactions you're interested in
277 2013-04-25 07:06:14 <sipa> but it's still block data
278 2013-04-25 07:06:25 <sipa> the utxo set doesn't contain transactions at all
279 2013-04-25 07:08:08 <Lolcust> sipa Ah, IC. Thanks.
280 2013-04-25 07:08:41 <sipa> the ironic part is that for large amounts of addresses the follow, this is potentially faster than a local rescan
281 2013-04-25 07:09:13 <Lolcust> wait a moment - can't my wallet ballance be discerned from utxo set ? I mean, having the privkeys, I should be able to tell which of the yet-unspent outputs are spendable with my keys ?
282 2013-04-25 07:09:22 <sipa> the balance can
283 2013-04-25 07:09:28 <sipa> the history can't
284 2013-04-25 07:09:44 <Lolcust> well, that's not even a problem really
285 2013-04-25 07:09:56 <Lolcust> The use case for history-in-client is rather narrow IMO
286 2013-04-25 07:10:27 <Lolcust> and someone who wants full accounting might be interested in shelling out for a few HDDs to keep the fullchain anyway
287 2013-04-25 07:10:43 <sipa> nobody should need the full blockchain to just maintain a wallet
288 2013-04-25 07:10:46 <sipa> that's ridiculous
289 2013-04-25 07:13:08 <Lolcust> sipa well, the wallet and the capacity to rebuild your transaction history from day 1.
290 2013-04-25 07:13:45 <Lolcust> Which can be more frugally achieved by (gasp) backupin the damn thing automatically :)
291 2013-04-25 07:14:19 <Lolcust> like you would do with vanilla accounting software which ain't got a blockchain to piggyback on after a "bad event"
292 2013-04-25 07:16:59 <The_Fly> do i have any option other than processing the output of listtransactions to calculate the balance of a single address?
293 2013-04-25 07:17:28 <Luke-Jr> The_Fly: addresses don't have balances, wallets do
294 2013-04-25 07:17:47 <The_Fly> ok...
295 2013-04-25 07:18:02 <The_Fly> i had feared as much
296 2013-04-25 07:18:26 <Luke-Jr> while you can define a conceptual "address balance", it doesn't work that way and doesn't make sense to abstract it that way
297 2013-04-25 07:18:27 <The_Fly> i think the confusion was that blockchain.info etc. will display a final balance
298 2013-04-25 07:18:36 <Luke-Jr> bc.i is full of bad misinformation :/
299 2013-04-25 07:18:41 <The_Fly> :) k
300 2013-04-25 07:19:20 <The_Fly> right, i see... so you send from accounts
301 2013-04-25 07:19:39 <Luke-Jr> eh, accounts are another whole layer of abstraction <.<
302 2013-04-25 07:19:47 <Luke-Jr> on top of wallets
303 2013-04-25 07:19:55 <The_Fly> sure, but i can get an account balance
304 2013-04-25 07:19:58 <Luke-Jr> yes
305 2013-04-25 07:20:04 <Luke-Jr> account balances can also be negative
306 2013-04-25 07:20:16 <The_Fly> they can?
307 2013-04-25 07:20:20 <Luke-Jr> indeed
308 2013-04-25 07:20:27 <The_Fly> if you have unconfirmed incoming tx?
309 2013-04-25 07:20:30 <Luke-Jr> accounts are mere beancounters
310 2013-04-25 07:20:42 <Luke-Jr> if another account is positive enough to account for the negative
311 2013-04-25 07:20:58 <kronicd_> o_0
312 2013-04-25 07:21:18 <Luke-Jr> move('a', 'b', 100) <-- this will, in a new empty wallet, result in account 'a' being -100 BTC, and account 'b' being +100 BTC
313 2013-04-25 07:21:37 <The_Fly> i see, thanks
314 2013-04-25 07:24:32 <The_Fly> so best to rely on some external mechanism to keep track of a user balance, say
315 2013-04-25 07:35:09 <jgm> Has there been any work looking at protecting wallets with OTPs (YubiKey or similar)? Was thinking that the OTP could be used to generate one of the signatures in a MULTISIG transaction
316 2013-04-25 07:36:05 <gmaxwell> jgm: yubikey doesn't do the right stuff for that, alas.
317 2013-04-25 07:36:28 <gmaxwell> there is work people have done on 'hardware wallets' to basically address that idea, you can search the forums.
318 2013-04-25 07:38:45 <jgm> gmaxwell: shame, was hoping for a more generic solution. Hardware wallets are great, but was thinking more for general desktop/mobile use
319 2013-04-25 07:39:07 <gmaxwell> jgm: who says a hardware wallet isn't a little yubikey like fob?
320 2013-04-25 07:39:18 <gmaxwell> (though if it doesn't have a display there are some attacks you cannot defeat)
321 2013-04-25 07:40:51 <jgm> Yeah, more reading on this one required. Thanks
322 2013-04-25 07:43:31 <The_Fly> walletnotify is working nicely, does it stop when confirmations >=6 does anyone know?
323 2013-04-25 07:43:46 <The_Fly> would be strange to keep notifying beyond that
324 2013-04-25 07:43:56 <Luke-Jr> does it notify for every confirm? O.o
325 2013-04-25 07:44:11 <The_Fly> it is doing so here
326 2013-04-25 07:44:21 <Luke-Jr> ugly :|
327 2013-04-25 07:44:38 <Luke-Jr> I'd think if someone wanted to do something every confirm, they'd use blocknotify
328 2013-04-25 07:44:51 <The_Fly> yeah a bit... would you propose calls to gettransaction for open tranaction upon each blocknotify
329 2013-04-25 07:45:01 <The_Fly> *transactions
330 2013-04-25 07:45:58 <sipa> The_Fly: that would surprise me a lot
331 2013-04-25 07:46:06 <sipa> blocknotify will notify at every block
332 2013-04-25 07:46:26 <Luke-Jr> The_Fly: personally, I'd hit listtransactions on blocknotify ;)
333 2013-04-25 07:46:33 <sipa> but walletnotify should only notify when 1) first seen on the network 2) getting its first confirmation
334 2013-04-25 07:46:40 <The_Fly> it doesn't
335 2013-04-25 07:46:45 <The_Fly> i got two
336 2013-04-25 07:46:47 <The_Fly> on testnet
337 2013-04-25 07:47:02 <The_Fly> and im waiting to see if another comes on the next confirmation
338 2013-04-25 07:47:20 <The_Fly> < sipa> blocknotify will notify at every block
339 2013-04-25 07:47:33 <sipa> walletnotify being called twice is possible for the same transaction
340 2013-04-25 07:47:41 <sipa> once when first seen, once when confirmed
341 2013-04-25 07:47:51 <The_Fly> okay
342 2013-04-25 07:48:06 <The_Fly> and then i have to poll until 6 to trust the payment?
343 2013-04-25 07:48:15 <sipa> just check at blocknotifys
344 2013-04-25 07:48:22 <The_Fly> thats what i was asking
345 2013-04-25 07:48:45 <sipa> that's not really polling, but indeed
346 2013-04-25 07:49:09 <The_Fly> confusion was that i was not confident that blocks were tied to confirmations
347 2013-04-25 07:49:14 <The_Fly> so no need to poll :)
348 2013-04-25 07:49:34 <The_Fly> quick final question on listtransactions
349 2013-04-25 07:50:07 <The_Fly> does that filter transactions after they exceed 6 confirmations?
350 2013-04-25 07:50:11 <sipa> no
351 2013-04-25 07:50:18 <The_Fly> so it will get fairly large
352 2013-04-25 07:50:25 <The_Fly> the output
353 2013-04-25 07:50:49 <The_Fly> necessitating individual calls to gettransaction
354 2013-04-25 07:51:00 <The_Fly> for all "open" transactions
355 2013-04-25 07:51:45 <The_Fly> which is not necessarily a bad thing...
356 2013-04-25 07:51:56 <The_Fly> just would be nicer to get it all in a single call
357 2013-04-25 07:53:36 <The_Fly> perhaps a maxconf on listtransactions would achieve this?
358 2013-04-25 07:53:38 <Luke-Jr> The_Fly: listtransactions arguments filter it..
359 2013-04-25 07:54:08 <The_Fly> only by account/count/from
360 2013-04-25 07:54:53 <Luke-Jr> The_Fly: [from] is what you'd want to use I think
361 2013-04-25 07:55:07 <The_Fly> hm
362 2013-04-25 07:55:14 <The_Fly> it is just akin to a pagination index of sorts
363 2013-04-25 07:55:18 <The_Fly> righ?
364 2013-04-25 07:55:20 <The_Fly> *right?
365 2013-04-25 07:55:25 <Luke-Jr> it is as documented..
366 2013-04-25 07:55:47 <The_Fly> yeah, i see that
367 2013-04-25 07:55:57 <The_Fly> so does not fulfill my requirements
368 2013-04-25 07:57:22 <The_Fly> i will just have to make individual calls to gettransaction for all open transactions
369 2013-04-25 07:57:32 <The_Fly> until they reach the required number of confirmations
370 2013-04-25 07:58:16 <The_Fly> the only issue is that with high volume i can see a lot of processes being forked upon each blocknotify
371 2013-04-25 07:58:39 <The_Fly> which, as commented in the pull request, is a bit of a DOS hole
372 2013-04-25 08:00:38 <The_Fly> would it be accepted if i add support for a maxconfirmations on listtransactions?
373 2013-04-25 08:01:12 <The_Fly> on a very active wallet the output will grow to unmanageable proportions
374 2013-04-25 08:03:37 <Luke-Jr> exactly one process is run per blocknotify..
375 2013-04-25 08:05:23 <The_Fly> yes... but i will then want to check the n_confirmations of each open transaction ihave
376 2013-04-25 08:05:26 <The_Fly> *i have
377 2013-04-25 08:05:46 <The_Fly> because i want to make a call somewhere else once it exceeds a treshold ammount
378 2013-04-25 08:05:49 <The_Fly> *threshold
379 2013-04-25 08:05:53 <devurandom> Luke-Jr et.al.: Another question about GBT, just so that I get it right: When I longpoll, any response that I get automatically invalidates all previous templates I got from the pool?
380 2013-04-25 08:06:03 <The_Fly> and then discontinue checking that account on all subsequent blocknotifies
381 2013-04-25 08:06:25 <The_Fly> Luke-Jr: it might help if i say im building a transaction processing system for a project
382 2013-04-25 08:06:33 <devurandom> So whenever my longpoll returns, I clear the work queue, stop everything, and start again with the new template?
383 2013-04-25 08:06:57 <Luke-Jr> devurandom: not always, but you should use the new one as soon as reasonably possible
384 2013-04-25 08:08:26 <devurandom> Luke-Jr: Ok, so I do not continue with the existing template, but just throw it away on the next possible moment?
385 2013-04-25 08:08:51 <Luke-Jr> devurandom: right
386 2013-04-25 08:09:04 <devurandom> Luke-Jr: And you said something about me having to fetch more work, even though I longpoll. Should I fetch multiple templates and queue them up, until I get another longpoll answer?
387 2013-04-25 08:10:08 <devurandom> I might be confused, because I was reading a getwork implementation before. So I do not know whether the template I get from GBT is reasonably "large" that I do not have to fetch multiple of them to keep my workers busy.
388 2013-04-25 08:10:59 <devurandom> But that is what the getwork impl did - it bugged the pool for lots of work, queued it up and then let its workers work down (or up?) the queue.
389 2013-04-25 08:13:38 <devurandom> Luke-Jr: And the longpollid mechanism works such that I send a bootstrap request and use the returned longpollid for the next request? And the id returned by that for the next, and so on?
390 2013-04-25 08:14:11 <Luke-Jr> devurandom: fetching multiple templates at the same time will be useless
391 2013-04-25 08:14:31 <Luke-Jr> devurandom: you just want to make sure you fetch a replacement before blkmaker tells you that the current one has run out of work/time
392 2013-04-25 08:15:33 <Luke-Jr> devurandom: and yes - although if the normally-fetched template changes longpollid you may need to abort a prior request and restart with the new one
393 2013-04-25 08:16:12 <devurandom> Luke-Jr: So if longpoll does not return in time, I need to fetch the next template "manually"? How do I figure out how long until I need to fetch again? Or do I just fetch 2 templates and rotate through these two with my workers, so I always have a spare?
394 2013-04-25 08:16:39 <Luke-Jr> devurandom: if you fetch 2 templates at time T, most likely they will both expire at the same time T+N
395 2013-04-25 08:16:51 <Luke-Jr> devurandom: work_left and time_left are counters
396 2013-04-25 08:17:10 <Luke-Jr> devurandom: when time_left is doing to a few seconds, you probably want to be getting the next template coming in
397 2013-04-25 08:17:37 <devurandom> Ok, thanks. :) (I assume time_left is measured in seconds?)
398 2013-04-25 08:18:33 <Luke-Jr> yes
399 2013-04-25 08:22:31 <The_Fly> hm, i like gavinandresen's suggestion of "-walletnotify=/path/to/named_pipe would be safer" and same for blocknotify
400 2013-04-25 08:23:05 <devurandom> work_left is the condition that depends on how fast my workers are, and time_left depends on the pool, right? So ideally, I would measure my hashrate and by that turn work_left into a time. And if either time_left or time_of_work_left goes below the margin, I would fetch another template?
401 2013-04-25 08:23:58 <Luke-Jr> The_Fly: not sure where that suggestion is, but I disagree on it being any safer. the same thing can already be achieved with -*notify='echo foo > named_pipe'
402 2013-04-25 08:24:18 <The_Fly> right, i have already been using an echo...
403 2013-04-25 08:24:31 <The_Fly> thanks
404 2013-04-25 08:24:56 <Luke-Jr> devurandom: right
405 2013-04-25 08:25:17 <Luke-Jr> devurandom: generally speaking, work_left on a new template will be either practically-infinite or 1
406 2013-04-25 08:25:38 <Luke-Jr> in practice, I think every GBT server is doing practically-infinite
407 2013-04-25 08:25:59 <sturles> What's the safety issue? Someone making a tx with txid like "`do evil muahaha`"?
408 2013-04-25 08:26:11 <Luke-Jr> sturles: ?
409 2013-04-25 08:26:30 <sturles> script vs named pipe
410 2013-04-25 08:26:55 <sturles> The script is called with txid as argument.
411 2013-04-25 08:27:58 <Luke-Jr> sturles: txids are hex, that's impossible
412 2013-04-25 08:28:02 <sturles> I know.
413 2013-04-25 08:28:34 <sturles> I just wonder how *notify to a named pipe could be safer.
414 2013-04-25 08:29:08 <Luke-Jr> well, maybe ask gavin when he's here :p
415 2013-04-25 08:29:41 <Luke-Jr> using a named pipe would still need a fork anyway to avoid risk of blocking, so meh
416 2013-04-25 08:30:14 <sturles> Yep. Writing to a named pipe will block when it is full. This may be a bigger problem if the reader dies.
417 2013-04-25 08:30:19 <The_Fly> yeah, sorry, i missed the obvious echo to pipe
418 2013-04-25 08:30:20 <Luke-Jr> (and would drastically reduce options - no more killall -HUP or curl to a remote server)
419 2013-04-25 08:32:16 <The_Fly> the only issue im still uncomfortable with is having to make calls to gettransaction on each blocknotify. if gettransaction is pretty fast then it's no problem
420 2013-04-25 08:32:42 <The_Fly> and since a batch of gettransactions will only be called each blocknotity, i can live with that
421 2013-04-25 08:33:14 <The_Fly> it's the only way to solve what im trying to do really
422 2013-04-25 08:34:59 <devurandom> Luke-Jr: So I do not have to look at work_left at all, because the value has no actual meaning (if it is infinite)? (I assume it should measure the amount of calls to get_data that are possible?)
423 2013-04-25 08:35:41 <devurandom> And if it is 1 - what does that mean? That the 2nd call to get_data will fail?
424 2013-04-25 08:35:43 <devurandom> bbl
425 2013-04-25 08:36:30 <Luke-Jr> devurandom: correct, if it is 1 you need to behave similar to getwork
426 2013-04-25 08:37:30 <devurandom> So in that case, I need to queue up work manually?
427 2013-04-25 08:41:51 <Luke-Jr> devurandom: if necessary
428 2013-04-25 08:58:55 <MARKASH> HELLO
429 2013-04-25 09:00:43 <Scrat> HI FRIEND
430 2013-04-25 09:01:17 <MARKASH> HELLO CAN ANYBODY SPEAK TO ME
431 2013-04-25 09:01:28 <SomeoneWeird> no
432 2013-04-25 09:01:37 <MARKASH> WHY
433 2013-04-25 09:02:13 <MARKASH> CAN ANYONE TELL ME ABOUT BITCOIN
434 2013-04-25 09:03:31 <SomeoneWeird> because you're talking in caps
435 2013-04-25 09:03:34 <gmaxwell> MARKASH: you might want to go to #bitcoin channel instead of this one.
436 2013-04-25 09:03:48 <gmaxwell> MARKASH: And avoid the allcaps, it's considered yelling.
437 2013-04-25 09:07:39 <Luke-Jr> http://www.wired.com/threatlevel/2013/04/stephen-watt-stalked-by-past/
438 2013-04-25 09:33:32 <devurandom> Luke-Jr: Thanks again!
439 2013-04-25 10:42:10 <The_Fly> is there any method which can divide the role of bitcoind up between blockchain syncing and wallet functions
440 2013-04-25 10:42:23 <The_Fly> say i want to host only one copy of the blockchain, but many wallets
441 2013-04-25 10:43:09 <The_Fly> storage is cheap, but the extra bandwidth for each wallet is not optimal
442 2013-04-25 10:43:14 <The_Fly> or necessary
443 2013-04-25 10:43:52 <alaricsp> The_Fly: SPV is a bit like that
444 2013-04-25 10:44:07 <The_Fly> spv?
445 2013-04-25 10:44:47 <The_Fly> unless im mistaken and it's actually not a bandwidth concern
446 2013-04-25 10:44:49 <devurandom> Luke-Jr: I managed to run into another problem. In _build_merkle_root, the first element of txnlist is a bytes object as expected, but all later ones are _Transaction.
447 2013-04-25 10:44:58 <The_Fly> i suppose depends on the billing structure of the hosting provider
448 2013-04-25 10:45:11 <devurandom> Luke-Jr: And sha256 cannot work on that.
449 2013-04-25 10:45:37 <The_Fly> storage cheap, bandwidth also cheap, but best not to multiply bitcoin traffic per wallet (im not even sure what bitcoin bandwidth usage is like)
450 2013-04-25 10:46:01 <devurandom> Luke-Jr: When I do this instead, it works: txnlist = [coinbase] + [t.data for t in tmpl.txns]
451 2013-04-25 10:46:06 <t7> wasnt too bad when i was running bitcoind on my linode
452 2013-04-25 10:46:11 <t7> (bandwidth usage)
453 2013-04-25 10:46:12 <The_Fly> at nearly 7GB per blockchain it's not bad
454 2013-04-25 10:46:16 <The_Fly> but that's going to grow
455 2013-04-25 10:46:27 <The_Fly> and bitcoin usage is only going to increase (we hope)
456 2013-04-25 10:46:56 <The_Fly> so to scale better would be nice to have one p2p node and wallets existing independantly
457 2013-04-25 10:47:21 <The_Fly> retaining the same RPC functionality that currently exists
458 2013-04-25 10:53:22 <The_Fly> hm, i dont see any easy way to do this
459 2013-04-25 10:55:35 <The_Fly> https://bitcointalk.org/index.php?topic=80007.0
460 2013-04-25 10:56:31 <diki> Why is COIN in util.h of type in64 instead of being unsigned?
461 2013-04-25 10:56:36 <diki> *int64
462 2013-04-25 11:04:08 <pjorrit_> is there an unsigned64?
463 2013-04-25 11:05:34 <diki> yes there is
464 2013-04-25 11:06:07 <diki> on Windows it can hold a value up to 18,446,744,073,709,551,615
465 2013-04-25 11:06:30 <t7> uint64_t
466 2013-04-25 11:07:04 <diki> I guess int64 does indeed suffice even for all of the 21 million coins if they were in a single wallet
467 2013-04-25 11:07:16 <diki> unless of course we need more division
468 2013-04-25 11:07:16 <The_Fly> hrm MultiBit looks ok, but im not sure if headless
469 2013-04-25 11:09:08 <diki> I was just doing a mild exercise in PHP and wondered how to process the numbers from fields in a POST request
470 2013-04-25 11:09:22 <diki> in an exchange they are entered as 123.4567 etc
471 2013-04-25 11:09:43 <diki> I was wondering how to process that, perhaps just stripping the dot
472 2013-04-25 11:26:36 <Diapolo> gmaxwell: ping, any news on the coinstate thing?
473 2013-04-25 11:27:23 <diki> Diapolo:Hey
474 2013-04-25 11:27:39 <Diapolo> diki: hey mate
475 2013-04-25 11:29:12 <diki> When is CENT vs COIN used in the coin?
476 2013-04-25 11:29:16 <diki> *code
477 2013-04-25 11:30:59 <Diapolo> diki: never took a look at that part of the code, sorry
478 2013-04-25 11:36:45 <Sucidal> Any Flash Programmers here ?
479 2013-04-25 11:38:43 <Diablo-D3> bwahahahahahahahahahano.
480 2013-04-25 11:43:14 <diki> lol?
481 2013-04-25 11:43:16 <diki> Flash??
482 2013-04-25 11:43:23 <diki> That thing should be dead.
483 2013-04-25 11:44:31 <Sucidal> Yes, because HTML with DRM is much better.
484 2013-04-25 11:45:29 <diki> After Flash 9, it has sucks more CPU cycles than it needs.
485 2013-04-25 11:45:33 <diki> Highly unoptimized.
486 2013-04-25 11:46:46 <Sucidal> Flash is not perfect.
487 2013-04-25 11:46:55 <Sucidal> and HTML 5 is.
488 2013-04-25 11:49:45 <The_Fly> agreed
489 2013-04-25 11:50:56 <Sucidal> Especially after the DRM implementation.
490 2013-04-25 11:51:43 <Sucidal> It will be able to lock down the Web better than Flash could have ever done.
491 2013-04-25 11:51:55 <Sucidal> HTML5 lovers should start dancing on the ceiling already.
492 2013-04-25 11:52:20 <gonffen> html5 does have some really cool features
493 2013-04-25 11:52:24 <Sucidal> While they are there, they might as well start speaking in tongues.
494 2013-04-25 11:52:29 <HM2> ACTION grumbles something about xhtml
495 2013-04-25 11:53:07 <Sucidal> ha ha ha
496 2013-04-25 11:53:15 <Sucidal> HM2, yeah I remember xhtml.
497 2013-04-25 11:53:19 <Sucidal> <br/> anyone ?
498 2013-04-25 11:53:31 <saracen> I wish HTML5 only had the xml serialization :(
499 2013-04-25 11:54:39 <Sucidal> If approved.
500 2013-04-25 11:54:50 <saracen> What do you mean?
501 2013-04-25 11:54:55 <Sucidal> HTML5 will have DRM lock down before you will get your XML serialization.
502 2013-04-25 11:55:05 <saracen> It has XML serialization already
503 2013-04-25 11:55:46 <Sucidal> NOT HTML5
504 2013-04-25 11:55:51 <Sucidal> That would be XHTML5
505 2013-04-25 11:56:05 <saracen> Yes. HTML5. HTML5 has two serializations: HTML and XML.
506 2013-04-25 11:56:13 <Diablo-D3> you lie
507 2013-04-25 11:56:17 <Sucidal> <html xmlns="http://www.w3.org/1999/xhtml">
508 2013-04-25 11:56:23 <Diablo-D3> html5 killed xhtml :<
509 2013-04-25 11:56:28 <Sucidal> Normal HTML 5 is: <!DOCTYPE html>
510 2013-04-25 11:56:41 <saracen> Yes, when using html serialization
511 2013-04-25 11:56:53 <Diablo-D3> s/html/sgml/
512 2013-04-25 11:56:53 <saracen> add in the xhtml namespace and xml header
513 2013-04-25 11:57:02 <saracen> and follow xml rules, and it becomes the xml serialization
514 2013-04-25 11:57:14 <Sucidal> Why is this still going on ?
515 2013-04-25 11:57:18 <HM2> ACTION has a powerful debate-spawning grumble
516 2013-04-25 11:57:18 <saracen> SGML disappeared with HTML5. It's essentially the same thing, but they call it html.
517 2013-04-25 11:57:21 <saracen> Which, is confusing
518 2013-04-25 11:57:23 <saracen> But, that's what they did
519 2013-04-25 11:57:31 <Sucidal> Fused...not fused...fused....not fused...
520 2013-04-25 11:57:33 <saracen> http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html
521 2013-04-25 11:57:34 <saracen> Here
522 2013-04-25 11:57:39 <saracen> that's a pretty picture
523 2013-04-25 11:58:17 <Sucidal> Hold on
524 2013-04-25 11:58:29 <HM2> wow the w3c website has improved greatly since i last visited
525 2013-04-25 11:58:41 <Sucidal> You mean to tell me HTML 5 [The Normal one...] allow you to do <p> without the </P> ?
526 2013-04-25 11:58:52 <Sucidal> Crap I think I just screwed my last project!
527 2013-04-25 11:58:55 <saracen> Yes. When using the html serialization
528 2013-04-25 11:59:02 <saracen> But, it does allow both, even with html
529 2013-04-25 11:59:17 <saracen> But you can be strict about it and make it xml compliant (which is better, imp)
530 2013-04-25 11:59:21 <saracen> imo*
531 2013-04-25 11:59:23 <Sucidal> But then what becomes of the </br>
532 2013-04-25 11:59:30 <Sucidal> <br/> I mean..........
533 2013-04-25 11:59:35 <HM2> tag soup
534 2013-04-25 11:59:52 <saracen> Well, <br> is fine in the html serialization, but it's not valid xml for the xml serialization
535 2013-04-25 11:59:54 <Sucidal> I know they are quite religious about telling us <br/> is dead dead DEAD.
536 2013-04-25 11:59:58 <saracen> in XML, tags must close
537 2013-04-25 12:00:15 <HM2> in XML every tag has to be closed, unless it's of the <foo/> form
538 2013-04-25 12:00:19 <Sucidal> Fuck that shit why can't they stop this inbreding and choose one.
539 2013-04-25 12:00:25 <saracen> Which is just a self-close :)
540 2013-04-25 12:00:28 <Diablo-D3> HM2: yeah but thats just self closing
541 2013-04-25 12:00:32 <HM2> <foo/> is equivalent to <foo></foo>
542 2013-04-25 12:00:59 <HM2> even in early html, i think <br>blah</br> was technically valid
543 2013-04-25 12:01:05 <Sucidal> Accept that there are no <br></br> equalvalent
544 2013-04-25 12:01:09 <saracen> I wish they just kept to XML. There's not too much difference, but it annoys me they added things like data-something attribute. XML namespaces deal with that
545 2013-04-25 12:01:15 <Sucidal> NO fucking way....
546 2013-04-25 12:01:44 <HM2> saracen: it was infeasible.