1 2013-08-13 01:30:03 <jgarzik> bitmessage uses xml-rpc? puke.
2 2013-08-13 01:53:52 <jgarzik> the Tor protocol is such crap
3 2013-08-13 01:59:29 <Cusipzzz> blasphemer! :)
4 2013-08-13 02:38:25 <jgarzik> slow blocks
5 2013-08-13 02:38:50 <jgarzik> ACTION turns on setgenerate, and sure enough, a block appears
6 2013-08-13 02:58:09 <Luke-Jr> lol
7 2013-08-13 03:00:49 <jgarzik> It is disappointing that the bitcoind coin chooser likes to split big coins, rather than gather up small coins
8 2013-08-13 03:04:36 <gmaxwell> jgarzik: it's easy to reverse that but you very rapidly get txn which are too big to be free. We need to change the rules for free txn to not count up to 200 bytes of per input. I have a patch... kind of afraid of shed painting, there is no perfect solution.
9 2013-08-13 03:05:10 <gmaxwell> jgarzik: as far as selection, you could also easily make a post selection pass to add additional inputs from the same 'taint group' as the exsting ones, one at a time until the txn is as large as it cares to make it.
10 2013-08-13 03:05:45 <gmaxwell> limiting it to the same taint group makes it less powerful, but means that its basically no compromise.
11 2013-08-13 03:06:37 <gmaxwell> it would also be nice to have a button to 'donate' all your really tiny inputs by creating a ANYONE_CAN_PAY|NONE signature for each of them and broadcasting it or sending it someplace where it can be merged by miners into sweeping transactions if there is free space left in their blocks.
12 2013-08-13 03:06:48 <gmaxwell> should be able to get rid of a lot of the 1e-8 outputs that way.
13 2013-08-13 03:07:02 <gmaxwell> also a lot of the other really small ones people seem to be sending for deanonymization purposes.
14 2013-08-13 03:09:56 <jgarzik> That would be nice. Spit out such a transaction, and give people an opportunity to clean that up.
15 2013-08-13 03:10:12 <jgarzik> Though even easier is "donate dust to miner", adding a couple dusts for each new transaction
16 2013-08-13 03:10:32 <jgarzik> "if tx < 5k, add dust up to 5k or donation limit"
17 2013-08-13 03:12:02 <jgarzik> or really even "if tx < 1k"
18 2013-08-13 03:14:51 <gmaxwell> even just a one time "hey, your wallet has a lot of dust??? you have 3213 outputs amounting to 0.000001 BTC. This dust slows down bitcoin for you and everyone else. [Get rid of this dust!] [I suck] [Are you my mommy?]" that just sends off a bunch of ANYONE_CAN_PAY|NONE to some collector running on bitcoin.org or something.. would probably reduce the utxo set size a lot.
19 2013-08-13 03:16:03 <gmaxwell> The other idea I had was a dust cleaning constest. Put out some tools for helping people clean dust... and give away some big prizes... like 1, 1, 1, 1, 10, 10 btc to some randomly selected destroyers of dust that was created say, before aug 1st.
20 2013-08-13 03:16:20 <gmaxwell> maybe even with the odds weighed by the inverse-bitcoin days destroyed.
21 2013-08-13 03:16:44 <gmaxwell> would cause people to go dig up old unused wallets full of SD dust and get it off the network.
22 2013-08-13 03:17:05 <gmaxwell> I think we we don't get people to destroy their old SD dust soon, a lot of it will become unrecoverable.
23 2013-08-13 03:17:16 <gmaxwell> (because the keys will be lost)
24 2013-08-13 03:17:19 <Luke-Jr> gmaxwell: hmm, so I should avoid cleaning dust until you have the contest? :P
25 2013-08-13 03:18:30 <gmaxwell> ACTION swats Luke-Jr
26 2013-08-13 03:18:42 <gmaxwell> I'm willing to bet you've already cleaned up all your really small dust. :P
27 2013-08-13 03:19:32 <Luke-Jr> unfortunately before Aug 1 :<
28 2013-08-13 03:21:30 <gmaxwell> I certantly don't have any.
29 2013-08-13 03:23:22 <jgarzik> ACTION still thinks pools should not create all-the-way-to-8-decimal-places payments
30 2013-08-13 03:23:45 <Luke-Jr> that's silly, and entirely unrelated to dust
31 2013-08-13 03:23:58 <gmaxwell> Luke-Jr: it makes people create dusty change though..
32 2013-08-13 03:24:02 <gmaxwell> and jagged change.
33 2013-08-13 03:24:03 <jgarzik> not entirely unrelated
34 2013-08-13 03:24:06 <Luke-Jr> gmaxwell: not really
35 2013-08-13 03:24:12 <jgarzik> yes really
36 2013-08-13 03:24:27 <Luke-Jr> jagged maybe, but that's harmless
37 2013-08-13 03:24:32 <gmaxwell> jgarzik: alternatively, a send button that knows how to round up to avoid change would be handy... e.g. when you're paying yourself. Make mtgox deal with the sharp coins.
38 2013-08-13 03:25:45 <gmaxwell> Luke-Jr: e.g. you pay me 1.002345678 BTC then I spend 1. now I have a .002345678 output that I'm never going to use. If coin selection was smarter perhaps it would add inputs (from the same taint group) to try to get the change closer in size to the real output or something and it would be less of an issue.
39 2013-08-13 03:26:15 <Luke-Jr> gmaxwell: only if your wallet is empty
40 2013-08-13 03:26:34 <gmaxwell> The two polar behaviors that are good is no change at all, and change which reflects your future spending sizes. Jagged doesn't help either of those.
41 2013-08-13 03:26:34 <Luke-Jr> gmaxwell: it WILL add more inputs to make the change >.01 BTC
42 2013-08-13 03:26:48 <jgarzik> if mtgox was smart, they would only trade in 1 BTC increments
43 2013-08-13 03:26:50 <Luke-Jr> and if it *can't* get change >.01 BTC, it will demand you use it as a fee
44 2013-08-13 03:26:57 <gmaxwell> Luke-Jr: I know.
45 2013-08-13 03:27:18 <jgarzik> currently people play silly games with fractional amounts @ mtgox. that was one way to game the system, overwhelming it with tiny orders.
46 2013-08-13 03:27:26 <gmaxwell> jgarzik: I thought they fixed that?
47 2013-08-13 03:29:02 <jgarzik> gmaxwell, The new trade engine should fix that, purportedly. Unsure if that was just-deployed or almost-deployed.
48 2013-08-13 03:32:16 <gmaxwell> Luke-Jr: also, "make my chage the size of my future transactions" is approximated by "make my change the size of the current transaction"??? and better approximations (like using your txn history) have privacy risks.
49 2013-08-13 03:38:52 <jgarzik> Windows people love defragging.
50 2013-08-13 03:38:59 <jgarzik> Have a "defragment wallet" button/dialog.
51 2013-08-13 03:39:10 <jgarzik> or "optimize"
52 2013-08-13 03:40:52 <gmaxwell> needs a visualization "coin fragmentation"
53 2013-08-13 03:41:20 <gmaxwell> [###.//_XXX/x-.x-@@_x-x-#####......##x-@_$@@]
54 2013-08-13 03:41:34 <gavinandresen> gmaxwell: a dust-cleaning contest is a great idea. Next deadline for foundation grants is 23-September if you're motivated enough to write a proposal
55 2013-08-13 03:41:50 <gmaxwell> gavinandresen: sounds like a plan.
56 2013-08-13 03:43:05 <Graet> oooh! visualization :D
57 2013-08-13 03:43:07 <Graet> >.>
58 2013-08-13 03:50:53 <warren> hmm, Mac OS X corruption issue?
59 2013-08-13 03:53:06 <gmaxwell> what about it?
60 2013-08-13 03:59:06 <warren> gmaxwell: curious if discussion about it is in any issue or PR.
61 2013-08-13 03:59:39 <warren> oh, found it: https://github.com/bitcoin/bitcoin/issues/2770
62 2013-08-13 03:59:52 <gmaxwell> warren: a bunch of people have reported it in a bunch of places, not just there.
63 2013-08-13 04:00:03 <gmaxwell> seems that one common trigger is suspending the system and waking it back up.
64 2013-08-13 04:00:35 <warren> ahhh
65 2013-08-13 04:01:04 <warren> thanks
66 2013-08-13 04:01:19 <gmaxwell> I'd take some WAG that OSX is corrupting mmaped files on suspend. More people looking at this would be good.
67 2013-08-13 04:01:50 <warren> I'll sic our OS X guy on it. He wanted more tasks assigned.
68 2013-08-13 04:02:09 <Diablo-D3> actually
69 2013-08-13 04:02:12 <Diablo-D3> WHICH suspend?
70 2013-08-13 04:02:17 <warren> good question
71 2013-08-13 04:02:30 <Diablo-D3> because osx with powernap is a completely different kind of suspend we probably could use
72 2013-08-13 04:03:12 <Diablo-D3> keep a bitcoind subprocess running that uploads and downloads chain shit
73 2013-08-13 04:03:18 <warren> gmaxwell: so the encrypted filesystem thing wasn't part of it, or not confirmed?
74 2013-08-13 04:03:24 <Diablo-D3> and osx does provide an API iirc to do events on power states
75 2013-08-13 04:03:34 <Diablo-D3> so even if it corrupts shit on suspend, we can just close all the files
76 2013-08-13 04:04:26 <gmaxwell> warren: don't think its relevant, but there could be multiple issues.
77 2013-08-13 04:05:11 <warren> after 0.8.0 was released we heard reports of Windows and btrfs index corruption on unclean shutdown, have those gone away?
78 2013-08-13 04:05:25 <warren> I haven't seen them in a long time now, personally.
79 2013-08-13 04:05:48 <gmaxwell> if not, they're pretty rare, there has been a couple instances of windows that really looked like they could have been hardware.
80 2013-08-13 04:06:05 <gmaxwell> we fixed some issues that could have been corrupting it on windows (running out of FDs)
81 2013-08-13 04:06:19 <warren> ah
82 2013-08-13 04:06:36 <gmaxwell> OSX is the big sore spot.
83 2013-08-13 04:07:13 <warren> Diablo-D3's idea of using OSX's suspend API to close things might be good, but it might also hide the real problem.
84 2013-08-13 04:07:44 <gmaxwell> yea, the real problem needs to get fixed in any case. unclean shutdowns are killing it too in OSX.
85 2013-08-13 04:08:00 <gmaxwell> or at least I've seen reports that suggested that to be the case.
86 2013-08-13 04:08:22 <warren> gmaxwell: I'm allocating part of our dev fund to a bug bounty for this. <amount> for a consistent reproduce procedure. <bigger amount> for a fix that passes bitcoin dev scrutiny and inclusion into master.
87 2013-08-13 04:08:47 <gmaxwell> warren: thank you!
88 2013-08-13 04:09:14 <warren> gavinandresen earlier mentioned that BF should create a bug bounty program, only they need a volunteer to coordinate it.
89 2013-08-13 04:09:20 <gmaxwell> I'd be appriciative if ltc could help with this, it's been an annoyance for a while and the overlap of good testers and OSX users isn't high.
90 2013-08-13 04:09:41 <gavinandresen> I did?
91 2013-08-13 04:09:51 <warren> gavinandresen, yeah, it was a while back?
92 2013-08-13 04:10:23 <Diablo-D3> [02:01:31] <warren> Diablo-D3's idea of using OSX's suspend API to close things might be good, but it might also hide the real problem.
93 2013-08-13 04:10:25 <Diablo-D3> it hides it BUT
94 2013-08-13 04:10:34 <Diablo-D3> at least it stops it until its fixed
95 2013-08-13 04:10:35 <gavinandresen> okey dokey. A grant for some person or group to award bounties for security issues in the protocol or reference implementation makes sense. I think.
96 2013-08-13 04:10:36 <Diablo-D3> and since its osx
97 2013-08-13 04:10:38 <Diablo-D3> it wont ever be fixed
98 2013-08-13 04:10:49 <gavinandresen> general bugs??? we've got plenty of those.
99 2013-08-13 04:10:53 <Diablo-D3> ACTION stares at apples opencl stack and glares
100 2013-08-13 04:12:07 <warren> corruption is a big general bug
101 2013-08-13 04:12:57 <warren> gavinandresen: would it be a good idea for <some entity> to have a bucket for mac users to donate to to increase incentive to find and fix the issue?
102 2013-08-13 04:13:28 <Diablo-D3> actually, we should be using power event APIs on every platform
103 2013-08-13 04:13:28 <gavinandresen> cool. Good experiment, I'll be very interested to see if setting a bounty gets the job done. Hard bit will be to figure out if code fixes "a" corruption issue or "the" corruption issue.
104 2013-08-13 04:13:40 <Diablo-D3> correctly close all the files, correctly close all the sockets, etc
105 2013-08-13 04:14:47 <gavinandresen> warren: dunno if it would be a good idea or not, never tried it. Have other projects had luck giving bounties for fixing bugs?
106 2013-08-13 04:14:47 <warren> gavinandresen: carefully defining the issue and bounty conditions would be important (I am not aware of the details myself, and I have no mac). Also the condition where "must be accepted by bitcoin devs into master and prove itself after subsequent testing to a release" may help.
107 2013-08-13 04:14:48 <gmaxwell> the obvious thing to do with this bounty is go to the leveldb upstream devs. :P
108 2013-08-13 04:15:04 <gmaxwell> perhaps the novelty of recieving bitcoin will get their attention
109 2013-08-13 04:15:18 <gmaxwell> *coin.
110 2013-08-13 04:15:34 <warren> I'm willing to offer some of our dev funds to even a consistent reproduce procedure. Bored non-devs can abuse their systems and figure that out.
111 2013-08-13 04:16:43 <jgarzik> meh, leveldb is so simple, just rewrite it, to fix the corruption problem :)
112 2013-08-13 04:17:05 <Diablo-D3> jgarzik: ORLY
113 2013-08-13 04:17:16 <Diablo-D3> I tried to write something like leveldb once
114 2013-08-13 04:17:19 <Diablo-D3> because I hated bdb
115 2013-08-13 04:17:25 <Diablo-D3> its not as simple as you think
116 2013-08-13 04:17:26 <warren> bdb isn't dead yet
117 2013-08-13 04:18:11 <toffoo> gmaxwell one data point for you here on your OSX corruption theory: in my case I literally NEVER shutdown or suspended my MacBook with bitcoin-qt running, so I am suspicious of that theory ??? but I did ALWAYS run it on an SSD drive with FileVault full disk encryption
118 2013-08-13 04:18:12 <warren> Given that nobody knows for sure how to consistently cause the corruption, that's the first step.
119 2013-08-13 04:18:35 <Diablo-D3> I also use an encrypted ssd in osx on 10.8
120 2013-08-13 04:18:39 <Diablo-D3> Ive never seen corruption
121 2013-08-13 04:19:02 <toffoo> Diablo-D3 which exact bitcoin-qt version are you on?
122 2013-08-13 04:19:08 <Diablo-D3> the newest one
123 2013-08-13 04:19:24 <warren> 0.8.2 and 0.8.3 are pretty much the same
124 2013-08-13 04:19:39 <Diablo-D3> I hate using it because the UI is fucked up
125 2013-08-13 04:19:48 <Diablo-D3> if I close the bitcoin window I cant reopen it
126 2013-08-13 04:19:54 <toffoo> that was supposed to be fixed
127 2013-08-13 04:20:00 <toffoo> in the latest one
128 2013-08-13 04:20:14 <toffoo> and from what I remember it was
129 2013-08-13 04:20:16 <Diablo-D3> I havent tried it
130 2013-08-13 04:22:00 <gmaxwell> toffoo: it's not unlikely that there are multiple triggers and perhaps multiple root causes.
131 2013-08-13 04:22:39 <toffoo> that makes perfect sense
132 2013-08-13 04:31:33 <toffoo> has there been any comment from the devs on that "satoshi patch in the blockchain" from earlier today?
133 2013-08-13 04:32:24 <jgarzik> yes
134 2013-08-13 04:34:01 <warren> whaaaa?
135 2013-08-13 04:34:21 <gavinandresen> warren: http://www.reddit.com/r/Bitcoin/comments/1k7ol2/an_interesting_transaction/
136 2013-08-13 04:35:01 <gavinandresen> If it ain't gpg signed, it almost certainly ain't Satoshi.
137 2013-08-13 04:35:35 <gmaxwell> yea. almost certantly not??? although I wasn't aware of the 16 bit opcode stuff. So that was at least amusing!
138 2013-08-13 04:37:26 <gmaxwell> But hey, if whomever it is wants to keep sending useful patches, sounds fine to me. He can call himself whatever he wants.
139 2013-08-13 04:37:50 <warren> although attribution of the commit is a big question mark
140 2013-08-13 04:38:31 <gmaxwell> warren: it's anonymous in any case. :P not exactly an attribution concern on pure code removal. :P
141 2013-08-13 04:38:43 <warren> heh
142 2013-08-13 04:38:45 <gmaxwell> warren: its a patch to the electrum code.
143 2013-08-13 04:38:52 <warren> I know.
144 2013-08-13 04:40:14 <gmaxwell> one point about weird txn is that eligius is now taking more of them, so we'll probably se more get mined.
145 2013-08-13 04:42:47 <gmaxwell> warren: when the patch was first linked to I went and posted it on the bct thread with my own decode of it. People then went and looked at bc.i and satoshi's email address was gone because of lack of HTML escaping. This made several people contact me, thinking that I was satoshi and goofed up and leaked it on BCT, kindly pointing it out and suggesting I quickly delete the post. (very kind and flattering of people!)
146 2013-08-13 04:42:58 <Luke-Jr> I think petertodd is credit for dealing with the relay issues
147 2013-08-13 04:43:49 <Luke-Jr> is to credit*
148 2013-08-13 04:46:50 <toffoo> has anyone tried following the burned coins? they look too new to be satoshi's ;D
149 2013-08-13 04:46:50 <warren> <gavinandresen> okey dokey. A grant for some person or group to award bounties for security issues in the protocol or reference implementation makes sense. I think.
150 2013-08-13 04:48:02 <petertodd> gmaxwell: "Wow Satoshi! You're coding skill have improved so much!"
151 2013-08-13 04:48:08 <warren> gavinandresen: I'd like to help coordinate this, although I'm severely oversubscribed now. This is also tough in that you need such person(s) to be privy to the responsible disclosure knowledge which could be a horribly tough burden.
152 2013-08-13 04:48:13 <warren> petertodd: heh
153 2013-08-13 04:49:34 <Luke-Jr> petertodd: but not your English! :p
154 2013-08-13 04:49:47 <petertodd> Luke-Jr: lol
155 2013-08-13 04:55:59 <warren> I'll propose to the LTC team about making a bounty for a reproduce procedure and maybe fix too. I strongly suggest the BTC community make a similar bounty. If BF isn't setup to fund it, then <someone trusted> should make a collection.
156 2013-08-13 04:56:22 <warren> Perhaps it's helpful enough to just identify how to corrupt it.
157 2013-08-13 04:56:27 <petertodd> Luke-Jr: by "dealing" all I did was bug you repeatedly :) though speaking of, think there would be value to having a second non-std relay node on the wiki?
158 2013-08-13 04:56:31 <gmaxwell> petertodd: you'll likely find the figures in this interesting: https://bitcointalk.org/index.php?topic=272709.msg2922718#msg2922718
159 2013-08-13 05:00:04 <gmaxwell> petertodd: in particular, they give an empirical delay vs blocksize for several points on the distribution.
160 2013-08-13 05:00:57 <gmaxwell> on the downside, all their data is pretty old.
161 2013-08-13 05:02:02 <gmaxwell> Luke-Jr: where is your old abandoned forward-block-before validation code?
162 2013-08-13 05:08:04 <Luke-Jr> ACTION wonders why 'git branch' takes 5 seconds to list his branches <.<
163 2013-08-13 05:08:15 <Luke-Jr> gmaxwell: fastblockrelay
164 2013-08-13 05:08:24 <Luke-Jr> gmaxwell: note it never actually worked due to socket stuff
165 2013-08-13 05:08:36 <Luke-Jr> petertodd: possibly
166 2013-08-13 05:13:53 <petertodd> Luke-Jr:gmaxwell: ironic that my internet connection died just as I was opening that...
167 2013-08-13 05:14:22 <petertodd> Luke-Jr: will do then
168 2013-08-13 05:20:56 <petertodd> 180???000 through 190???000 we get the distribution shown in
169 2013-08-13 05:20:56 <petertodd> "By extracting the timestamps from the blocks at height
170 2013-08-13 05:20:57 <petertodd> Figure 6."
171 2013-08-13 05:21:15 <petertodd> <- when was nTime rolling implemented?
172 2013-08-13 05:23:00 <gmaxwell> oh timestamps. :-/
173 2013-08-13 05:23:49 <petertodd> gmaxwell: pools make it even harder to get the data they want - propagation within the general p2p network may have little to do with propagation to majority hashing power
174 2013-08-13 05:25:57 <petertodd> I do like how they used a 4000 peer node to manipulate the width of the network
175 2013-08-13 05:26:08 <Luke-Jr> petertodd: to make things more fun, ntime rolling is to date not implemented consistently!
176 2013-08-13 05:26:28 <petertodd> Luke-Jr: so different windows?
177 2013-08-13 05:26:34 <Luke-Jr> petertodd: ?
178 2013-08-13 05:26:55 <gmaxwell> petertodd: yea that was that python block forwarder thing that also forwarded totally invalid stuff, weird that they didn't mention it getting DOSed from the network.
179 2013-08-13 05:27:21 <petertodd> Luke-Jr: IE my implementation rolls up to x seconds, yours y seconds
180 2013-08-13 05:27:40 <Luke-Jr> cgminer only rolls ntime for getwork, and not related to real time at all. BFGMiner does the same for getwork, but rolls time correctly for GBT and stratum. not sure where poclbm is on this now
181 2013-08-13 05:28:00 <petertodd> gmaxwell: Ah! Those guys.... So they didn't check anything at all?
182 2013-08-13 05:28:41 <gmaxwell> petertodd: diff1 was enough to make it through.
183 2013-08-13 05:28:50 <petertodd> gmaxwell: ...
184 2013-08-13 05:28:55 <gmaxwell> at least at one point.
185 2013-08-13 05:29:01 <petertodd> gmaxwell: heh
186 2013-08-13 05:29:45 <petertodd> Luke-Jr: right, what do you mean by "not related to real time at all" ?
187 2013-08-13 05:30:03 <Luke-Jr> petertodd: incremented just to produce new work
188 2013-08-13 05:30:20 <Luke-Jr> as opposed to incremented once a second
189 2013-08-13 05:30:39 <petertodd> Luke-Jr: ha!
190 2013-08-13 05:31:29 <gmaxwell> http://pastebin.com/Vz1V9H8d < is this too harsh?
191 2013-08-13 05:32:24 <petertodd> gmaxwell: no, that's a very good point to make
192 2013-08-13 05:33:08 <petertodd> gmaxwell: for Bitcoin the leading peer-reviewed journal is the email list and wizards
193 2013-08-13 05:33:11 <gmaxwell> I'm currently reviewing another paper, fwiw, which has 3/4 of its citations as logs here, and BCT and such.
194 2013-08-13 05:33:20 <petertodd> nice!
195 2013-08-13 05:34:11 <Luke-Jr> https://en.bitcoin.it/wiki/Talk:Hardfork_Wishlist#.27Permanent_Forwarding.27 <-- might need input from a third party
196 2013-08-13 05:35:17 <Luke-Jr> gmaxwell: there is still development that takes place on bitcointroll? O.o
197 2013-08-13 05:35:50 <petertodd> Luke-Jr: sure, just filter out everyone who doesn't have the "bitcoin expert" icon...
198 2013-08-13 05:36:04 <Luke-Jr> petertodd: is there an option for that? :oi
199 2013-08-13 05:36:47 <petertodd> Luke-Jr: too bad bitcoin wasn't designed such that address reuse was actually impossible, like lamport sigs do
200 2013-08-13 05:37:58 <Luke-Jr> petertodd: could still be done, sortof - just modify clients to reject sending to addresses they've seen
201 2013-08-13 05:38:21 <Luke-Jr> it wouldn't work 100% for non-full nodes, but would likely make it useless enough..
202 2013-08-13 05:38:28 <petertodd> Luke-Jr: sure, but that's not the same as actually making such stuff insecure
203 2013-08-13 05:38:54 <Luke-Jr> can we spec out a K selection that does this maybe?
204 2013-08-13 05:39:04 <petertodd> lol, good idea!
205 2013-08-13 05:39:16 <gmaxwell> Luke-Jr: I do think some priority logic that did that would be an interesting start. (priortize unseen addresses)
206 2013-08-13 05:39:16 <petertodd> K=Hash(scriptPubKey) would work
207 2013-08-13 05:39:28 <gmaxwell> petertodd: no, if K is known the game is over.
208 2013-08-13 05:39:42 <gmaxwell> (seems that I'm correcting everyone on that today)
209 2013-08-13 05:39:52 <petertodd> gmaxwell: oh, so what, it's R I'm talking about?
210 2013-08-13 05:40:13 <gmaxwell> petertodd: R is just K*g. when K gets reused the result is that you can recover K, knowing K you can recover the private key.
211 2013-08-13 05:40:28 <petertodd> gmaxwell: right, back to lamport then
212 2013-08-13 05:40:39 <Luke-Jr> gmaxwell: yeah, that's been on my todo list for a while.. kinda waiting for the child-pays-for-parent to get merged in some way or another
213 2013-08-13 05:41:04 <Luke-Jr> K = SHA256d(private key)
214 2013-08-13 05:41:08 <gmaxwell> Luke-Jr: even just rate limiting reuse inside a block would be an improvement, and an extra reason to advise against reuse.
215 2013-08-13 05:41:08 <Luke-Jr> :>
216 2013-08-13 05:41:24 <petertodd> Luke-Jr: yeah, sipa's doing changes that make my cpfp not worth working on for now given how much I'll need to modify
217 2013-08-13 05:41:45 <gmaxwell> Luke-Jr: I think you and petertodd are going too far here. To some extent??? anonymous tip jars, at least... reuse is a mostly harmless asset (though those things can be super down prioritized)
218 2013-08-13 05:41:51 <petertodd> Luke-Jr: accompanied by a zero-knowledge proof that K is actually sha256d...
219 2013-08-13 05:42:13 <Luke-Jr> gmaxwell: it's no longer an anonymous tip jar ;)
220 2013-08-13 05:42:31 <gmaxwell> yea I mean a different meaning of anonymous.
221 2013-08-13 05:42:37 <Luke-Jr> ah, ok I get that
222 2013-08-13 05:42:38 <gmaxwell> Where the transacting parties are arms-length.
223 2013-08-13 05:42:50 <Luke-Jr> gmaxwell: HD pubkeys could replace that need
224 2013-08-13 05:42:59 <Luke-Jr> made into an address form
225 2013-08-13 05:43:20 <petertodd> gmaxwell: right, but you can agree that if we had a reason to do something that made address re-use impossible, it wouldn't be a big deal
226 2013-08-13 05:43:24 <gmaxwell> It could certantly reduce that, yes. And I think thats a good step forward. Though even that??? what happens when two people read the address at once and send at once?
227 2013-08-13 05:43:37 <petertodd> Luke-Jr: problematic for SPV clients... which is why they wind up reusing addresses so much already :(
228 2013-08-13 05:43:58 <gmaxwell> petertodd: if we had a reason, and keeping that option open is one of the reasons to discourag reuse. (though dwarfed by fungibility risk)
229 2013-08-13 05:44:16 <Luke-Jr> hmm
230 2013-08-13 05:44:39 <Luke-Jr> gmaxwell: if the child number is based on the sender rather than incrementally..
231 2013-08-13 05:44:43 <gmaxwell> Though keep in mind, even lamport doesn't totally preclude reuse, you can make your lamport key really a hash tree of 1024 lamport keys. Now you can safely reuse 1024 times.
232 2013-08-13 05:44:52 <Luke-Jr> but then we need a way to identify them
233 2013-08-13 05:45:02 <petertodd> gmaxwell: sure, but then it's a merkle signature scheme
234 2013-08-13 05:45:15 <gmaxwell> Luke-Jr: yes, you should go see some of bytecoins pay-to-ECDH proposals. (where is bytecoin these days?)
235 2013-08-13 05:46:04 <petertodd> gmaxwell
236 2013-08-13 05:46:16 <gmaxwell> In any case, I'm convinced that we can adequately discourage reuse through carrots more than sticks, and sticks are just not viable when the public can't understand the benefits (and if they do, you don't need the sticks)
237 2013-08-13 05:46:24 <petertodd> gmaxwell: gah, read the whole paper and I can't see how to use their data to work out profitability of large vs. small blocks
238 2013-08-13 05:46:37 <petertodd> gmaxwell: amazed they don't seem to think of that
239 2013-08-13 05:47:11 <gmaxwell> petertodd: they give a delay per byte for large blocks "to a majority" (whatever that means). You can combined that with the PDF and compute the race odds.
240 2013-08-13 05:47:36 <gmaxwell> the bummer is that these are pre-ultraprune numbers.
241 2013-08-13 05:47:49 <petertodd> gmaxwell: oh right, although still not something I can just eyeball
242 2013-08-13 05:48:08 <gmaxwell> though I think post-signature cache.
243 2013-08-13 05:49:41 <gmaxwell> Things like good BIP32 addresses to allow addresses that don't get reused (much), payment protocol (uh and something like it that doesn't require a webserver :( ), priortizing non-reuse even if it's just recent non-reuse, changes to UI to not constantly direct people to old addresses (armory gets this right).... determinstic wallets for better backups..
244 2013-08-13 05:50:01 <gmaxwell> with that stuff I think we're well on the way to taming the worst of the reuse.
245 2013-08-13 05:50:29 <petertodd> oh, actually, maybe this is enough for the rough estimate: 80ms per additional 1KB to get to majority, so that's 80ms/600s = 0.00013 * 25BTC = 0.0033BTC/KB breakeven
246 2013-08-13 05:51:06 <petertodd> 0.001BTC/KB is probably roughly right with ultraprune improvements
247 2013-08-13 05:51:34 <gmaxwell> worse because the exponential distribution's median is less than the mean... there are more fast blocks.
248 2013-08-13 05:51:46 <petertodd> gmaxwell: right, median is 8 minutes?
249 2013-08-13 05:52:43 <gmaxwell> .69 * expectation, I think. though it is late.
250 2013-08-13 05:54:17 <petertodd> ok, so that works out to ~0.005BTC/KB break even, given that tx cost - inflation / txs - is 0.1BTC/tx that feels very roughly right
251 2013-08-13 05:55:20 <petertodd> so if anything, my p2pool node setting of 0.005BTC/KB are about right
252 2013-08-13 06:01:40 <Luke-Jr> ACTION ponders if sipa's address index can easily be used to blacklist any previously used address
253 2013-08-13 06:02:10 <petertodd> Luke-Jr: just do a big bloom filter with per-node keys
254 2013-08-13 06:02:15 <gmaxwell> Luke-Jr: I think it can, but I think thats too expensive and too harsh.
255 2013-08-13 06:02:30 <gmaxwell> Luke-Jr: just keep one of those limited capacity maps around and test transactions against addresses you've already seen.
256 2013-08-13 06:02:36 <Luke-Jr> gmaxwell: meh, Eligius is only 5%
257 2013-08-13 06:02:56 <Luke-Jr> I suppose merely filtering the mempool would work
258 2013-08-13 06:03:19 <gmaxwell> Luke-Jr: I'd like to encourage other people to run such a patch, maybe even make it a system default... though we could only do a minimally harsh version of it for that.
259 2013-08-13 06:04:55 <Luke-Jr> if we index the mempool by first output address, that'd save memory
260 2013-08-13 06:05:02 <Luke-Jr> (instead of by txid)
261 2013-08-13 06:05:07 <Luke-Jr> otoh, might not be practical
262 2013-08-13 06:06:17 <petertodd> Luke-Jr: mempool needs txid indexes for a few things
263 2013-08-13 06:07:48 <Luke-Jr> too bad inputs don't refer to coins by a hash of the output
264 2013-08-13 06:07:50 <petertodd> Oh, that reminds me: I was thinking it would have made more sense if signatures refered to txin's by H(scriptPubKey) rather than H(tx)
265 2013-08-13 06:07:55 <petertodd> er, exactly
266 2013-08-13 06:07:59 <Luke-Jr> that'd fix so many things..
267 2013-08-13 06:08:14 <petertodd> Yup, and it prohibits address reuse because you'd be able to reuse signatures.
268 2013-08-13 06:08:30 <petertodd> We can add ths with a new CHECKSIG...
269 2013-08-13 06:08:44 <Luke-Jr> we can?
270 2013-08-13 06:09:11 <Luke-Jr> I don't think it would work..
271 2013-08-13 06:09:18 <petertodd> Yes, make the has be of the scriptPubKeys, and leave the txid's in the tx itself as just a way to quickly find the scriptPubKeys in question.
272 2013-08-13 06:09:19 <Luke-Jr> short of a hardfork
273 2013-08-13 06:09:32 <petertodd> Nope, you can add any new opcode with a soft-fork.
274 2013-08-13 06:10:15 <Luke-Jr> hmm
275 2013-08-13 06:10:53 <petertodd> Specifically redefine OP_NOPn as OP_MAST and make OP_MAST fail the script if the inner script evaluation returns false, otherwise do nothing.
276 2013-08-13 06:11:00 <petertodd> s/MAST/EVAL/
277 2013-08-13 06:12:36 <Luke-Jr> petertodd: were you here for OP_EVAL? :p
278 2013-08-13 06:13:01 <petertodd> Luke-Jr: sort of... I was a bit distracted by second year calculus/analysis :)
279 2013-08-13 06:13:07 <petertodd> looked ugly...
280 2013-08-13 06:13:46 <gmaxwell> H(scriptpubkey) isn't unique.
281 2013-08-13 06:13:57 <petertodd> gmaxwell: It is if you don't re-use addresses...
282 2013-08-13 06:14:34 <petertodd> (obviously I'm handwaving a bit, you want to sign lists of scriptPubKeys like txids can be signed in various ways)
283 2013-08-13 06:14:51 <petertodd> (well, minimal is probably sets...)
284 2013-08-13 06:15:34 <gmaxwell> Yea, you're handwaving??? but sure this is what etotheipi really wants with his utxo stuff... otherwise it means >100% overhead on every mining node just to enable lazy wallets.
285 2013-08-13 06:16:12 <petertodd> Oh, how does this fit in with UTXO exactly? By removing the need to have txid's?
286 2013-08-13 06:16:38 <gmaxwell> I don't know if any kind of index on scriptpubkey is fundimentally sound, it instantly creates big benefits for reuse. I suppose, unless you preclude it.. and precluding it is darn tricky due to payment races on public addresses.
287 2013-08-13 06:17:16 <petertodd> gmaxwell: Well worse comes to worst you can always bodge in a nonce...
288 2013-08-13 06:17:34 <gmaxwell> petertodd: well, what he really wants is a utxo on scriptpubkeys so that lite wallets can just fetch all their transactions (hello huge reuse payoff!), so most of his writing is about commiting _that_ tree, which you can't use for validation, so oh yea on the side you need this extra one.
289 2013-08-13 06:17:57 <gmaxwell> petertodd: yea, and if you unique via a nonce then thats a huge benefits for reuse and all the fungiblity hazards that arise
290 2013-08-13 06:18:16 <petertodd> Yeah, and there is no soft-fork upgrade path that doesn't involve maintaining two tx indexes at some point.
291 2013-08-13 06:18:42 <gmaxwell> right, thats why I said what you were suggesting was what he really wanted, not what he can actually have. :P
292 2013-08-13 06:18:52 <petertodd> Yup... stupid Satoshi
293 2013-08-13 06:19:00 <gmaxwell> Smart smart satoshi.
294 2013-08-13 06:19:30 <gmaxwell> All these index by scripthash things superbly reward reuse, they're hazards to the system unless you've somehow perfected recovering fungiblity.
295 2013-08-13 06:19:33 <petertodd> Not smart enough! You can't even beat a half dozen experts with years of experience who spend hours every week.
296 2013-08-13 06:19:59 <gmaxwell> ACTION runs sloccount ... still beating you and I
297 2013-08-13 06:20:00 <petertodd> gmaxwell: Unless you make CHECKSIG work on scriptPubKeys so address reuse can't work...
298 2013-08-13 06:20:37 <petertodd> gmaxwell: Is there anyone who doesn't beat me? :P
299 2013-08-13 06:21:10 <warren> I guess we'll offer 133.7 LTC for a reproduce procedure, just to be lame.
300 2013-08-13 06:21:18 <gmaxwell> I mean, you can't have it both ways??? you either have the payment race or you have no reuse at all. A nonce can't help you, since it creates functional reuse.
301 2013-08-13 06:21:21 <petertodd> warren: lol
302 2013-08-13 06:21:37 <petertodd> warren: oh, make it a P2SH addr for donations, so you can advertise the same addr on LTC and BTC
303 2013-08-13 06:21:59 <warren> petertodd: I will not manage the Bitcoin donation bucket for the bug
304 2013-08-13 06:22:03 <gmaxwell> ... can you not distinguish a p2pool p2sh from a bitcoin one???
305 2013-08-13 06:22:15 <warren> petertodd: someone trusted in the bitcoin community should do that
306 2013-08-13 06:22:38 <petertodd> gmaxwell: right, the only real solution is payment protocols, like... oh wait, send to ip! :P
307 2013-08-13 06:22:51 <petertodd> gmaxwell: someone didn't read my audit report in full :)
308 2013-08-13 06:23:02 <warren> ACTION facepalm.
309 2013-08-13 06:23:07 <gmaxwell> :P
310 2013-08-13 06:23:30 <petertodd> warren: feel free to use me on that actually - I don't have a Mac... :)
311 2013-08-13 06:23:40 <warren> I should have included a verbosity penalty clause in the contract.
312 2013-08-13 06:23:44 <gmaxwell> I read part and told 10 other people to read it. :P
313 2013-08-13 06:24:05 <gmaxwell> reading the rest is in my queue, but its like eight things back.
314 2013-08-13 06:24:18 <warren> LIFO queue?
315 2013-08-13 06:25:00 <petertodd> gmaxwell: Pff, I only had 114 source code comments - spread amongst 2.3MB of diffs...
316 2013-08-13 06:25:24 <warren> petertodd: I don't want to be responsible for a LTC donation bucket for that either. Tax reasons.
317 2013-08-13 06:25:45 <petertodd> warren: as I said, your complaints were noted and filed in triplicate
318 2013-08-13 06:26:02 <petertodd> warren: huh, what's the tax implication?
319 2013-08-13 06:26:23 <warren> petertodd: the unknown from lack of guidance makes it a headache that I rather avoid entirely
320 2013-08-13 06:26:51 <petertodd> warren: If it's P2SH multisig from a few different parties hopefully they can all claim arms-length
321 2013-08-13 06:27:12 <gmaxwell> ouch: https://bitcointalk.org/index.php?topic=272709.msg2923046#msg2923046
322 2013-08-13 06:27:20 <gmaxwell> that was the comment I was trying _not_ to leave.
323 2013-08-13 06:27:26 <petertodd> warren: and we need to push people to actually support p2sh...
324 2013-08-13 06:27:37 <warren> petertodd: people who care about the issue will run away if you make it hard
325 2013-08-13 06:27:42 <gmaxwell> (I've PMed him and asked if he could please try to tone it down a little)
326 2013-08-13 06:28:08 <petertodd> gmaxwell: agreed, it's very non-obvious if you are an academic that the thing to do is start citing IRC logs...
327 2013-08-13 06:28:32 <petertodd> warren: Heh, LTC is lucky because there are fewer wallets...
328 2013-08-13 06:28:54 <petertodd> warren: Though really, just provide both, and have the most trusted person move funds to the P2SH one as they come in.
329 2013-08-13 06:28:57 <gmaxwell> well, CDecker is active on the forum, and has been in here too
330 2013-08-13 06:29:04 <gmaxwell> actually, he's here right now.
331 2013-08-13 06:29:17 <gmaxwell> But don't confuse stupitiy with malice, etc.
332 2013-08-13 06:29:31 <petertodd> yup
333 2013-08-13 06:29:32 <warren> (I'd like to know the Bluebook citation format for "some guy on IRC" myself ...)
334 2013-08-13 06:29:54 <gmaxwell> warren: I can show you examples from other papers, I'm reviewing one now that cites this channel.
335 2013-08-13 06:30:11 <warren> hahaha
336 2013-08-13 06:30:20 <gmaxwell> (they cite the public logs of it as a webpage??? pretty reasonable)
337 2013-08-13 06:30:29 <warren> I search Google for "Bluebook citation IRC" and it finds "Internal revenue Code".
338 2013-08-13 06:30:31 <petertodd> That's a big part of why I use my full name here...
339 2013-08-13 06:31:31 <Luke-Jr> gmaxwell: is it really plagerism if nobody took the time to do formal research?
340 2013-08-13 06:33:33 <Luke-Jr> (although I agree they should have done proper research to see the solutions were already thought of, it's something different than plagerism IMO)
341 2013-08-13 06:34:24 <gmaxwell> Luke-Jr: It's a bad pratice to have failed to do the research, at least. I don't think you or I should care about the details beyond "hey, you didn't do the research, and failed to cite the people actually implementing this". Academic notions of plagerism can be odd and probably are beyond the conception of people outside of those deep professional ratholes.
342 2013-08-13 06:34:52 <petertodd> Besides, no sense scaring them off...
343 2013-08-13 06:35:25 <warren> gmaxwell: I'd appreciation citation examples in any format.
344 2013-08-13 06:35:29 <warren> errr
345 2013-08-13 06:35:37 <warren> grammar fail means I need sleep
346 2013-08-13 06:36:15 <Luke-Jr> for me, grammar fail means I've rephrased what I was going to say :p
347 2013-08-13 06:37:20 <Luke-Jr> except when I intentionally the verb.
348 2013-08-13 06:39:41 <warren> petertodd: I have more important things to do right now, but if we go public with an offer of "reproduce procedure bounty" you want to manage the donation buckets?
349 2013-08-13 06:40:08 <petertodd> heh, funny, the "satoshi patch" timestamp has timezone -0200, which is used by the Grytviken, South Georgia and the South Sandwich Islands and Fernando de Noronha, Brazil - population 3000 for Fernando and some scientists and a postmaster for the other... highly likely to be faked :)
350 2013-08-13 06:40:26 <petertodd> warren: Only if I'm in a 2-of-3 or something
351 2013-08-13 06:40:33 <warren> (Please no P2SH and complications in it. Just be a trusted entity to send money to.)
352 2013-08-13 06:40:38 <warren> ugh
353 2013-08-13 06:41:10 <Luke-Jr> lol
354 2013-08-13 06:41:13 <petertodd> I have zero desire to take full responsibility, not to mention the bus problem...
355 2013-08-13 06:41:18 <warren> bus?
356 2013-08-13 06:41:26 <petertodd> getting hit by one :)
357 2013-08-13 06:41:30 <warren> oh
358 2013-08-13 06:42:44 <warren> I suppose the bounty is also an experiment if this kind of incentive works at all.
359 2013-08-13 06:44:02 <petertodd> Luke-Jr: too bad though, it's not obviously wrong either, say by the tx block timestamp - maybe satoshi took his millions and bought an island?
360 2013-08-13 06:44:16 <petertodd> Luke-Jr: with promised bitcoins...
361 2013-08-13 06:44:38 <petertodd> warren: Yeah, I mean, if it was *purely* an experiment, I might consider being responsible, but these things have a way of growing.
362 2013-08-13 06:45:33 <Luke-Jr> it's more fun as a multisig experiment/proof-of-concept IMO :P
363 2013-08-13 06:45:55 <Luke-Jr> do we have enough people for a 12-of-20 or something?
364 2013-08-13 06:46:01 <petertodd> heh, get jgarzik in on it and it can be a demo for bitpay!
365 2013-08-13 06:46:21 <petertodd> Luke-Jr: speaking of, did you know that P2SH multisig *isn't* bound by the n-of-3 rule?
366 2013-08-13 06:46:38 <petertodd> Luke-Jr: IsStandard() only enforces up to 3 on bare checkmultisig
367 2013-08-13 06:46:58 <petertodd> Luke-Jr: though scriptSig size is a problem if you go crazy...
368 2013-08-13 06:47:13 <t7> i was gonna say, thats gonna be a huge script
369 2013-08-13 06:48:00 <warren> petertodd: this is a pretty narrow experiment
370 2013-08-13 06:48:23 <petertodd> warren: my desire to hold on to other's money is also narrow :)
371 2013-08-13 06:49:11 <petertodd> warren: anyway, I can always be the trusted guy with the privkey to the regular donation addr, and send the funds to a p2sh between me and two others, or soemthing
372 2013-08-13 06:50:14 <Luke-Jr> petertodd: really? :o
373 2013-08-13 06:51:19 <petertodd> Luke-Jr: you tell people the regulat donation addr is what you should use if you absolutely can't send to the p2sh addr because your wallet sucks
374 2013-08-13 06:55:13 <shesek> does blockchain.info handle p2sh addresses incorrectly?
375 2013-08-13 06:55:17 <shesek> http://blockchain.info/tx/b1801e3cff2fe001ba26453224beef2c26ede8a29b828346c893dd8c905d6098
376 2013-08-13 06:55:58 <petertodd> shesek: last I remembered their wallet still didn't, although hilariously send-shared will send to P2SH
377 2013-08-13 06:56:01 <shesek> it says the transaction is paid to 3JNaZ9A1yMpRTGyoG9Vq9MvvjKcECYbSoo, while my bitcoind says its 3FB2DitED3VT1rWjnMkd6LFpdYS36oCWcH
378 2013-08-13 06:56:21 <shesek> bitcoind decoderawtransaction `bitcoind getrawtransaction b1801e3cff2fe001ba26453224beef2c26ede8a29b828346c893dd8c905d6098` yields 3FB2DitED3VT1rWjnMkd6LFpdYS36oCWcH
379 2013-08-13 06:56:47 <Luke-Jr> petertodd: I was responding to [08:40:36] <petertodd> Luke-Jr: speaking of, did you know that P2SH multisig *isn't* bound by the n-of-3 rule?
380 2013-08-13 06:56:47 <petertodd> oh! someone screwed up...
381 2013-08-13 06:56:48 <shesek> not their wallet, I want to use their API
382 2013-08-13 06:57:18 <petertodd> Luke-Jr: ah, yeah, look in IsStandard() for how the n-of-3 rule is applied
383 2013-08-13 06:57:42 <petertodd> shesek: pretty sure something is broken there...
384 2013-08-13 06:58:15 <shesek> petertodd, hmm... that sucks. I was kinda counting on their API for this project I'm working on :O
385 2013-08-13 06:59:40 <Luke-Jr> shesek: I wouldn't advise using bc.i for anything :/
386 2013-08-13 07:00:12 <shesek> Luke-Jr, is there an alternative you would recommend?
387 2013-08-13 07:00:36 <shesek> I looked into webbtc, but they don't support multisig and don't have SSL
388 2013-08-13 07:00:42 <petertodd> looks like sometimes it does work: https://blockchain.info/address/3CXBefgyf8PytgJbu1o6Vrgme2LRtAxi1e
389 2013-08-13 07:00:51 <petertodd> although the firstbits is wrong
390 2013-08-13 07:01:20 <shesek> I need an api for: a. loading unspent inputs of an p2sh address and b. broadcasting raw transactions
391 2013-08-13 07:01:38 <Luke-Jr> shesek: alternative for what?
392 2013-08-13 07:01:47 <shesek> Luke-Jr, bc.i
393 2013-08-13 07:01:59 <Luke-Jr> "loading unspent inputs of an p2sh address" ?
394 2013-08-13 07:02:08 <petertodd> shesek: BTW, please report the issue you are seeing to piuk
395 2013-08-13 07:02:17 <petertodd> shesek: that's a really serious problem
396 2013-08-13 07:02:25 <shesek> how do I contact piuk?
397 2013-08-13 07:02:36 <Luke-Jr> email
398 2013-08-13 07:02:51 <shesek> Luke-Jr, well... load a list of all the inputs the p2sh address has, that are unspent
399 2013-08-13 07:02:56 <Luke-Jr> shesek: if you are putting all the private keys of a P2SH on one system, you are Doing It Wrong???
400 2013-08-13 07:03:09 <shesek> Luke-Jr, who said I'm doing that?
401 2013-08-13 07:03:10 <Luke-Jr> shesek: that sounds like something for a library..
402 2013-08-13 07:03:48 <shesek> I prefer to avoid running my own bitcoin server for now and rely on 3rd party apis
403 2013-08-13 07:05:31 <shesek> petertodd, I can't seem to find an email on the website
404 2013-08-13 07:06:01 <shesek> their support page says to open an issue on github for website bugs, but I'm not quite sure on which repository
405 2013-08-13 07:06:09 <petertodd> there's a support form thing right? I've used that before and it is answered
406 2013-08-13 07:06:15 <petertodd> or just msg piuk on bitcointalk.org
407 2013-08-13 07:06:32 <petertodd> oh, actualy in this case, post to the public blockchain.info thread so others see it
408 2013-08-13 07:07:10 <shesek> will he notice it there?
409 2013-08-13 07:07:21 <petertodd> yes
410 2013-08-13 07:09:27 <shesek> "After registering, you will be unable to post in any section except "newbies" until you have spent some time on the forum and have published a few posts."
411 2013-08-13 07:09:49 <shesek> :-\\
412 2013-08-13 07:09:57 <petertodd> msg him then
413 2013-08-13 07:10:23 <petertodd> you can also just post in the "whitelist requests" thread saying you need to post in that thread - explain why so you don't look like a newbie :)
414 2013-08-13 07:12:56 <shesek> "You are not allowed to send personal messages"
415 2013-08-13 07:13:01 <shesek> I'll try to request a whitelist
416 2013-08-13 07:13:04 <petertodd> yeah
417 2013-08-13 07:13:23 <kinlo> there are some mods here that can help you :)
418 2013-08-13 07:13:28 <kinlo> gmaxwell: ping? :)
419 2013-08-13 07:14:49 <gmaxwell> shesek: what account?
420 2013-08-13 07:14:58 <shesek> gmaxwell, shesek
421 2013-08-13 07:15:09 <gmaxwell> whitelisted.
422 2013-08-13 07:15:14 <shesek> thanks :)
423 2013-08-13 07:30:43 <Happzz> if i import a private key to bitcoin-qt, and leave it like that for a while, will bitcoin-qt eventually move money to that address (as a change or whatever), or will it only do that for "internal" addresses
424 2013-08-13 07:31:00 <sipa> bitcoin-qt on its own never reuses an address
425 2013-08-13 07:31:11 <sipa> it will only move change to new addresses, fetched from the key pool
426 2013-08-13 07:47:28 <TD> good morning
427 2013-08-13 08:24:59 <Happzz> sipa is bitcoin-qt's algorithm of what to spend when sending money documented anywhere? like, if i have 10 addresses with different sums from different times - what will bitcoin-qt spend first?
428 2013-08-13 08:34:00 <phantomcircuit> Happzz, sure... in the code
429 2013-08-13 08:34:05 <phantomcircuit> it's partially random though so
430 2013-08-13 08:38:41 <sipa> Happzz: there is no such thing as "addresses with sums"
431 2013-08-13 08:38:51 <sipa> Happzz: it's just coins; what address those are assigned to, is irrelevant
432 2013-08-13 08:39:00 <sipa> and it will first consider coins that have >6 confirmations
433 2013-08-13 08:39:15 <sipa> and if that doesn't result in a solution, it tries using newer ones
434 2013-08-13 08:42:13 <grau> sipa: BTW should coin selection not prefer aggregation to reduce UTXO
435 2013-08-13 08:42:16 <grau> ?
436 2013-08-13 08:42:49 <gmaxwell> there are a bunch of tradeoffs here, and the code in question has not been changed in a long time.
437 2013-08-13 08:43:03 <gmaxwell> other behavior would be much better. _which_ other behavior is a complicated question.
438 2013-08-13 08:43:40 <gmaxwell> Overly agressive aggregation could destroy user privacy (uh, though if addresses are reused, the current behavior also destroys privacy)
439 2013-08-13 08:44:27 <Luke-Jr> gmaxwell: more-than-overly aggressive aggregation restores it :p
440 2013-08-13 08:44:36 <gmaxwell> aggregating a lot will result in big transactions that pay high fees, etc. so there are some tradeoffs.
441 2013-08-13 08:45:35 <warren> petertodd: I'll find someone else to make it simple.
442 2013-08-13 08:45:38 <grau> the fees will be there sooner or later if wallet is fragmented
443 2013-08-13 08:46:19 <grau> it might even be economical to aggregate in big tx
444 2013-08-13 08:46:39 <Luke-Jr> grau: on the other end, if the wallet isn't fragmented enough, you also end up with fees
445 2013-08-13 08:46:59 <gmaxwell> grau: yes, you want to aggregate towards output sizes which will be useful to you in the future.
446 2013-08-13 08:47:18 <grau> so have a logarithmic target fragmentation
447 2013-08-13 08:47:37 <grau> just like change in real coins
448 2013-08-13 08:48:10 <gmaxwell> optimal coin size selection is actually a really fun area of math, and not quite applicable to us with highly fractional coins. :P
449 2013-08-13 08:48:14 <gmaxwell> but yea.
450 2013-08-13 08:48:38 <sipa> the are just many concerns... privacy, price, network load, blockchain load, UTXO load
451 2013-08-13 08:48:53 <sipa> several of which are shared among all users of the system
452 2013-08-13 08:48:55 <gmaxwell> So now you want to agregate as much as you can, subject to not hurting privacy too much, and not producing txn that are totally too big, but only so much that you get change that follows some octave distribution.....
453 2013-08-13 08:49:22 <gmaxwell> (^ that isn't sounding much like a specification, alas)
454 2013-08-13 08:54:27 <grau> The maximum aggregation is well defined and is optimal for the network. The no aggregation is well defined and is optimal for privacy. What about randomly choosing between the two.
455 2013-08-13 08:55:13 <gmaxwell> random sounds kind of pessimal. :P
456 2013-08-13 08:55:24 <gmaxwell> sometimes privacy is perhaps worse than never. :P
457 2013-08-13 08:56:12 <gmaxwell> some privacy properties are well defined: coins paid to the same address or which have ever been commonly used in a single transaction are not considered private relative to each other, you can aggregate all those with no great privacy consequence.
458 2013-08-13 08:56:20 <grau> then lets give the random choice a parameter, so user can tilt between privacy and cost (since no aggregation will incure high cost over time)
459 2013-08-13 08:57:07 <gmaxwell> is it the case that maximum aggregation is network optimal? thats not clear to me. one transactio which produces change which is spent exactly with a single input later is better than constantly rolling foward.
460 2013-08-13 08:57:24 <gmaxwell> oh also another point, privacy is actually very important for the network not just the user.
461 2013-08-13 08:58:20 <grau> maximum aggregation means minimum UTXO, I do not see how that would not be technically optimal for the network.
462 2013-08-13 08:58:22 <gmaxwell> If users lose their privacy: (1) their idenfiability hurts the privacy of other users, (2) incentives are created to ask businesses or miners to block certian parties (the fungibility of bitcoin is degraded). This is kind of an aside, but I wanted to point out that its not just user vs network tension here.
463 2013-08-13 08:59:26 <TD> it's bad for a more prosaic reason - it leaks a part of your balance to whoever you spend it to
464 2013-08-13 08:59:37 <gmaxwell> So it actually important to provide _more_ privacy than an indifferent user may want, in order to respect the privacy of their trading partners and the fungibility of the coin overall.
465 2013-08-13 08:59:43 <grau> So what about having target denominations, that is actually the logarithmic model
466 2013-08-13 08:59:49 <gmaxwell> TD: http://www.cs.uwaterloo.ca/~shallit/Papers/change2.pdf I've never seen a paper on exactly our denomination problem.
467 2013-08-13 08:59:59 <gmaxwell> everything else is on integer value currencies. :P
468 2013-08-13 09:00:12 <grau> well we could limit the tilt between privacy and aggregation, so people do not make extreme choices.
469 2013-08-13 09:01:01 <gmaxwell> grau: it's probably fine, .. hm. making the same mix (rather than customizing the denominations extensively) for all users might have good privacy properties.
470 2013-08-13 09:01:06 <gmaxwell> or, as I said, achieve the maximum aggregation permitted by some privacy (and transaction size) constraints.
471 2013-08-13 09:01:23 <TD> yeah
472 2013-08-13 09:01:36 <TD> i was thinking of trying to make bitcoinj aim for 1, 5, 10, 20, 50, 100 etc sized outputs
473 2013-08-13 09:01:39 <TD> (with fractions of that as well)
474 2013-08-13 09:01:40 <grau> it could be simply transaction cost constraint, that people would also better understand
475 2013-08-13 09:01:48 <TD> but it's hard.
476 2013-08-13 09:01:52 <TD> you also want to request payments in those denominations
477 2013-08-13 09:01:53 <grau> aggregate until certain cost of tx not exceeded
478 2013-08-13 09:01:54 <gmaxwell> eventually spends that are larger than any privacy isolated group will have no choice but to merge them, at that point they can aggregate.
479 2013-08-13 09:01:57 <gmaxwell> i'd previously thought that what it should do is just make change similar in size to outputs, with the rational that it hides the output value the most, and it produces outputs of the size you spend.
480 2013-08-13 09:02:10 <gmaxwell> well, you can't relay txn over 100kb. But sure, a lower fee constraint could work as well.
481 2013-08-13 09:02:11 <TD> that way you can avoid transactions ever being linked, as long as your recipient is OK with receiving a single logical payment through several independent txns
482 2013-08-13 09:02:22 <grau> With BIP32 one could even have sub-accounts for the different denominations, so also use the hierarchy to protect higher coins
483 2013-08-13 09:02:55 <gmaxwell> grau: one problem w/ privacy is that people currently attack bitcoin user's privacy by sending them very tiny payments to old addresses in order to see how addresses link up.
484 2013-08-13 09:03:06 <grau> a subset of the wallet with small coins could be on the mobile e.g.
485 2013-08-13 09:03:07 <gmaxwell> grau: complicates enumeration, also the UI model for seperated security is hard.
486 2013-08-13 09:03:21 <gmaxwell> perhaps.
487 2013-08-13 09:03:25 <michagogo> [13:59:58] <gmaxwell> everything else is on integer value currencies. :P
488 2013-08-13 09:03:25 <michagogo> Well, so are we :-P
489 2013-08-13 09:03:45 <sipa> my idea was this: look at how many digits precision the actual output has, and create change outputs with the same number of digits, but scaled differently
490 2013-08-13 09:03:48 <gmaxwell> michagogo: yea so we'll have 1 satoshi outputs, and 5, and 10, and 18, and 20...
491 2013-08-13 09:04:04 <grau> now I understend those gifts.
492 2013-08-13 09:04:04 <TD> i was talking about this with sipa at lunch the other day
493 2013-08-13 09:04:14 <TD> ideally you want to treat outputs as if they were almost like metal coins, in various sized denominations
494 2013-08-13 09:04:15 <sipa> so if your change output is 0.13, maybe aim for a 2.4 and a 0.057 change
495 2013-08-13 09:04:30 <gmaxwell> sipa: pools contantly pay with alll the digits. :(
496 2013-08-13 09:04:33 <gmaxwell> oh, another point, making very very high value utxo is probably not a great idea. It increases the risk that a cosmic ray will make you lose a ton of coin, and it attracts journalists and theieves. :)
497 2013-08-13 09:04:46 <gmaxwell> (well even generations are pretty jagged these days too)
498 2013-08-13 09:04:55 <sipa> yeah
499 2013-08-13 09:05:19 <sipa> it only really works when an entire economy runs on bitcoin i guess, and people like easy numbers
500 2013-08-13 09:05:37 <sipa> and aren't tonal
501 2013-08-13 09:06:04 <gmaxwell> personally I'd like the ability to (1) round up payments to some destinations to get whole coins without change, (2) send small amounts of change jaggies to fees, if under some threshold (like 1 cent per txn)
502 2013-08-13 09:06:36 <gmaxwell> but I think thats mostly orthorgonal, though it also addresses some of the same issues.
503 2013-08-13 09:12:08 <TD> ye gods
504 2013-08-13 09:12:15 <TD> some users are receiving micropayments from enormous transactions
505 2013-08-13 09:12:27 <TD> i need to implement partial tx storage soon
506 2013-08-13 09:13:25 <gmaxwell> TD: thats what most of those deanonymizing dust things are.. stupid transactions with ten kazillion 0.000001 outputs or whatever
507 2013-08-13 09:13:51 <michagogo> ?
508 2013-08-13 09:13:51 <michagogo> I thought those don't get relayed anymore
509 2013-08-13 09:14:27 <TD> https://blockchain.info/tx/093435cea5d4627c3e4a154fa13153938561f80f128f5cbf51b73db63a7091df
510 2013-08-13 09:14:29 <TD> that's ridiculous
511 2013-08-13 09:16:20 <gmaxwell> michagogo: they're high enough to get relayed.
512 2013-08-13 09:16:35 <gmaxwell> see the ones there are the absolute minimum value outputs we'll relay now.
513 2013-08-13 09:16:49 <gmaxwell> notice that a bunch are spent.
514 2013-08-13 09:16:51 <grau> One nice property of having a BIP32 wallet that I no longer accidentally mix funds of different sources as the are all separated in sub accounts.
515 2013-08-13 09:16:54 <gmaxwell> 1001 users deanonymized and counting!
516 2013-08-13 09:17:17 <sturles> Is it possible to just donate a txout as a fee without creating an unspendable transaction? I have this 0.00000006 output which is just sitting there as an annoyance. Uneconomical to spend, but a miner may want to pick it up and add it as a fee.
517 2013-08-13 09:17:55 <TD> you can spend it entirely to fees
518 2013-08-13 09:17:59 <TD> with a prunable output, no less
519 2013-08-13 09:18:19 <sturles> How?
520 2013-08-13 09:18:21 <gmaxwell> sturles: if you create a transaction and sing with ANYONE_CAN_PAY|NONE then someone could merge it.
521 2013-08-13 09:18:23 <michagogo> sturles: Well, you *could* send it along with another transaction
522 2013-08-13 09:18:43 <gmaxwell> s/sing/sign/
523 2013-08-13 09:18:43 <michagogo> Like I did the other day with e9d64a4737fa2070649e240f7c26185b0907011a20f843ae16239c6353d8ec70-000
524 2013-08-13 09:18:44 <sturles> I wish the client would do that.
525 2013-08-13 09:18:58 <michagogo> Er, e9d64a4737fa2070649e240f7c26185b0907011a20f843ae16239c6353d8ec70
526 2013-08-13 09:19:04 <sturles> It just sits there with 20k confirmations.
527 2013-08-13 09:19:48 <gmaxwell> sturles: listunspent, find it, create raw transaction.. pay it to whatever you want. then signrawtransaction hex "null" "null" "NONE|ANYONECANPAY"
528 2013-08-13 09:19:52 <sturles> I would be very happy if the client picked it up and spent it with some other transaction. Adding it to a larger piece of change.
529 2013-08-13 09:20:05 <gmaxwell> and then give it to petertodd because he's probably the only person that would bother actually merging it with something. :P
530 2013-08-13 09:20:16 <sturles> Hehe
531 2013-08-13 09:20:40 <sturles> Probably won't get accepted by my own client due to the small output?
532 2013-08-13 09:20:41 <gmaxwell> sturles: well it can, it just hasn't. If you use the coincontrol patches you can force it to spend it.
533 2013-08-13 09:21:15 <gmaxwell> sturles: right. because its a NONE|ANYONECANPAY anyone else could take your signature and bind it into a transaction with totally different inputs and outputs.
534 2013-08-13 09:21:26 <gmaxwell> NONE|ANYONECANPAY = give away my input.
535 2013-08-13 09:21:36 <sturles> I wish it would just do that without me forcing it to. Just add it to some transaction which is small enough to not require a fee anyway.
536 2013-08-13 09:21:40 <knotwork_> I pulled latest github and it is sticking on block 251021 hour after hour, log keeps saying mapOrphan overflow, removed 1 tx does that mean it is overflowed with orphans and has no room to store more?
537 2013-08-13 09:22:01 <gmaxwell> knotwork_: that message is irrelevant.
538 2013-08-13 09:22:05 <gmaxwell> ;;bc,blocks
539 2013-08-13 09:22:05 <gribble> 251940
540 2013-08-13 09:22:14 <gmaxwell> ;;tslb
541 2013-08-13 09:22:15 <gribble> Time since last block: 2 minutes and 26 seconds
542 2013-08-13 09:22:17 <knotwork_> also it says "Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."
543 2013-08-13 09:22:20 <gmaxwell> knotwork_: still stuck?
544 2013-08-13 09:22:32 <knotwork_> which is why I pulled in the first place as previous version already was saying that
545 2013-08-13 09:22:48 <gmaxwell> if you're getting that warning, I think thats suggesting you've rejected the chain.
546 2013-08-13 09:22:51 <gmaxwell> What OS?
547 2013-08-13 09:23:03 <gmaxwell> and can you look in your debug log for INVALID? it may be some ways back.
548 2013-08-13 09:23:08 <knotwork_> fedora core 17 linux
549 2013-08-13 09:23:10 <gmaxwell> "INVALID"
550 2013-08-13 09:23:39 <knotwork_> grep INVALID ~/.bitcoin/debug.log comes back empty
551 2013-08-13 09:24:35 <knotwork_> -rescan is part of my startup script too so it has always done rescan any time i start it
552 2013-08-13 09:25:02 <michagogo> ...why?
553 2013-08-13 09:25:10 <sipa> -rescan is a wallet option, it has nothing to do with chain validation
554 2013-08-13 09:25:15 <knotwork_> I never know for sure why it needs starting at all
555 2013-08-13 09:25:28 <knotwork_> usually it means power corp rebooted machine by fluctuating our power
556 2013-08-13 09:25:41 <michagogo> knotwork_: Why rescan on every startup?
557 2013-08-13 09:25:44 <knotwork_> so I assume if it needs startring it likely didnt die cleanly
558 2013-08-13 09:25:45 <sipa> you shouldn't ever need -rescan really, unless you're manually messing with your wallet
559 2013-08-13 09:25:54 <sipa> -rescan doesn't help with unclean shutdown
560 2013-08-13 09:25:59 <michagogo> Should only need to do that if you're doing wallet stuff or importing a privkey
561 2013-08-13 09:26:00 <knotwork_> oh?
562 2013-08-13 09:26:20 <sipa> and that warning you get most likely means your chain database is corrupted
563 2013-08-13 09:26:24 <knotwork_> I saw too many people on forum have mysterious problems that went away once someone convinced them to rescan
564 2013-08-13 09:26:36 <sipa> people have been claiming you need rescan for ages
565 2013-08-13 09:26:41 <knotwork_> so I just put it in srtart script so i would never have to worry about it
566 2013-08-13 09:26:58 <knotwork_> is there a database fixer of some kind?
567 2013-08-13 09:27:10 <michagogo> knotwork_: For the chain database?
568 2013-08-13 09:27:11 <michagogo> -reindex
569 2013-08-13 09:27:14 <sipa> yes -reindex
570 2013-08-13 09:27:19 <sipa> but that takes a very long time
571 2013-08-13 09:27:28 <sipa> (not as much as starting over, of course)
572 2013-08-13 09:27:30 <knotwork_> so would downloading whole chain again
573 2013-08-13 09:27:39 <gmaxwell> knotwork_: sorry, I'm stupid about the case, can you grep for "Invalid"
574 2013-08-13 09:27:40 <gmaxwell> ?
575 2013-08-13 09:27:48 <sipa> grep -i
576 2013-08-13 09:27:53 <knotwork_> ok I will restart it with reindex go to sleep and see how it looks when I wake up
577 2013-08-13 09:28:04 <sipa> first do what gmaxwell asks :)
578 2013-08-13 09:28:08 <gmaxwell> knotwork_: can you please grep for Invalid first?
579 2013-08-13 09:28:18 <knotwork_> oh tons of invalid with -i
580 2013-08-13 09:28:20 <knotwork_> InvalidChainFound: current best=000000000000002102ae028653e8a6898ab0b825965f3a937b1bfce81198b1ee height=251021 log2_work=71.108179 date=2013-08-09 00:44:27
581 2013-08-13 09:28:20 <knotwork_> InvalidChainFound: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
582 2013-08-13 09:28:23 <knotwork_> is the last of many
583 2013-08-13 09:28:43 <gmaxwell> knotwork_: can you start it in less: less ~/.bitcoin/debug.log
584 2013-08-13 09:28:48 <gmaxwell> and type /Invalid
585 2013-08-13 09:28:59 <gmaxwell> and paste us the messages right before the first InvalidChainFound: ?
586 2013-08-13 09:29:32 <knotwork_> it might date back several runs of the daemon as debug.log doesnt get cleaned out
587 2013-08-13 09:29:37 <gmaxwell> knotwork_: was this node working okay before you updated git?
588 2013-08-13 09:29:47 <gmaxwell> knotwork_: thats fine, we want to see the first Invalid?
589 2013-08-13 09:29:55 <knotwork_> InvalidChainFound: current best=000000000000002102ae028653e8a6898ab0b825965f3a937b1bfce81198b1ee height=251021 log2_work=71.108179 date=2013-08-09 00:44:27
590 2013-08-13 09:29:55 <knotwork_> InvalidChainFound: invalid block=00000000000000253d9c0d5138e23c4c145cdcab8bf662f7488e56b9408f9536 height=251022 log2_work=71.10827 date=2013-08-09 00:46:30
591 2013-08-13 09:29:56 <gmaxwell> er s/\\?/\\./
592 2013-08-13 09:30:09 <gmaxwell> knotwork_: okay, and right _before_ that?
593 2013-08-13 09:30:28 <knotwork_> that is first one less found
594 2013-08-13 09:30:42 <gmaxwell> I know, I want to know the log messages right before the InvalidChainFound
595 2013-08-13 09:30:51 <gmaxwell> they will tell us what it thought was invalid about it.
596 2013-08-13 09:31:04 <knotwork_> not sure if it worked before i think not though as it alweays said not to use it for commerce or mining but I think today said it neded updating
597 2013-08-13 09:31:07 <knotwork_> so I updated it
598 2013-08-13 09:31:23 <knotwork_> also it did not show me a transaction I had sent to it just a day or so ago
599 2013-08-13 09:31:31 <knotwork_> so obviously wasnt getting up to date
600 2013-08-13 09:31:42 <sipa> yes yes, that's clear already :)
601 2013-08-13 09:31:53 <gmaxwell> please, the log entries before the first InvalidChainFound?
602 2013-08-13 09:31:53 <knotwork_> ERROR: ConnectBlock() : inputs missing/spent
603 2013-08-13 09:31:53 <knotwork_> InvalidChainFound: current best=000000000000002102ae028653e8a6898ab0b825965f3a937b1bfce81198b1ee height=251021 log2_work=71.108179 date=2013-08-09 00:44:27
604 2013-08-13 09:31:53 <knotwork_> InvalidChainFound: invalid block=00000000000000253d9c0d5138e23c4c145cdcab8bf662f7488e56b9408f9536 height=251022 log2_work=71.10827 date=2013-08-09 00:46:30
605 2013-08-13 09:31:53 <knotwork_> received block 00000000000000253d9c0d5138e23c4c145cdcab8bf662f7488e56b9408f9536
606 2013-08-13 09:31:54 <sipa> we want to know why it is considering the right chain invalid
607 2013-08-13 09:32:01 <sipa> eww
608 2013-08-13 09:32:29 <gmaxwell> knotwork_: can you email me and sipa this debug.log file? I'm not sure if we'll learn more from it, but it couldn't hurt to look.
609 2013-08-13 09:32:44 <knotwork_> those files never contain "sensitive" info?
610 2013-08-13 09:33:00 <gmaxwell> knotwork_: your IP address most likely, perhaps the ID of some of your transactions.
611 2013-08-13 09:33:12 <gmaxwell> no keys or passwords or anything like that.
612 2013-08-13 09:33:55 <gmaxwell> if you're uncomfortable with that, I don't think its very important here, I doubt we'll learn more.
613 2013-08-13 09:34:18 <gmaxwell> a reindex should fix it, but it may just fail again, since we don't know why it failed there.
614 2013-08-13 09:35:54 <knotwork_> email to where
615 2013-08-13 09:36:27 <gmaxwell> sipa: want a copy too?
616 2013-08-13 09:36:44 <gmaxwell> greg@xiph.org
617 2013-08-13 09:37:13 <sipa> i won't have time to investigate it in detail anyway
618 2013-08-13 09:37:39 <gmaxwell> knotwork_: thanks for troubleshooting with us, enjoy your reindex.
619 2013-08-13 09:37:48 <knotwork_> ok sent
620 2013-08-13 09:38:13 <knotwork_> it should contain runs of the previous version, then one run of the latest from github
621 2013-08-13 09:38:50 <knotwork_> previous was from github too at some random point when it was saying not to use for commerce or mining
622 2013-08-13 09:39:35 <sipa> it always says that, except during rc/release
623 2013-08-13 09:39:48 <knotwork_> ok
624 2013-08-13 09:41:16 <knotwork_> ok off to sleep then hopefully it will be nicely reindexed when I wake up have fun with the debug.log.tgz
625 2013-08-13 09:41:35 <gmaxwell> Thanks!
626 2013-08-13 09:44:48 <gribble> slush was last seen in #bitcoin-dev 19 weeks, 5 days, 2 hours, 46 minutes, and 53 seconds ago: <slush> not really :(
627 2013-08-13 09:44:48 <ThomasV> !seen slush
628 2013-08-13 12:45:50 <handle> is there anyone here who has experience with building opencl kernels?
629 2013-08-13 12:46:08 <handle> I believe Diablo-D3 built one, I'm not sure of any others
630 2013-08-13 12:47:56 <UukGoblin> handle, that's #bitcoin-mining, I believe
631 2013-08-13 12:48:05 <handle> ah, thanks
632 2013-08-13 12:48:46 <handle> that said, I'm not asking for help on how to use one, I'm asking for help on understanding the CL code, and also help for building one
633 2013-08-13 12:49:10 <handle> the reason I don't just use an existing one is because I'm not building one for sha256
634 2013-08-13 12:49:40 <UukGoblin> yeah, I understand, but AFAIK the core of bitcoin doesn't use any OpenCL. And some mining software devs used to hang out on #bitcoin-mining
635 2013-08-13 12:50:01 <UukGoblin> so might have more luck there
636 2013-08-13 12:50:04 <handle> no, the code does not use opencl
637 2013-08-13 12:50:04 <UukGoblin> but, I'm not an expert
638 2013-08-13 12:50:12 <sipa> it doesn't, no
639 2013-08-13 12:50:47 <sipa> but mining is moving away quickly from GPUs to FPGA/ASIC
640 2013-08-13 12:51:00 <handle> I don't think there are any bitcoin devs (as in bitcoin in general, not bitcoin core) in #bitcoin-mining that wouldn't be in here
641 2013-08-13 12:51:16 <handle> indeed, but I don't necessarily need a kernel for bitcoin or any altcoin
642 2013-08-13 12:51:38 <UukGoblin> ask your question then ;-]
643 2013-08-13 12:51:44 <handle> lol, I already did :P
644 2013-08-13 12:52:04 <UukGoblin> 154550 < handle> is there anyone here who has experience with building opencl kernels?
645 2013-08-13 12:52:06 <sipa> "does someone know about X" isn't a really useful question
646 2013-08-13 12:52:11 <UukGoblin> I believe the answer to that is "yes"
647 2013-08-13 12:52:43 <sipa> i believe i've actually had an accepted pull request for poclbm, a long long time ago :)
648 2013-08-13 12:53:01 <handle> that's basically all my question boils down to - some mentoring on opencl and help on understanding an optimized sha256 opencl kernel (will pay)
649 2013-08-13 12:55:17 <handle> I have a relatively basic understanding of both opencl and the workings of SHA2, so I'm not necessarily working from nothing - anyways, I'm done now and will stop spamming the channel :P
650 2013-08-13 12:56:58 <UukGoblin> there's probably #opencl too ;-)
651 2013-08-13 12:57:14 <handle> ah, that's true - didn't even think of that
652 2013-08-13 13:11:21 <shesek> http://thegenesisblock.com/bitcoin-block-time-halved-to-five-minutes-amid-exponential-network-growth/
653 2013-08-13 13:11:36 <shesek> "Since network speed has increased both dramatically and persistently so far in 2013 ... the time between blocks has been reduced by 50% to the five-minute block time currently observed."
654 2013-08-13 13:12:05 <shesek> interesting... it seems like it doesn't adjust fast enough
655 2013-08-13 13:12:08 <sipa> 5 minutes blocks means doubling every two weeks
656 2013-08-13 13:12:35 <shesek> was it considered to lower the number of last blocks that it uses to calculate the average?
657 2013-08-13 13:12:45 <sipa> actually, per week
658 2013-08-13 13:12:54 <sipa> that would be a hard fork
659 2013-08-13 13:13:02 <sipa> which means like planning a year ahead
660 2013-08-13 13:13:24 <Happzz> sipa thaks.
661 2013-08-13 13:13:26 <Happzz> thanks even
662 2013-08-13 13:13:36 <UukGoblin> nothing wrong with 5-minute blocks while network is growing
663 2013-08-13 13:13:43 <sipa> indeed
664 2013-08-13 13:15:11 <UukGoblin> it'll calm down when asics get distributed
665 2013-08-13 13:15:50 <shesek> ... until the next batch of asics
666 2013-08-13 13:17:01 <shesek> but yeah, I guess faster blocks while the network is growing isn't that bad
667 2013-08-13 13:17:03 <petertodd> shesek: ASICs aren't going to have feature sizes less than a few atoms wide, and we're actually not that many steps away from that...
668 2013-08-13 13:18:28 <sipa> they can scale up in die size :)
669 2013-08-13 13:19:01 <handle> yeah, but that won't give any more power efficiency would it?
670 2013-08-13 13:19:15 <sipa> no, but it would increase production efficiency
671 2013-08-13 13:19:22 <handle> true
672 2013-08-13 13:19:54 <petertodd> sipa: Funny that you mention that. :) A lot of people don't realize that much of moore's law *has* been scaling up in die size, and the damn things are getting big enough to be a real problem.
673 2013-08-13 13:20:14 <sipa> yes, and moore's law has nothing to do even with efficiency or performance
674 2013-08-13 13:20:31 <sipa> it's just about the number of components on an integrated circuit for a given price
675 2013-08-13 13:20:41 <petertodd> In theory it doesn't, in practice in does due to how ICs work.
676 2013-08-13 13:21:23 <sipa> well, taking a single-core CPU die and turning it into a CPU die with such identical such cores is a perfect embodiment of moore's law
677 2013-08-13 13:21:24 <handle> well yeah, it doesn't
678 2013-08-13 13:21:44 <sipa> with _two_ such identical cores
679 2013-08-13 13:21:45 <handle> I thought that was due to heat problems
680 2013-08-13 13:22:05 <sipa> if done for a fixed price
681 2013-08-13 13:22:14 <petertodd> Mainly it's been in the past few years where moore's law improvements aren't getting efficiency/performance improvements because the transistor power consumption is going up dramatically as they get smaller, mainly due to leakage. Also the fact that parallization doesn't get many gains. (but we're talking about bitcoin PoW here)
682 2013-08-13 13:22:41 <petertodd> Used to be power consumption alwent went down when transistors were shrunk due to lower capacitive switching losses.
683 2013-08-13 13:28:34 <petertodd> http://thegenesisblock.com/bitcoin-block-time-halved-to-five-minutes-amid-exponential-network-growth/ <- nice to see someone pointing out, even if only in passing, that 5min average block times from ASICs are increasing inflation. (roughly 20%/year right now w/ 5m blocks)
684 2013-08-13 13:28:38 <petertodd> So much for deflation :P
685 2013-08-13 13:32:52 <TD> i've always been kind of surprised that inflation changes don't seem to have more impact on the price
686 2013-08-13 13:33:10 <TD> though given that mt gox is limited to 10 SEPA wire transfers per day .... perhaps the fact that the price moves at all is the most surprising thing
687 2013-08-13 13:34:51 <petertodd> Each transaction has a cost, by inflation, of at least $10 and probably a lot more in terms of coins actually in circulation. People are obviously speculating on Bitcoin, and I'll bet you a huge number of miners are effectively doing just that, absorbing all that inflation with no impact on price.
688 2013-08-13 13:38:35 <Anduck> gox limited to 10 sepa wires? wtf
689 2013-08-13 13:40:05 <petertodd> Anduck: meh, they're just one exchange
690 2013-08-13 13:40:21 <Anduck> yeah but limits like that...
691 2013-08-13 13:40:46 <TD> apparently when they were using the second largest bank in japan, they represented >50% of all that banks SWIFT traffic
692 2013-08-13 13:40:51 <TD> wire tranfers, it turns out, are rare
693 2013-08-13 13:41:11 <TD> i assume there's some story behind this, like SWIFT charging per wire or something stupid
694 2013-08-13 13:41:42 <petertodd> Mt. Gox, for the bitcoin ecosystem, is most important as a way of doing price discovery through day-traders - there's no reason to assume they actually have a significant amount of economically useful trade movement
695 2013-08-13 13:44:00 <petertodd> Heck, I know people even in just Toronto that are averaging four and five figures of person-to-person trades a month - over the whole world that adds up.
696 2013-08-13 13:44:36 <TD> yeah, seems like there's a nice agent network in zurich now
697 2013-08-13 13:44:39 <TD> it's not just me anymore
698 2013-08-13 13:44:46 <TD> (which is good because i stopped local trading)
699 2013-08-13 13:45:33 <TD> wow. bitcoin is big in romania
700 2013-08-13 13:45:44 <petertodd> ?
701 2013-08-13 13:45:57 <TD> there are traders in lots of cities
702 2013-08-13 13:46:04 <petertodd> ah, localbitcoins?
703 2013-08-13 13:46:21 <TD> yeah
704 2013-08-13 13:46:50 <helo> oh yeah, they're really into crypto currencies over there
705 2013-08-13 13:47:16 <petertodd> see, what I find remarkable about that p2p trading, is of the people I know doing reasonably large volumes, only about 2/3 even use localbitcoins
706 2013-08-13 13:48:26 <petertodd> the day any of them tell me they've been using inputs.io or some other off-chain thing is when I know our hope of easily getting good data on this stuff is gone :)
707 2013-08-13 13:49:47 <Anduck> maybe mp got something to do with that romanian bitcoin conquering
708 2013-08-13 13:50:29 <michagogo> Hmm. From http://thegenesisblock.com/bitcoin-block-time-halved-to-five-minutes-amid-exponential-network-growth/...
709 2013-08-13 13:50:38 <michagogo> "Additionally, the confirmation time required for the same level of confidence that a transaction is not fraudulent has also been cut in half."
710 2013-08-13 13:50:55 <michagogo> If I'm not mistaken that's not true, right?
711 2013-08-13 13:51:10 <petertodd> depends on your attack model, often that's roughly true
712 2013-08-13 13:51:13 <michagogo> Since it's actually the time that matters?
713 2013-08-13 13:51:15 <michagogo> Oh?
714 2013-08-13 13:51:49 <petertodd> if your attacker is sized in terms of a % of total hashing power already contributing to the network, wall clock time has little to do with it
715 2013-08-13 13:51:54 <petertodd> (IE an attacker hacking pools)
716 2013-08-13 13:51:59 <michagogo> Ahh...
717 2013-08-13 13:52:10 <petertodd> or just screwing with node-to-node propagation
718 2013-08-13 13:53:04 <michagogo> So with the increase in (assuming) honest hashpower, it means that it's more likely for more blocks to be found if you're trying to come from behind?
719 2013-08-13 13:54:05 <petertodd> pretty much, modulo inefficiencies because information propagates in non-zero time - IE orphans
720 2013-08-13 13:54:16 <petertodd> but that's a second order effect not relevant at 5min blocks
721 2013-08-13 13:54:21 <petertodd> (very relevatn)
722 2013-08-13 13:56:31 <petertodd> "Firstbits: Compromised. Thanks, Android!
723 2013-08-13 13:56:42 <petertodd> " <- from someone who previously had a vanity addr...
724 2013-08-13 13:56:46 <sipa> ?
725 2013-08-13 13:57:03 <EagleTM> i assume he imported the vanity to android
726 2013-08-13 13:57:04 <TD> well, vanity addresses ......
727 2013-08-13 13:57:11 <petertodd> just someone's tagline on troll talk - shows how little people understand of the issue
728 2013-08-13 13:57:13 <michagogo> ;;calc [bc,blocks]/2016
729 2013-08-13 13:57:14 <gribble> 124.987599206
730 2013-08-13 13:57:34 <michagogo> ;;calc [bc,blocks]%2016
731 2013-08-13 13:57:35 <gribble> 1991
732 2013-08-13 13:57:44 <jouke> petertodd: why does that show how that?
733 2013-08-13 13:57:51 <petertodd> ?
734 2013-08-13 13:58:16 <jouke> My firstbits may be comppromised as well
735 2013-08-13 13:58:23 <michagogo> ;;bc,blocks
736 2013-08-13 13:58:24 <gribble> 251975
737 2013-08-13 13:58:33 <petertodd> did you generate the address on a phone?