1 2013-12-03 00:00:05 <edulix> hello ruescasd =)
2 2013-12-03 00:00:11 <edulix> welcome to here
3 2013-12-03 00:00:46 <danneu> zombocom
4 2013-12-03 00:00:59 <gmaxwell> edulix: uh. I invented an optimization for some kinds of cut and choose protocols which is applicable to both interactive and non-interactive cases, which can substantially reduce the size of a proof of a faithful random permutation.
5 2013-12-03 00:01:10 <gmaxwell> edulix: https://bitcointalk.org/index.php?topic=284194.0
6 2013-12-03 00:02:02 <edulix> thanks
7 2013-12-03 00:23:20 <michagogo> cloud|gmaxwell: wait, is it not true that it's the same privkey, from an ecdsa standpoint, and it's simply two different encodings of the same pubkey?
8 2013-12-03 00:24:26 <gmaxwell> michagogo|cloud: we do not use ecdsa in bitcoin. We use script. It is very very much not the same public key in script.
9 2013-12-03 00:24:49 <michagogo> cloud|gmaxwell: ah, fair enough.
10 2013-12-03 00:25:54 <michagogo> cloud|(I *think* I understand what you mean by "we don't use ecdsa"...)
11 2013-12-03 00:28:53 <gmaxwell> michagogo|cloud: Bitcoin's digital signature system is script. It just so happens that script embeds ecdsa. But, for a more clear example. say you have a 2 of 3 p2sh multisig. You know two of the keys, but .. without the redeemscript you can't redeem. So the redeem script is also required private key data.
12 2013-12-03 00:30:03 <michagogo> cloud|Right, that's what I thought you meant
13 2013-12-03 00:30:17 <sipa> even if you don't make the full script abstraction
14 2013-12-03 00:30:30 <sipa> bitcoin's public keys are byte sequences
15 2013-12-03 00:30:35 <gmaxwell> You can basically generalize the idea to "data you must know to redeem" == private key, "data that allows you to identify an authentic redemption" == public key, ... so in that model compressed or not is a property of the private key for pay-to-hash160
16 2013-12-03 00:30:37 <sipa> not coordinate pairs
17 2013-12-03 00:31:01 <michagogo> cloud|gmaxwell: yeah, makes sense
18 2013-12-03 00:31:18 <sipa> and the compressed and non-compressed version of the same (ECDSA) key are different byte sequences, hence different from bitcoin's perspective
19 2013-12-03 00:31:46 <sipa> that's why (bitcoin) private keys also carry a flag bit, so each public key has exactly one corresponding private key and the other way around
20 2013-12-03 00:31:54 <gmaxwell> e.g. I tell you that a payment to hash160 1apple is yours. You have a set of scalars that could be the private key. How do you know which is which? you have to brute force the compressed or not flag unless you've stored it. ... of course that could just as well be true with any other bit of the private key. :)
21 2013-12-03 00:33:16 <phantomcircuit> gmaxwell, iirc p2sh scripts are actually bruteforced already
22 2013-12-03 00:33:27 <michagogo> cloud|So a "bitcoin private key" is, in the case of p2pkh, an ecdsa pubkey plus a un/compressed flag?
23 2013-12-03 00:33:38 <phantomcircuit> there's a list of possible scripts types that all get tried for every outpoint
24 2013-12-03 00:33:45 <phantomcircuit> output*
25 2013-12-03 00:34:29 <michagogo> cloud|Where the pubkey hash itself is the "bitcoin public key"?
26 2013-12-03 00:34:38 <gmaxwell> phantomcircuit: huh? what are you talking about?
27 2013-12-03 00:34:54 <gmaxwell> michagogo|cloud: yea.
28 2013-12-03 00:35:18 <michagogo> cloud|Or I guess that would be the scriptPubKey in its entirety
29 2013-12-03 00:35:46 <michagogo> cloud|(With the opcodes assumed)
30 2013-12-03 00:35:49 <sipa> phantomcircuit: we pattern-match outputs against some patterns, turn that into a destination, and look up whether that destination matches something in our wallet
31 2013-12-03 00:36:05 <sipa> there is no brute-forcing, apart from iterating over patterns
32 2013-12-03 00:36:29 <gmaxwell> michagogo|cloud: right. At least thats how I look at it.
33 2013-12-03 00:36:47 <michagogo> cloud|Okay, I need to stop thinking about bitcoin and go to bed -- it's 2:36.
34 2013-12-03 00:36:53 <gmaxwell> Goodnight!
35 2013-12-03 00:36:58 <michagogo> cloud|Thanks
36 2013-12-03 00:37:00 <phantomcircuit> sipa, that's what i meant
37 2013-12-03 00:37:38 <phantomcircuit> sipa, the wallet's Solver doesn't try every possible p2sh because it cant possibly
38 2013-12-03 00:37:39 <sipa> but it's not variations of scripts corresponding to your pubkeys that are tried
39 2013-12-03 00:37:57 <warren> I'm back.
40 2013-12-03 00:38:03 <warren> any reports on no-mmap?
41 2013-12-03 00:38:08 <gmaxwell> the pattern matching is just so it knows how to extract the destination.
42 2013-12-03 00:38:29 <phantomcircuit> warren, turns out i missed something in there about calling fsync on the directory if it's the manifest file
43 2013-12-03 00:38:34 <phantomcircuit> which is a bug
44 2013-12-03 00:39:14 <gmaxwell> warren: rescrv is yelling at me on the toffoo pull, I'm not clear if toffoo's latest corruption is after an unrelated crash or not, I was hoping toffoo would step in to clarify.
45 2013-12-03 00:39:50 <warren> gmaxwell: was his latest crash using 0.8.6mactest1? that has none of my patches, it's purely wumpus' 0.8.6 + rescrv's patch
46 2013-12-03 00:40:14 <gmaxwell> warren: you can read the pull as much as I can.
47 2013-12-03 00:40:21 <warren> phantomcircuit: wumpus last night mentioned 0.8.6rc1 would happen, is the updated no-mmap ready? I'll test in my builds too.
48 2013-12-03 00:40:29 <warren> ACTION looks
49 2013-12-03 00:40:39 <phantomcircuit> warren, i haven't applied the fix yet
50 2013-12-03 00:40:55 <phantomcircuit> (in practice i suspect it's very unlikely to actually cause any issues but will fix it none the less)
51 2013-12-03 00:41:06 <phantomcircuit> gmaxwell, the output script is just OP_HASH160 hash OP_EQUAL
52 2013-12-03 00:41:29 <sipa> phantomcircuit: i'd rather wait for Sanjay to do no-mmap upstream than do that locally
53 2013-12-03 00:41:46 <phantomcircuit> sipa, i agree on principle but how long will that take?
54 2013-12-03 00:41:53 <phantomcircuit> so to figure out if you can spend that you need to check the cartesian join of all your keys and all the templates
55 2013-12-03 00:41:59 <phantomcircuit> or am i missing something obvious
56 2013-12-03 00:42:02 <phantomcircuit> (probably that)
57 2013-12-03 00:42:21 <sipa> phantomcircuit: yes, the p2sh addresses you are interested in are just stored in the wallet
58 2013-12-03 00:42:27 <sipa> phantomcircuit: and we match against those
59 2013-12-03 00:42:33 <phantomcircuit> ooh
60 2013-12-03 00:42:36 <warren> In the long-term no-mmap would be great for other reasons, but for the short-term it isn't worth the risk to the already reliable linux/win32.
61 2013-12-03 00:42:44 <phantomcircuit> right the p2sh address is the hash itself right?
62 2013-12-03 00:42:44 <sipa> phantomcircuit: which is the only sane thing to do
63 2013-12-03 00:42:59 <sipa> phantomcircuit: as nobody can send to an address they didn't get from people with the keys
64 2013-12-03 00:43:10 <phantomcircuit> yeah ok that makes sense
65 2013-12-03 00:44:01 <sipa> phantomcircuit: sanjay is crazy good, if he wants to, soon
66 2013-12-03 00:44:01 <warren> sipa: given the other reasons to release 0.8.6, would it be good enough with a temporary no-mmap ifdef for Mac only? Leave linux/win32 unchanged to reduce risk. Mac at least is not worse off than before.
67 2013-12-03 00:44:20 <sipa> i'd just use rescrv's patch for 0.8.6
68 2013-12-03 00:44:21 <phantomcircuit> sipa, i've been tempted a few times to write a real Solve() function to instantly grab peoples bizarre challenge txouts
69 2013-12-03 00:44:28 <warren> sipa: rescrv's patch is crashing
70 2013-12-03 00:44:36 <warren> or something else is crashing after rescrv's patch
71 2013-12-03 00:44:48 <sipa> then we first need to understand that in any case
72 2013-12-03 00:45:12 <sipa> i don't like swapping out the writing backing of leveldb in a local branch
73 2013-12-03 00:45:16 <sipa> for a point release
74 2013-12-03 00:46:03 <warren> can mac be any worse off?
75 2013-12-03 00:48:14 <phantomcircuit> sipa, it's a relatively minor change that is getting a large amount of scrutiny
76 2013-12-03 00:48:24 <phantomcircuit> (certainly it could use more)
77 2013-12-03 00:48:59 <warren> phantomcircuit: please let me know when the update is available and I'll push new binaries.
78 2013-12-03 00:49:48 <saracen> https://github.com/iStyx/IamFeelingLucky
79 2013-12-03 00:49:50 <saracen> People be crazy
80 2013-12-03 00:51:20 <phantomcircuit> saracen, lol that's hilarious
81 2013-12-03 00:51:24 <phantomcircuit> what's wrong with people
82 2013-12-03 00:52:35 <warren> phantomcircuit: do you think for this point release we should exclude !macos from no-mmap?
83 2013-12-03 00:55:25 <sipa> phantomcircuit: see sanjay's mails in https://groups.google.com/forum/#!topic/leveldb/GXhx8YvFiig
84 2013-12-03 00:55:31 <sipa> there's one 2 hours ago :)
85 2013-12-03 00:56:26 <gmaxwell> saracen: I lot of people believe the directory.io thing is a problem. :(
86 2013-12-03 00:57:10 <phantomcircuit> warren, fix pushed
87 2013-12-03 00:57:15 <phantomcircuit> gmaxwell, lol
88 2013-12-03 00:57:28 <gmaxwell> I bet as soon as someone realizes that they can lookup their own key, and then link to a page that shows a key which has recently had 100 btc "stolen" and say "hackers found my key here:" it'll get worse.
89 2013-12-03 00:57:31 <phantomcircuit> i hope they have bandwidth limiters
90 2013-12-03 00:57:39 <phantomcircuit> some idiot is going to try and scrape all the pages
91 2013-12-03 00:57:53 <gmaxwell> phantomcircuit: it's saracen's site.
92 2013-12-03 00:57:53 <sipa> cloudflare ftw
93 2013-12-03 00:58:01 <gmaxwell> and its using cloudflare.
94 2013-12-03 00:58:08 <phantomcircuit> gmaxwell, can you lookup your own key?
95 2013-12-03 00:58:16 <phantomcircuit> lol
96 2013-12-03 00:58:18 <sipa> using the power of mathematics, yes
97 2013-12-03 00:58:21 <phantomcircuit> cloudflare caching all of that nonense
98 2013-12-03 00:58:36 <phantomcircuit> oh right i guess you can lookup your private key
99 2013-12-03 00:58:38 <warren> phantomcircuit: it needs a private key search box to make finding your address easier.
100 2013-12-03 00:58:56 <phantomcircuit> warren, lol people searching for heir private keys
101 2013-12-03 00:58:58 <sipa> warren: i hope that's a joke
102 2013-12-03 00:59:02 <saracen> gmaxwell: I think it's calmed down now. They still don't understand it though, refering to it as a prank, or "fake"
103 2013-12-03 00:59:03 <warren> =)
104 2013-12-03 00:59:05 <phantomcircuit> their*
105 2013-12-03 00:59:13 <saracen> warren: You can now search by private key.
106 2013-12-03 00:59:16 <warren> oh
107 2013-12-03 00:59:17 <warren> didn't look
108 2013-12-03 00:59:26 <saracen> http://directory.io/warning:understand-how-this-works!/5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuatmU
109 2013-12-03 00:59:57 <gmaxwell> saracen: there were people last last night in #bitcoin bringing it back up because all the keys start with 5 and so did ones they were extracting from their bitcoin client.
110 2013-12-03 01:00:03 <gmaxwell> saracen: "omg bitcoin uses weak keys!"
111 2013-12-03 01:00:38 <rescrv> gmaxwell, warren, sipa, phantomcircuit: I do not mean to yell. I simply am trying to state a point: Look at my patch. The only thing it does is call msync on a region that *necessarily* is unmapped just a few instructions later. The msync call succeeds, and the subsequent munmap succeed. The region being sync'ed/unmapped is valid, as the calls succeed. The *only* other effect this can have on
112 2013-12-03 01:00:41 <rescrv> anything is that it introduces a delay that was not previously present. Becoming skeptical of mmap and replacing it may mask the symptoms of something else that is unrelated to the bug on clean shutdown.
113 2013-12-03 01:00:55 <saracen> gmaxwell: Ah, I see. I think it has some educational value now though. There's still guys crawling it. Plus that IamFeelingLucky script.
114 2013-12-03 01:01:07 <sipa> rescrv: yes, my point too
115 2013-12-03 01:01:23 <saracen> And the articles about it, still don't understand it entirely. Maybe I should add an FAQ
116 2013-12-03 01:01:34 <sipa> rescrv: i like the idea of moving away from mmap, but if your patch is causing (related or unrelated) problems to appear, we should understand those too
117 2013-12-03 01:01:56 <phantomcircuit> rescrv, im generally skeptical about mmap working correctly with read/write syscalls on osx entirely at this point
118 2013-12-03 01:01:57 <wiretapped> gmaxwell: did anything ever come of this idea? https://bitcointalk.org/index.php?topic=21995.0
119 2013-12-03 01:02:30 <sipa> and no offence, but i do trust sanjay more than phantomcircuit regarding leveldb backends, so if they're both working on it, i'd prefer waiting :)
120 2013-12-03 01:04:08 <rescrv> phantomcircuit: LevelDB never writes to files via mmap while reading from them using another method. I don't trust a write to immediately be reflected through other means, but nowhere is such a feature required.
121 2013-12-03 01:04:46 <gmaxwell> saracen: yea, you should add a faq.
122 2013-12-03 01:04:53 <phantomcircuit> rescrv, im not sure that's actually true
123 2013-12-03 01:04:59 <rescrv> phantomcircuit: it's worth reading this man page: http://www.openbsd.org/cgi-bin/man.cgi?query=msync&sektion=2&arch=i386&apropos=0&manpath=OpenBSD+Current
124 2013-12-03 01:05:01 <phantomcircuit> infact i know for a fact that isn't true
125 2013-12-03 01:05:10 <phantomcircuit> the mmap limiter means that under heavy load
126 2013-12-03 01:05:14 <phantomcircuit> you can be writing with mmap
127 2013-12-03 01:05:17 <gmaxwell> wiretapped: lots of discussion some code, as variations of that idea were later proposed by others.
128 2013-12-03 01:05:20 <phantomcircuit> but reading with standard pread()
129 2013-12-03 01:05:28 <sipa> phantomcircuit: simultaneously?
130 2013-12-03 01:05:37 <phantomcircuit> sipa, in separate threads i believe
131 2013-12-03 01:05:38 <gmaxwell> wiretapped: https://bitcointalk.org/index.php?topic=88208.0
132 2013-12-03 01:05:38 <rescrv> phantomcircuit: you're wrong there. A file is never used for reading until after it is flushed, synced and closed
133 2013-12-03 01:06:21 <warren> anyone want to buy toffoo's mac and overnight it from Brazil?
134 2013-12-03 01:06:37 <phantomcircuit> rescrv, sure but i dont trust os x to return the correct results with read() even after flush/sync/close
135 2013-12-03 01:06:39 <warren> (not sure that' s possible
136 2013-12-03 01:07:29 <phantomcircuit> i do however trust that read() after write() will be correct
137 2013-12-03 01:08:50 <rescrv> phantomcircuit: an "msync(..., MS_ASYNC)" must have the same effect as a "write(...)" by POSIX. an "msync(..., MS_SYNC)" is the more in-line with "write(...); fsync(...)"
138 2013-12-03 01:09:06 <phantomcircuit> ok the docs say that
139 2013-12-03 01:09:16 <phantomcircuit> but os x clearly doesn't actually do what the docs say
140 2013-12-03 01:09:22 <phantomcircuit> i mean ffs fsync is a NOP
141 2013-12-03 01:11:51 <phantomcircuit> rescrv, if you look at PosixMmapFile::Sync you'll notice that fdatasync is before msync, meaning if you dont trust msync to actually enforce a flush to disk (which i dont) there is a more than 0 change that even a Flush/Sync/Close cycle will result in dirty pages
142 2013-12-03 01:12:26 <phantomcircuit> chance*
143 2013-12-03 01:12:48 <phantomcircuit> if you couple that with not trusting mmap dirty pages to be reflected in read() calls
144 2013-12-03 01:12:57 <phantomcircuit> well then you have all kinds of problems
145 2013-12-03 01:13:26 <phantomcircuit> which is why i decided it would be easier and much safer to simply replace the mmap code with write() calls
146 2013-12-03 01:14:25 <phantomcircuit> rescrv, and actually the msync documentation for os x says that dirty pages are written back to the filesystem... not to disk
147 2013-12-03 01:14:43 <phantomcircuit> so not only in practice but the documented behavior is that this will fail
148 2013-12-03 01:15:47 <rescrv> phantomcircuit: are you arguing that it's possible for whole pages to b written back to the filesystem without writing them to disk?
149 2013-12-03 01:17:49 <rescrv> munmap not preceded by an msync means the kernel can do what it wants with those pages. An msync with the MS_SYNC flag must do a synchronous write before returning. One of these is a much more common path than the other. I'd believe that they'd miss the case of a dirty page not hitting the FS layer (especially given OS X's origins). I'd bet there's a much smaller chance that they miss a synchronous
150 2013-12-03 01:17:51 <rescrv> write.
151 2013-12-03 01:19:10 <warren> where's the URL for toffoo's latest corruption?
152 2013-12-03 01:19:37 <rescrv> so while you can rewrite the mmap code because you don't trust OS X, I argue that it's mostly superstition and that the patch I provided is just as safe from a correctness standpoint because it takes the code from the realm of "this is undefined behavior, but it so happens to work" to "this is relying upon specifications that are quite clear about what should happen".
153 2013-12-03 01:21:24 <warren> ACTION wonders how to e-mail toffoo
154 2013-12-03 01:38:07 <amiller> gmaxwell, is there a pre-built way to search the blockchain for instances of OP_CHECKMULTISIG
155 2013-12-03 01:38:10 <amiller> like one you know of from blockchain.info
156 2013-12-03 01:38:20 <amiller> i want to see how many of them are actually used
157 2013-12-03 01:38:29 <amiller> i've asked this before and don't recall the answer / might try searching logs
158 2013-12-03 01:39:19 <gmaxwell> amiller: no. also, you can't see them for unspent p2sh. :)
159 2013-12-03 01:39:57 <gmaxwell> the answer a couple months ago was "not much" but apparentlyâ petertodd had made some commentsâ there is someone using them at some scale now.
160 2013-12-03 01:44:38 <ers35> Has a bug report been filed at https://bugreport.apple.com/ regarding mmap dirty page writing?
161 2013-12-03 01:52:00 <hno> rescrv, MAP_SHARED without the use of mxync is not undefined. Only unbounded in time when the writes will hit the backing store.
162 2013-12-03 01:53:58 <Luke-Jr> hno: do you happen to know offhand which standard defines the behaviour in that case?
163 2013-12-03 01:54:40 <Luke-Jr> my manpage at least seems to leave it undefined unless msync or munmap is called
164 2013-12-03 01:56:45 <rescrv> hno Luke-Jr: On Linux, munmap will sync. On some BSDs (OpenBSD is most explicit), you need to msync to ensure the dirty pages are pushed back to the file. The system can do so, but is not obligated to do so quickly. That's the gist of what was happening. There was a region of the file to which data was "memmoved", and then the page was immediately unmapped. That final change didn't make it to the
165 2013-12-03 01:56:47 <rescrv> backing file, leading to the corruption.
166 2013-12-03 01:58:10 <saracen> Okay, FAQ added: http://directory.io/faq
167 2013-12-03 02:01:44 <Luke-Jr> saracen: excellent
168 2013-12-03 02:03:06 <gmaxwell> saracen: you might want to add a silly "Because of this the system displays X pages, which is about 400 quadrillion times more pages than there are atoms in the solar system"
169 2013-12-03 02:03:38 <gmaxwell> (perhaps thats a little more concrete for people than just the 'because math' that you have now)
170 2013-12-03 02:04:04 <saracen> Yeah, but the atom explanation has become too cliche
171 2013-12-03 02:06:20 <Luke-Jr> saracen: ooooh, you could have it generate each page in javascript..
172 2013-12-03 02:06:35 <gmaxwell> Two quattuordecillion times the age of the universe in pico-seconds?
173 2013-12-03 02:06:40 <Luke-Jr> no server load
174 2013-12-03 02:07:00 <saracen> Luke-Jr: Yeah, I realied that as soon as people started crawling me :(
175 2013-12-03 02:07:04 <saracen> err, realised*
176 2013-12-03 02:07:24 <saracen> They'd probably have still done it though, just fetching the same page again and again.
177 2013-12-03 02:10:31 <Luke-Jr> saracen: my father decided to print a hard copy of your database. can you advise him on how many orders of toner he should get?
178 2013-12-03 02:11:43 <berndj> lucky dad - it isn't an inkjet
179 2013-12-03 02:12:30 <Luke-Jr> why would anyone buy inkjet?
180 2013-12-03 02:12:41 <saracen> Luke-Jr: Ha :)
181 2013-12-03 02:12:48 <saracen> Speaking of backups: http://pastebin.com/wS14ykC6
182 2013-12-03 02:12:51 <saracen> Who did this :(
183 2013-12-03 02:13:54 <saracen> gmaxwell: I added the reddit link to that guy explaining why it is impossible
184 2013-12-03 02:14:38 <xorpt> Is there a good channel to discuss the bitcoin, or other alt coins, protocol?
185 2013-12-03 02:15:48 <Luke-Jr> xorpt: here, for bitcoin
186 2013-12-03 02:16:18 <xorpt> Luke-Jr: Great, thanks.
187 2013-12-03 02:17:12 <warren> anyone know how to remove extremely old tx's from a wallet that will never confirm?
188 2013-12-03 02:17:39 <warren> I tested it months ago with a client that violated fee rules to verify that Coin Control was working.
189 2013-12-03 02:17:52 <Luke-Jr> warren: if you find out, let me know XD
190 2013-12-03 02:17:54 <warren> and now I have stuck tx's in the wallet that retransmit forever
191 2013-12-03 02:18:00 <Luke-Jr> I've had 2 stuck for like a year
192 2013-12-03 02:18:15 <Luke-Jr> wow, yep, Dec 4 2012
193 2013-12-03 02:18:25 <Luke-Jr> almost exactly a year
194 2013-12-03 02:18:26 <warren> I suppose I could modify the mempool accept to mine them...
195 2013-12-03 02:18:37 <warren> hell yes, doing that.
196 2013-12-03 02:18:39 <Luke-Jr> mine are doublespends :P
197 2013-12-03 02:18:49 <xorpt> I read a bit of the paper from Satoshi about the bitcoin protocol, and right at the start he makes the point that it's better to create some sort of proof of work instead of relying on ips for majority decision. Now at the time that made sense, but now with ASICS I'm not so sure.
198 2013-12-03 02:19:06 <Luke-Jr> xorpt: IPs are centrally delegated..
199 2013-12-03 02:19:26 <Luke-Jr> mining ASICs are far more diverse in comparison
200 2013-12-03 02:19:38 <warren> Error: Invalid amount for -mintxfee=<amount>: '0'
201 2013-12-03 02:19:39 <warren> damn
202 2013-12-03 02:19:41 <warren> hahhaa
203 2013-12-03 02:20:13 <Luke-Jr> warren: just pastebin the raw tx and I'll prioritise them on Eligius
204 2013-12-03 02:20:17 <xorpt> My CPU can maybe push 10 Mh/s, there are ASICS pushing 7500000Mh/s, and they cost 14500 dollars. That's like buying 50 ips for a dollar.
205 2013-12-03 02:20:53 <Luke-Jr> xorpt: 50 IPs? standard issue is a /48 subnet!
206 2013-12-03 02:21:06 <xorpt> And I'm on a desktop with a quad core, the real people out there doing the shopping use phones, ipds, notebooks.
207 2013-12-03 02:21:12 <warren> Luke-Jr: this is my testnet wallet
208 2013-12-03 02:21:15 <xorpt> Does that cost 1 dollar?
209 2013-12-03 02:21:39 <Luke-Jr> warren: ah
210 2013-12-03 02:22:05 <Luke-Jr> if only satoshi had hardforked to add merged mining to bitcoin before he left.. sigh
211 2013-12-03 02:22:14 <Luke-Jr> (then we could be merge mining testnet with mainnet)
212 2013-12-03 02:26:21 <xorpt> Doesn't matter how much it costs, that's a lot of ips ^^
213 2013-12-03 02:26:42 <gmaxwell> xorpt: this is offtopic for this channel, but if you'd like to move it to #bitcoin I'd be glad to discuss it with you.
214 2013-12-03 02:27:19 <xorpt> gmaxwell: Sure.
215 2013-12-03 02:28:06 <warren> Luke-Jr: https://bitcointalk.org/index.php?topic=34028.0 this tool claims to be able to delete transactions
216 2013-12-03 02:29:54 <warren> Luke-Jr: grrr.... there's no git?
217 2013-12-03 02:37:57 <warren> Luke-Jr: https://github.com/jackjack-jj/pywallet
218 2013-12-03 02:38:05 <warren> Luke-Jr: delete all transactions from wallet and rescan
219 2013-12-03 02:41:54 <warren> Luke-Jr: I suppose you can also just delete particular txid
220 2013-12-03 02:59:05 <cfields> Luke-Jr: ping
221 2013-12-03 03:16:12 <rweichler> hey when i use -walletnotify it doesn't notify me until a new block is mined on my regtest
222 2013-12-03 03:16:28 <rweichler> id imagine it'd be right when it recieves the transaction (not necessarily when it recieves a block) on the normal network, right?
223 2013-12-03 03:26:47 <spokesz> Does anyone have testnet coins they dont need? My app is ready for testing but I dont have any :D
224 2013-12-03 03:44:32 <rweichler> spokesz: use -regtest
225 2013-12-03 03:45:45 <spokesz> rweichler: what does that do?
226 2013-12-03 03:53:47 <rweichler> makes your own testnet
227 2013-12-03 03:53:57 <rweichler> and then you do setgenerate true to instantly get 50 coins
228 2013-12-03 03:58:42 <shesek> spokesz, testnet.mojocoin.com
229 2013-12-03 03:59:26 <shesek> if you can, return it to them when you're doing using them
230 2013-12-03 04:22:42 <phantomcircuit> rescrv, check the os x man page it doesn't say anything about whether MS_SYNC pushes to disk or to the filesystem, the way i read it MS_ASYNC pushes async to the filesystem and MS_SYNC pushes sync to the filesystem but not necessarilly to disk
231 2013-12-03 04:23:08 <phantomcircuit> indeed it seems to imply that it's not pushing synchronously to disk at all
232 2013-12-03 04:29:21 <EasyAt> Does any known client have built in dust collection or perhaps output consolidation? As in combine more than the required outputs in order to save space in UTXO or something?
233 2013-12-03 04:29:43 <EasyAt> https://blockchain.info/tx/04479fd1048e79994b6227a1bfadf31ccccf5f46f66dc9ea55bb9abee4fc23a4
234 2013-12-03 04:30:03 <EasyAt> This person is spending 10 coins but his client appears to have selected extra outputs
235 2013-12-03 04:33:03 <rescrv> phantomcircuit: that's a crazy interpretation of the man page. What is the filesystem if not the permanent storage on disk? The FS module in the kernel? How would it reach there asynchronously. To back up my claim: OS X is certified by the open group to conform to its standard. See here: http://pubs.opengroup.org/onlinepubs/007904875/functions/msync.html . Pay attention to the words "The msync()
236 2013-12-03 04:33:05 <rescrv> function shall write all modified data to permanent storage locations"
237 2013-12-03 04:33:59 <gmaxwell> EasyAt: how do you know they're spending 10 coins? maybe they specified two outputs themselves.
238 2013-12-03 04:41:08 <cfields> phantomcircuit: it's saying that MS_SYNC pushes to the hdd, but doesn't guarantee that the hdd flushes its cache to the platters synchronously
239 2013-12-03 04:41:34 <cfields> so if you request a page from the hdd, you'll get it back as if it's written, but if power is cut, you might not see it again when repowered
240 2013-12-03 04:43:56 <EasyAt> gmaxwell: I don't. Though, the 10 BTC address is coinbase
241 2013-12-03 04:44:00 <EasyAt> I think, at least
242 2013-12-03 04:44:50 <gmaxwell> EasyAt: in any case, there is some fancier coin selection code in armory that might be able to do that, but I've never seen evidence of it doing so.
243 2013-12-03 04:45:31 <cfields> in fact, the man pages are pretty clear about that:
244 2013-12-03 04:45:43 <cfields> data to the platters for quite some time and it may be written in an out-of-order sequence.
245 2013-12-03 04:45:43 <cfields> Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent storage device"), the drive itself may not physically write the
246 2013-12-03 04:45:43 <gmaxwell> EasyAt: at some point I'd like to change bitcoin-qt to do that (e.g. always pull on all the coins on whatever addresses its using if there is already change, and if the transaction already has a fee)
247 2013-12-03 04:46:29 <EasyAt> gmaxwell: Armory only allows selection of address I believe, not output. Though, that'd be nice
248 2013-12-03 04:46:52 <cfields> rescrv: so there's your definition, from OSX itself. "permanent storage device" may really be a transient cache.
249 2013-12-03 04:46:52 <EasyAt> Hm, maybe Armory sends all outputs tied to that address
250 2013-12-03 04:47:41 <rescrv> cfields: I think it's stronger than that. See "Synchronized I/O Data Integrity Completion" from http://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap03.html and note that it's the guarantee that msync(MS_SYNC) is required to give you
251 2013-12-03 04:47:50 <EasyAt> nvm, then all of the inputs would have the same address
252 2013-12-03 04:48:06 <gmaxwell> EasyAt: I mean its optimizer can do things like prefer to produce non-jagged change.
253 2013-12-03 04:48:58 <cfields> rescrv: i'm not arguing the spec, i'm simply c/p apple's stated behavior
254 2013-12-03 04:50:06 <EasyAt> gmaxwell: Optimizing like that makes it easier to group addresses in 1 wallet, no?
255 2013-12-03 04:50:06 <rweichler> whats the difference between addnode and connect in bitcoin.conf?
256 2013-12-03 04:50:19 <EasyAt> For an outsider to group them*
257 2013-12-03 04:50:30 <cfields> rescrv: and it makes sense. The OS writes to the disk, and waits for the disk to say that it's written. If the disk uses a hardy (unsafe) cache, that's not to say the the OS lied about the data being written.
258 2013-12-03 04:52:03 <cfields> rescrv: in fact, it seems perfectly reasonable that someone like toffoo could be seeing a fw bug on his disk that's not honoring write-through requests as it should
259 2013-12-03 04:53:29 <cfields> as a (probably useless) point, it may be no coincidence that apple's SSDs (as his is) began getting popular around the 10.8 era, which is where we've seen this thing manifest.
260 2013-12-03 04:57:35 <cfields> rescrv: note that despite the tinfoil, I still think your change is necessary and correct.
261 2013-12-03 04:59:06 <lifeofcray> can i set transaction fee per transaction?
262 2013-12-03 04:59:28 <lifeofcray> if im making a php wallet?
263 2013-12-03 05:00:05 <lifeofcray> i recon some users would want to have higher/lower fees than others
264 2013-12-03 05:00:37 <EasyAt> Are you using the reference client as a backend?
265 2013-12-03 05:01:12 <lifeofcray> what's a reference client?
266 2013-12-03 05:01:21 <EasyAt> bitcoin-qt
267 2013-12-03 05:01:25 <lifeofcray> ah, yes
268 2013-12-03 05:01:56 <EasyAt> If you''re creating a rawtx, why not?
269 2013-12-03 05:03:08 <EasyAt> or you can use settxfee
270 2013-12-03 05:03:16 <EasyAt> https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
271 2013-12-03 05:04:35 <gmaxwell> EasyAt: like what?
272 2013-12-03 05:06:30 <lifeofcray> if i use settxfee, isnt there a risk that two users will call it at the same time? so it's like settx.user1 settx.user2 sendcash.1 sendcash.2 isntead of settx1 send1 settx2 send2?
273 2013-12-03 05:08:51 <EasyAt> gmaxwell: @gmaxwell> EasyAt: like what? <-- what are you referring to
274 2013-12-03 05:09:02 <gmaxwell> 20:50 < EasyAt> gmaxwell: Optimizing like that makes it easier to group addresses in 1 wallet, no?
275 2013-12-03 05:09:08 <gmaxwell> EasyAt: like "that" what?
276 2013-12-03 05:09:16 <gmaxwell> your question was ambigious.
277 2013-12-03 05:10:58 <EasyAt> Well, the optimizer is linking multiple addresses, just to make prettier outputs. Seeing a TX like that as someone who doesn't know the sender can reasonably assume common ownership
278 2013-12-03 05:11:20 <EasyAt> Seems unncessary to give that away
279 2013-12-03 05:11:43 <gmaxwell> EasyAt: right but was it previously already given away? :P
280 2013-12-03 05:12:01 <EasyAt> Ha, as in is it mine?
281 2013-12-03 05:12:33 <gmaxwell> EasyAt: no, I mean, the wallet could check when adding extra outputs and only add ones sent to the same address OR which have already been used as a common input previously.
282 2013-12-03 05:12:54 <gmaxwell> and so linking it again wouldn't really leak much more information.
283 2013-12-03 05:12:59 <EasyAt> Ah, gotchya
284 2013-12-03 06:54:57 <phantomcircuit> cfields, rescrv the actual osx msync man page isn't anywhere near as clear cut on whether it pushes to the filesystem module or to the hdd itself
285 2013-12-03 06:54:57 <phantomcircuit> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/msync.2.html
286 2013-12-03 06:55:29 <phantomcircuit> "The msync() system call writes modified whole pages back to the filesystem and updates the file modification time."
287 2013-12-03 06:56:09 <phantomcircuit> personally i interpret that to mean the pages are flushed into the page cache and marked as dirty but not flushed to hdd and certainly not flushed to platters
288 2013-12-03 06:56:51 <phantomcircuit> i can certainly agree that the opengroup version of this man page clearly states it needs to be flushed to permanent storage
289 2013-12-03 06:57:03 <phantomcircuit> but os x obviously doesn't care what they think since fsync is a nop...
290 2013-12-03 07:04:08 <rweichler> whats the difference between addnode and connect in bitcoin.conf?
291 2013-12-03 07:05:22 <weex> addnode is exclusive
292 2013-12-03 07:05:38 <weex> if you have addnodes, no other nodes will be connected to
293 2013-12-03 07:05:48 <weex> connect is "please try these too"
294 2013-12-03 07:05:59 <phantomcircuit> weex, that's backwards
295 2013-12-03 07:07:36 <weex> that's how i roll
296 2013-12-03 07:13:58 <freewil> yeah, what phantomcircuit said
297 2013-12-03 07:15:16 <rweichler> im fricking confused now
298 2013-12-03 07:15:27 <rweichler> aight so if im like connect=127.0.0.1 i wont get shiet
299 2013-12-03 07:15:35 <rweichler> but if im like addnode=127.0.0.1 ill be chill?
300 2013-12-03 07:15:51 <rweichler> or just like a random eye pee
301 2013-12-03 07:16:08 <freewil> you probably dont want to specify localhost for either one of those
302 2013-12-03 07:16:20 <freewil> you are telling your bitcoind about other peers with those two options
303 2013-12-03 07:17:11 <freewil> i have an internal bitcoind where i specify -connect to tell it to only connect to the bitcoind i have on the edge of my network
304 2013-12-03 07:17:36 <freewil> so thats the only peer it has
305 2013-12-03 07:18:33 <rweichler> Okay, I see
306 2013-12-03 07:19:52 <freewil> in the case i layed out you probably want to set listen=0 as well
307 2013-12-03 07:57:54 <warren> Anyone have testnet coins? Please send a few dozen tx's of any size to mfq9MhywsmZijd7DqsDrKLQ9yGD94EUzyN
308 2013-12-03 07:58:18 <K1773R> warren: tpfaucet.appspot.com
309 2013-12-03 07:58:51 <K1773R> warren: http://testnet.mojocoin.com/
310 2013-12-03 07:59:12 <warren> mojocoin seems broken
311 2013-12-03 07:59:22 <K1773R> ugh, long time since ive tried
312 2013-12-03 08:00:30 <lifeofcray> what's a testnet coin?
313 2013-12-03 08:10:31 <xeroc> lifeofcray: the testnet is an alternative blockchain ..
314 2013-12-03 08:10:50 <xeroc> lower difficulties and some other tweaks .. just for testing of protocol etc..
315 2013-12-03 08:11:05 <xeroc> lifeofcray: testnet coins are like bitcoins just in the testnet ==> worth nothing ..
316 2013-12-03 08:31:12 <iddo> gmaxwell: there's new paper on multi-party computation and Bitcoin: http://eprint.iacr.org/2013/784.pdf
317 2013-12-03 08:32:11 <iddo> looking at page 18, seems like they are using something similar to my first idea on how to do fair coin toss, rather than the improved idea of Adam Back
318 2013-12-03 08:33:28 <gmaxwell> 15:20 < gmaxwell> amiller: I expect iddo will be unhappy with that paper.
319 2013-12-03 08:33:29 <gmaxwell> 15:20 < gmaxwell> amiller: it doesn't really go too much further than the coinflip stuff other than to note that it could be applied more generally. And I assume iddo was working on a similar paper.
320 2013-12-03 08:33:33 <gmaxwell> 15:21 < nsh> link/ref for iddo's work?
321 2013-12-03 08:33:35 <gmaxwell> 15:55 < amiller> i think i'll email them and suggest they review iddo's forum post
322 2013-12-03 08:33:56 <gmaxwell> iddo: I'd even edited amiller's post about to hyperlink your coinflip thing.
323 2013-12-03 08:34:28 <iddo> oh sorry, didn't see the previous chat
324 2013-12-03 08:35:08 <gmaxwell> iddo: You should be idling in #bitcoin-wizards if you can.
325 2013-12-03 08:35:33 <iddo> if you haven't emailed them yet, then i can email them now so that i could see how they respond
326 2013-12-03 08:35:42 <iddo> ok
327 2013-12-03 08:35:53 <gmaxwell> I think amiller has, I dunno.
328 2013-12-03 08:35:55 <gmaxwell> amiller: ^
329 2013-12-03 08:36:09 <iddo> ok i'll wait:)
330 2013-12-03 08:36:29 <lifeofcray> guys, what happens if i send coins to an adress that's in the same wallet?
331 2013-12-03 08:36:38 <iddo> trying to look now if they also have more interesting constructions in the paper
332 2013-12-03 09:17:08 <hno> lifeofcray, depends on your wallet software. It may alert you about it and ask if you really want a transaction or just adjust wallet balances, or just send it anyway.
333 2013-12-03 10:08:55 <TD> good morning
334 2013-12-03 11:11:29 <diki> I just noticed that the wiki does not specify how you compute the hash of a transaction.
335 2013-12-03 11:11:58 <stonecoldpat> as far as im aware, you concantate all the inputs/outputs then hash ti
336 2013-12-03 11:12:08 <diki> double sha256 or single?
337 2013-12-03 11:12:45 <stonecoldpat> twice as far as im aware
338 2013-12-03 11:12:49 <stonecoldpat> http://bitcoin.stackexchange.com/questions/2859/how-are-transaction-hashes-calculated
339 2013-12-03 11:12:50 <stonecoldpat> talks about it
340 2013-12-03 11:13:19 <diki> I think someone needs to add that to the wiki.
341 2013-12-03 11:16:28 <stonecoldpat> i cant find it on the wiki either
342 2013-12-03 11:16:38 <stonecoldpat> im looking into that atm so ill try and give it an update at some point
343 2013-12-03 11:16:55 <stonecoldpat> (if i can edit it obv)
344 2013-12-03 12:33:04 <diki> Another question. Can I trust that the transactions in my copy of the blockchain are valid? I don't want to do any sophisticated verification whether some output can actually spend the funds.
345 2013-12-03 12:33:30 <sipa> no, you cannot
346 2013-12-03 12:33:39 <sipa> they're only validated after storing them
347 2013-12-03 12:33:48 <diki> well that simply sucks
348 2013-12-03 12:34:26 <diki> So now I have to verify them all?
349 2013-12-03 12:35:38 <diki> https://en.bitcoin.it/wiki/Protocol_specification#Transaction_Verification does not tell me what I must do.
350 2013-12-03 12:37:08 <sipa> don't
351 2013-12-03 12:37:13 <sipa> let bitcoind do that
352 2013-12-03 12:37:53 <sipa> and use getblock to query it for valid transactions in the chain
353 2013-12-03 12:37:58 <diki> sipa:I am writing my own blockchain parser, my end goal is to export the utxos.
354 2013-12-03 12:38:16 <diki> however I don't want to mark some output as spent if the transaction was not valid.
355 2013-12-03 12:38:36 <sipa> you can't just iterate all blocks in the block datadir
356 2013-12-03 12:38:44 <sipa> it will contain invalid blocks and blocks in side chains
357 2013-12-03 12:38:54 <sipa> you need to walk the currently active block chain
358 2013-12-03 12:39:05 <wumpus> bitcoind is very good at keeping track of the utxo, why not let it do that for you
359 2013-12-03 12:39:23 <diki> wumpus:Won't hurt to learn more about the bitcoin protcol.
360 2013-12-03 12:42:36 <diki> sipa:And to walk the active blockchain, do I check if the current block's prev_block value matches the previous block?
361 2013-12-03 12:43:14 <sipa> use getblock, and follow the nextblockhash
362 2013-12-03 12:43:31 <diki> I don't plan to use bitcoind at all.
363 2013-12-03 12:43:38 <sipa> then you'll have a problem
364 2013-12-03 12:43:43 <diki> Why?
365 2013-12-03 12:43:56 <diki> I will code everything I need if I have to. All I need is some pointers :)
366 2013-12-03 12:44:04 <sipa> unless you plan on reimplementing the blockchain verification from scratch, just the block fiels don't contain the necessary information
367 2013-12-03 12:44:36 <sipa> bitcoind keeps verification information in its databases
368 2013-12-03 12:45:24 <sipa> you can of course just ask it once for the current best block, and then do everything yourself, by finding all ancestors of that blocks
369 2013-12-03 12:47:10 <diki> And if hypothetically I did want to re-implement the bitcoin protocol? Writing a node from scratch etc?
370 2013-12-03 12:47:28 <sipa> then i would ask you to reconsider
371 2013-12-03 12:48:00 <sipa> not that trying to do so is not useful as an exercise, but you'll spend more time than you imagine to get the details right
372 2013-12-03 12:48:05 <diki> I am aware of how the developers feel about reimplementations, I've seen their reaction towards some of them
373 2013-12-03 13:19:42 <Luke-Jr> cfields: pong
374 2013-12-03 13:28:18 <amiller> iddo, go ahead and email ehtme i havven't gotten to it yet :p
375 2013-12-03 13:35:49 <lclc> what was the reason to choose JSON-RPC for IPC/RPC instead of DBus? Has there ever been a discussion about this or is it just historically
376 2013-12-03 13:36:35 <Diablo-D3> lclc: because dbus only exists usefully on one OS?
377 2013-12-03 13:36:46 <Diablo-D3> and the point of the json rpc is to interact with webapps
378 2013-12-03 13:37:36 <wumpus> lclc: there is a patch for using zeromq floating around somewhere, I don't think dbus would have made much sense
379 2013-12-03 13:37:38 <lclc> I don't know how usfull it is for Windows, but it exists
380 2013-12-03 13:37:58 <Diablo-D3> its not useful for osx either
381 2013-12-03 13:38:10 <wumpus> dbus is meant for a completely different purpose, basically for local system control, not as a general purpose RPC mechanism
382 2013-12-03 13:38:12 <Diablo-D3> dbus is also a pile of shit and should die in a fire
383 2013-12-03 13:38:22 <Diablo-D3> wumpus: thats not entirely true either
384 2013-12-03 13:38:30 <Diablo-D3> its not meant for high bandwidth messaging though
385 2013-12-03 13:38:35 <Diablo-D3> or low latency messaging
386 2013-12-03 13:38:56 <wumpus> Diablo-D3: in practice, it is, do you know of any other practical applications that use dbus?
387 2013-12-03 13:39:24 <Diablo-D3> wumpus: mostly gnomey kind of shit
388 2013-12-03 13:39:27 <lclc> ok thanks
389 2013-12-03 13:39:33 <Diablo-D3> its not all kenrel<->userland shit
390 2013-12-03 13:39:49 <wumpus> yes -- it was made as a replacement for CORBA, for gnome, which is a general RPC mechanism but kind of overkill for the task
391 2013-12-03 13:39:56 <Diablo-D3> yeah
392 2013-12-03 13:39:59 <Diablo-D3> it works for DEs fine
393 2013-12-03 13:40:02 <wumpus> but it's basically for communication between applications on the local system
394 2013-12-03 13:40:13 <wumpus> and kernel<->userland "shit"
395 2013-12-03 13:40:26 <Diablo-D3> but like, linux would have been better served with a L4-style message passing system
396 2013-12-03 13:40:41 <Diablo-D3> do it all in kernel space, do it at very high speed
397 2013-12-03 13:41:06 <TD> basically like android binder
398 2013-12-03 13:41:36 <Diablo-D3> TD: android whatnow?
399 2013-12-03 13:41:54 <wumpus> dbus works pretty well for what it's used for, sure, in retrospect it's always possible to think of something better, but I think all the switching around protocols is detrimental to actually accomplishing things in floss
400 2013-12-03 13:41:55 <TD> android has a local RPC mechanism that's kernel based
401 2013-12-03 13:42:02 <wumpus> yes the binder is pretty neat
402 2013-12-03 13:42:05 <TD> and which lets you send capabilities across channels, etc.
403 2013-12-03 13:42:09 <TD> android in general is pretty neat
404 2013-12-03 13:42:09 <wumpus> though heavily underdocumented
405 2013-12-03 13:42:17 <Diablo-D3> TD: a lot of android isnt linux though
406 2013-12-03 13:42:18 <TD> hmm it's not that underdocumented...
407 2013-12-03 13:42:19 <TD> right
408 2013-12-03 13:42:22 <Diablo-D3> TD: even if it is bolted to the linux kernel
409 2013-12-03 13:42:28 <Diablo-D3> I'd like to see that change
410 2013-12-03 13:43:00 <Diablo-D3> android could be a useful OS that lots of people could adopt if google was smart about it
411 2013-12-03 13:43:11 <wumpus> TD: well it was back in the time I was looking at it, almost all of the low-level stuff was under (or undocumented)... maybe the situation improved
412 2013-12-03 13:43:32 <Luke-Jr> wumpus: KDE uses dbus for IM and VoIP negotiations
413 2013-12-03 13:43:54 <Diablo-D3> TD: like, I'd take android a lot more seriously if google switched to wayland for android instead of displayflinger or whatever its called
414 2013-12-03 13:44:08 <Luke-Jr> or at least is planning to, not sure if they've put it into reality yet
415 2013-12-03 13:44:08 <wumpus> Diablo-D3: what's wrong with surfaceflinger?
416 2013-12-03 13:44:10 <wumpus> Luke-Jr: ok, thanks
417 2013-12-03 13:44:34 <Diablo-D3> wumpus: its wasted effort
418 2013-12-03 13:44:48 <wumpus> Diablo-D3: surfaceflinger is a simple and effective compositor interface
419 2013-12-03 13:44:56 <Diablo-D3> Luke-Jr: kde uses dbus everywhere now, actually
420 2013-12-03 13:45:01 <sipa> wumpus: the first rule of #bitcoin-dev is: do not argue with Diablo-D3
421 2013-12-03 13:45:21 <Diablo-D3> wumpus: yes, and its also android only and no third parties contribute to it on a regular basis
422 2013-12-03 13:45:44 <wumpus> sipa: I forgot for a moment
423 2013-12-03 13:45:46 <Diablo-D3> wumpus: it also cannot use the mesa/DRI stack, and depends on binary drivers that are only for android and not for other systems
424 2013-12-03 13:45:58 <Diablo-D3> wumpus: its rather useless.
425 2013-12-03 13:46:34 <wumpus> Diablo-D3: why couldn't surfaceflinger use OpenGL as backend?
426 2013-12-03 13:46:58 <Diablo-D3> wumpus: well, why would it? apps do not directly use it
427 2013-12-03 13:46:58 <Luke-Jr> KDE always used dbus everywhere, even before dbus.
428 2013-12-03 13:47:27 <Diablo-D3> wumpus: all android drawing APIs do not rely on surfaceflinger
429 2013-12-03 13:47:29 <Luke-Jr> dbus was based (in concept) on KDE's DCOP
430 2013-12-03 13:47:36 <wumpus> Diablo-D3: I'm pretty sure that's the default fallback even, if a platform doesn't have a native composition engine
431 2013-12-03 13:47:39 <Diablo-D3> Luke-Jr: yup, it was, I was trying to think of the name of it
432 2013-12-03 13:47:52 <Luke-Jr> I had to google it, it's been forever..
433 2013-12-03 13:47:58 <Diablo-D3> wumpus: I think it can render to opengl, because of the google x86 emulator
434 2013-12-03 13:48:02 <Diablo-D3> er, google android
435 2013-12-03 13:48:21 <lclc> I was just asking because FellowTraveler / OpenTransactions wants to make an OT daemon for OT clients like bitcoind is Bitcoin clients. Seems like the consensus in here is that JSON-RPC would be better for that too
436 2013-12-03 13:48:24 <Diablo-D3> Luke-Jr: and to be fair, dbus is an FDO effort, not gnome
437 2013-12-03 13:48:36 <Luke-Jr> FDO is GNOME
438 2013-12-03 13:48:41 <Diablo-D3> FDO is gnome AND kde
439 2013-12-03 13:48:43 <Diablo-D3> and xfce
440 2013-12-03 13:48:47 <Diablo-D3> and anyone else that wants to participate
441 2013-12-03 13:48:50 <Luke-Jr> Diablo-D3: GNOME took over, it seems
442 2013-12-03 13:48:57 <Diablo-D3> gnome makes the most contributions
443 2013-12-03 13:48:58 <wumpus> lclc: JSON-RPC is very well supported by languages... the only real issue that we have with it is that it has no 'decimal' type for monetary amounts
444 2013-12-03 13:49:00 <Diablo-D3> kde chooses not to
445 2013-12-03 13:49:03 <Luke-Jr> FDO's newer stuff wants to force GNOME libraries on everything else
446 2013-12-03 13:49:11 <Diablo-D3> Luke-Jr: yes/no
447 2013-12-03 13:49:20 <Diablo-D3> newer stuff uses gnome libraries as the standard impl
448 2013-12-03 13:49:28 <Diablo-D3> but its not a gnome infection route
449 2013-12-03 13:49:31 <wumpus> lclc: we currently use the number type for those, which is a bad idea because many implementations use doubles/other floating point types to represent it
450 2013-12-03 13:49:38 <Diablo-D3> its mostly glib-based stuff
451 2013-12-03 13:49:48 <Diablo-D3> which a LOT of kde uses glib-based libs
452 2013-12-03 13:49:55 <Diablo-D3> when it doesnt have a native qt one
453 2013-12-03 13:50:54 <Diablo-D3> Luke-Jr: gnome and kde both are dying out though
454 2013-12-03 13:51:51 <lclc> ok thanks wumpus
455 2013-12-03 13:52:18 <Luke-Jr> wumpus: are you really opposed to the format in https://github.com/bitcoin/bitcoin/pull/3229#discussion-diff-7551409 ? how would you want it?
456 2013-12-03 13:52:32 <Luke-Jr> Diablo-D3: my KDE runs just fine without any glib
457 2013-12-03 13:52:39 <wumpus> lclc: not sure what other popular RPC wire protocols far better in that regard
458 2013-12-03 13:52:47 <Diablo-D3> Luke-Jr: /me shrugs
459 2013-12-03 13:52:53 <Diablo-D3> Luke-Jr: FDO is about standards though
460 2013-12-03 13:53:03 <Diablo-D3> Luke-Jr: you can write a lib that complies to the standard and it works
461 2013-12-03 13:53:25 <Luke-Jr> Diablo-D3: if nobody participates or adopts it besides GNOME, it isn't a standard.
462 2013-12-03 13:53:35 <wumpus> Luke-Jr: I'll take a look
463 2013-12-03 13:54:04 <Diablo-D3> Luke-Jr: yes, but KDE adopts FDO standards
464 2013-12-03 13:54:10 <Diablo-D3> Luke-Jr: otherwise software doesnt work on kde
465 2013-12-03 13:54:17 <Diablo-D3> which is why FDO was created in the first place
466 2013-12-03 13:54:29 <wumpus> Luke-Jr: I think the && true is confusing, I would remove it
467 2013-12-03 13:54:45 <Luke-Jr> wumpus: how do I remove it without making it ugly formatted?
468 2013-12-03 13:55:01 <Diablo-D3> Luke-Jr: as I said though, kde and gnome are dead
469 2013-12-03 13:55:49 <Luke-Jr> wumpus: I'm looking at this from the angle of expecting a lot more mining options in the future; although I suppose any more and maybe using .count is non-ideal for performance reasons..
470 2013-12-03 13:56:32 <wumpus> Luke-Jr: ugly is a very personal opinion, in general I don't really care how you format it, but adding unneeded logical operators goes a bit far in making the code "pretty"
471 2013-12-03 13:56:58 <wumpus> Luke-Jr: and at least two other people had a 'wtf' response
472 2013-12-03 13:57:05 <Diablo-D3> wait
473 2013-12-03 13:57:10 <Diablo-D3> why the fuck would someone do && true
474 2013-12-03 13:57:24 <Diablo-D3> that'd always evaluate on the first term alone
475 2013-12-03 13:57:46 <Luke-Jr> wumpus: yeah, I see why it should be changed, just not sure a better alternative
476 2013-12-03 13:58:27 <wumpus> Luke-Jr: it's the same in makefiles... if you have a source file per line you can add \ at the end of the last source file, which makes it consistent but strange (...hey, the \ made me think another source file would follow)
477 2013-12-03 14:00:30 <wumpus> Diablo-D3: && true is a no-op as part of a logical conjunction, but it does confuse people, that's clear
478 2013-12-03 14:00:57 <Diablo-D3> wumpus: thats what I mean
479 2013-12-03 14:05:04 <wumpus> Luke-Jr: hmm yeah... I don't like the way we do lazy argument parsing, ie, parsing the arguments every time when the values are needed. I prefer parsing arguments at the start of the program and putting them in the appropriate places. This also allows for better error reporting for missing/extra options.
480 2013-12-03 14:05:14 <wumpus> Luke-Jr: then again, that's outside the scope of that pull request :)
481 2013-12-03 14:05:42 <Luke-Jr> indeed
482 2013-12-03 14:21:15 <iddo> amiller: ok thanks, i'll email them
483 2013-12-03 15:08:38 <rescrv> phantomcircuit: it doesn't need to be clear cut. Even if we read the man pages under your very narrow viewpoint, the msync would make it into the FS layer, at which point the next fdatasync/fsync will push it to disk, especially given the patches that use the OS X-specific method. So I don't know what point you are trying to make.
484 2013-12-03 15:10:53 <Luke-Jr> http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/
485 2013-12-03 15:11:01 <Luke-Jr> wow, can you say "full of crap"? XD
486 2013-12-03 15:12:07 <sipa> Luke-Jr: ironically, they have an entire section in the article to explain why this number is utterly meaningless...
487 2013-12-03 15:13:18 <Luke-Jr> sipa: I don't see it?
488 2013-12-03 15:13:55 <sipa> starts with: A few things I need point out about some of the potential problems with bitcoin networkâs 64 exaFLOPS number.
489 2013-12-03 15:14:16 <sipa> they don't say exactly that it's utterly meaningless, but they do give all arguments why it is :)
490 2013-12-03 15:17:41 <sipa> btw, i asked bitcoincharts.com to remove their petaflops number
491 2013-12-03 15:17:58 <sipa> they agreed, given a good explanation why it makes no sense they could put there instead
492 2013-12-03 15:18:14 <sipa> anyone feel like doing that?
493 2013-12-03 15:18:54 <quellhorst> can you check the balance of an external bitcoin address with bitcoind? (want to check the balance of a wallet that isn't mine)
494 2013-12-03 15:19:39 <Luke-Jr> sipa: send them http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/?commentId=comment_blogAndPostId/blog/comment/2179-2943-704 :P
495 2013-12-03 15:19:48 <sipa> quellhorst: no, addresses don't have a balance at the protocol level (bitcoin doesn't use balances internally, it's just wallets that exposes it that way)
496 2013-12-03 15:20:07 <sipa> quellhorst: and computing it requires keeping a transaction index for every address ever used
497 2013-12-03 15:20:35 <Luke-Jr> .. and that number is entirely meaningless, as addresses are not wallets
498 2013-12-03 15:22:39 <quellhorst> sipa: ok, then how do sites like blockchain.info get the balances?
499 2013-12-03 15:22:47 <sipa> by keeping a huge index
500 2013-12-03 15:23:25 <quellhorst> is there anything open source for that?
501 2013-12-03 15:23:34 <sipa> why do you need it?
502 2013-12-03 15:24:00 <quellhorst> wanted to have an independant system for checking balances of some offline wallets, for when they get deposits
503 2013-12-03 15:24:14 <quellhorst> and if they are certain amounts, then i'll kickoff some code
504 2013-12-03 15:24:28 <sipa> there are solutions that offer watch-only wallets
505 2013-12-03 15:24:38 <sipa> which track a balance for addresses that you don't have the key for
506 2013-12-03 15:24:46 <sipa> without needing to do so for every address ever used
507 2013-12-03 15:25:13 <quellhorst> do you know an answer to the first question?
508 2013-12-03 15:25:19 <quellhorst> open source version of blockchain.info
509 2013-12-03 15:25:26 <sipa> abe
510 2013-12-03 15:25:38 <sipa> but it's very resource intensive, afaik
511 2013-12-03 15:26:15 <quellhorst> you know if money-tree can do watch-only wallets?
512 2013-12-03 15:26:18 <lclc> an Electrum (or Obelisk) server might be enough
513 2013-12-03 15:26:29 <sipa> what is money-tree?
514 2013-12-03 15:27:01 <quellhorst> https://github.com/wink/money-tree
515 2013-12-03 15:38:02 <AdrianG> anyone here took a look at the mastercoin paper?
516 2013-12-03 15:55:28 <Luke-Jr> the tx mempool has an overflow limit, right? where is the code for that? O.o
517 2013-12-03 16:10:15 <CodeShark> it's not so trivial how to handle that
518 2013-12-03 16:10:45 <CodeShark> once you reach the max mempool size, do you just ignore new transactions until the mempool size shrinks? or do you start trashing some of them right away?
519 2013-12-03 16:10:46 <Luke-Jr> hrm, I thoguht it was already handled - it isn't?
520 2013-12-03 16:11:04 <CodeShark> trashing some of the old ones, that is
521 2013-12-03 16:11:13 <CodeShark> or perhaps trashing the lower priority ones?
522 2013-12-03 16:12:10 <CodeShark> CTxMemPool::accept is where the could should be in principle, no?