1 2013-10-07 00:21:00 <Luke-Jr> hmm, B-Qt keeps warning me about my PC clock
2 2013-10-07 00:21:02 <Luke-Jr> even though it's right
3 2013-10-07 00:21:26 <gmaxwell> Luke-Jr: run getpeerinfo
4 2013-10-07 00:21:34 <Luke-Jr> this is before any peers :/
5 2013-10-07 00:21:41 <gmaxwell> uh. pretty sure thats not so.
6 2013-10-07 00:21:51 <Luke-Jr> http://codepad.org/CF64ohfp
7 2013-10-07 00:22:03 <Luke-Jr> well, it's literally right when it opens
8 2013-10-07 00:22:09 <gmaxwell> IIRC once triggered by peers that message stays up.
9 2013-10-07 00:22:18 <gmaxwell> but yea, that doesn't make sense, are you _sure_?
10 2013-10-07 00:22:29 <gmaxwell> sorry, can't load the codepad... broken interwebs.
11 2013-10-07 00:26:50 <Luke-Jr> I'm not sure there were *zero* peers, but I am sure it was immediately when the GUI came up
12 2013-10-07 00:27:01 <Luke-Jr> this was loading a wallet that needed some rescanning
13 2013-10-07 00:27:13 <Luke-Jr> (but not very much)
14 2013-10-07 00:30:30 <gmaxwell> Luke-Jr: there have been a bunch of people who have reported this then, and even got me getpeerinfos showing the same set of nodes
15 2013-10-07 00:30:37 <gmaxwell> mostly some russian datacenters.
16 2013-10-07 00:31:33 <Luke-Jr> 178.33.43.149 88.198.41.74 46.4.64.21 144.76.70.73 91.121.58.230 5.9.30.207 5.9.245.121 192.198.107.178 76.17.46.152 24.5.178.60 70.36.220.57 96.48.108.76
17 2013-10-07 00:33:24 <warren> Luke-Jr: https://github.com/Lolcust/Tenebrix-QT/commit/775d9ec644c0ddc09e7e6eb2a051ceb27a653313
18 2013-10-07 00:34:30 <Luke-Jr> warren: why are you linking me this? it's buggy, and makes the network centralised
19 2013-10-07 00:34:40 <warren> Luke-Jr: joking
20 2013-10-07 00:34:43 <Luke-Jr> ah
21 2013-10-07 00:34:45 <Luke-Jr> ok
22 2013-10-07 00:34:50 <Luke-Jr> :p
23 2013-10-07 00:34:59 <warren> I can point at more bad ideas if you'd like.
24 2013-10-07 00:36:11 <gmaxwell> 02:11 < Krellan> CodeShark: 91.121.58.230:60406 5.9.203.20:44514 5.9.30.207:52886 144.76.70.73:19492 46.4.64.21:21221 5.9.245.121:18615 = nodes that do that
25 2013-10-07 00:36:36 <gmaxwell> you can find other examples in the log for this channel)
26 2013-10-07 00:36:48 <gmaxwell> I'm kinda wondering if we shouldn't just ship a patch to blacklist those IPs. :(
27 2013-10-07 00:38:26 <gmaxwell> I don't think it's intentional trouble, ... seems rather ineffectual, though they might be trying to make miners with exposed nodes stop mining.
28 2013-10-07 01:08:14 <pepsis_> do clients connect to lfnet to get peer ups?
29 2013-10-07 01:09:01 <pepsis_> peer ips (irc client autocorrect sucks)
30 2013-10-07 01:11:04 <gmaxwell> pepsis_: no.
31 2013-10-07 01:11:15 <gmaxwell> Years ago they did.
32 2013-10-07 01:11:38 <gmaxwell> Nothing still (reliably) working does.
33 2013-10-07 01:11:52 <pepsis_> i just built a mincoin client from svn and saw it do it so i was curious
34 2013-10-07 01:11:59 <pepsis_> s/svn/git
35 2013-10-07 01:12:13 <gmaxwell> pepsis_: please see the topic
36 2013-10-07 01:12:37 <gmaxwell> "altcoins" are usually copies of really old, broken, insecure bitcoin codebases.
37 2013-10-07 01:13:44 <pepsis_> it would make sense then. it has an ancient protocol version that i thought it was using to be 'unique' but it may in fact be that ancient. :) I'm new.
38 2013-10-07 01:15:03 <pepsis_> thank you for the help though.
39 2013-10-07 01:23:46 <Luke-Jr> gmaxwell: backports do
40 2013-10-07 01:24:22 <gmaxwell> Luke-Jr: you should probably discontinue all those... since its not widely used anymore its increasingly an isolation vulnerability source.
41 2013-10-07 01:27:11 <Luke-Jr> meh, it's just bootstrap
42 2013-10-07 01:29:24 <warren> eh?
43 2013-10-07 01:49:41 <pepsis_> ACTION hands warren a can of maple syrup
44 2013-10-07 04:02:34 <bcb> anyone know when happens when you move a coin
45 2013-10-07 04:02:38 <bcb> to another address
46 2013-10-07 04:08:45 <Luke-Jr> bcb: you mean send?
47 2013-10-07 04:09:05 <bcb> I received bitcoin to one address
48 2013-10-07 04:09:15 <bcb> I moved bitcoin to another address
49 2013-10-07 04:09:32 <bcb> then I send from that second addreee to a third address outside my walled
50 2013-10-07 04:09:37 <gmaxwell> bcb: I suspect you mean accounts. You can't "move" to an address unless you mean just moving coins to an account with a name that looks like an address.
51 2013-10-07 04:09:51 <Luke-Jr> bitcoins aren't moved between addresses; they're sent from a wallet, to another wallet identified by an address
52 2013-10-07 04:09:58 <bcb> gmaxwell, I guess that is what I'm trying to understand
53 2013-10-07 04:09:59 <Luke-Jr> and/or moved between accounts
54 2013-10-07 04:10:12 <bcb> yes I moved bitcoin with in my wallet
55 2013-10-07 04:10:18 <bcb> what happens when you do that
56 2013-10-07 04:10:37 <Luke-Jr> it sets the balance of one account + X BTC, and the other - X BTC
57 2013-10-07 04:11:06 <razorfishsl> minus a possible transaction charge
58 2013-10-07 04:11:17 <Luke-Jr> razorfishsl: no
59 2013-10-07 04:11:26 <Luke-Jr> moving between accounts never has a transaction charge
60 2013-10-07 04:11:26 <razorfishsl> why?
61 2013-10-07 04:11:33 <gmaxwell> razorfishsl: there is no transaction with a move, it's just local book keeping.
62 2013-10-07 04:11:48 <bcb> so and address is not tied to an account?
63 2013-10-07 04:11:56 <bcb> *an
64 2013-10-07 04:11:59 <Luke-Jr> bcb: only for receiving from other wallets
65 2013-10-07 04:12:24 <Luke-Jr> an address points to an account, but an account is not tied to any address(es)
66 2013-10-07 04:12:25 <bcb> so when I use sendfrom what is happening
67 2013-10-07 04:12:42 <razorfishsl> only if the addresses are in the same wallet
68 2013-10-07 04:12:43 <gmaxwell> bcb: perhaps you should first consult the channel topic?
69 2013-10-07 04:12:55 <Luke-Jr> bcb: it creates a transaction from your wallet, to another wallet identified by an address, and debits the account you name
70 2013-10-07 04:12:55 <razorfishsl> I thught it was about separate wallets?
71 2013-10-07 04:13:04 <gmaxwell> razorfishsl: No. You're clueless as to how any of this works.
72 2013-10-07 04:13:13 <razorfishsl> thanks
73 2013-10-07 04:13:18 <gmaxwell> razorfishsl: move _NEVER_ creates a transaction send* _ALWAYS_ creates a transaction.
74 2013-10-07 04:13:54 <bcb> Luke-Jr, thx
75 2013-10-07 04:18:04 <gavinandresen> cfields: I need help with re-enabling win32 builds for the pull-tester.
76 2013-10-07 04:18:13 <gavinandresen> cfields: see: http://jenkins.bluematt.me/pull-tester/216ca8b7d7a55d85676a13c875aaec716a3cc945/test.log
77 2013-10-07 04:19:21 <Luke-Jr> hmm, looks like we need to check for a target-specific moc or something
78 2013-10-07 04:19:59 <gavinandresen> cfields: Problem is using the wrong moc (/usr/bin/moc is qt4.6, but I don't understand why autotools is using it when I pass --with-qt-bindir=$MINGWPREFIX/host/bin )
79 2013-10-07 04:20:17 <Luke-Jr> no i586-mingw32msvc-moc?
80 2013-10-07 04:20:34 <gavinandresen> $MINGWPREFIX/host/bin/moc is the correct version.
81 2013-10-07 04:20:46 <gavinandresen> We don't want a mingw-compiled moc....
82 2013-10-07 04:20:59 <Luke-Jr> i586-mingw32msvc-g++ isn't mingw-compiled either ;)
83 2013-10-07 04:21:45 <gavinandresen> I don't think moc cares what it is compiling TO, it is generating source code.
84 2013-10-07 04:26:45 <Luke-Jr> gavinandresen: can you run the configure in strace easily? (strace -ff ./configure --your-args &>logfile)
85 2013-10-07 04:29:50 <gavinandresen> Luke-Jr: not easily, no
86 2013-10-07 04:31:30 <Luke-Jr> hrm
87 2013-10-07 04:31:43 <Luke-Jr> you can run /mnt/w32deps/host/bin/moc manually, I presume?
88 2013-10-07 04:32:18 <gavinandresen> Sure. I just can't easily get strace and the right pull request into the chroot environment
89 2013-10-07 04:32:32 <gavinandresen> Luke-Jr: why? What would strace tell you? The problem is configure is using the wrong moc binary
90 2013-10-07 04:32:54 <Luke-Jr> strace would confirm it's looking for the right binary and maybe why it's failing to find it
91 2013-10-07 04:33:08 <Luke-Jr> configure.ac in master *should* be attempting to use it (and is in my strace here)
92 2013-10-07 04:34:02 <gavinandresen> ok, I'll rewrite the pull-tester a bit so it exits before cleaning up its directories...
93 2013-10-07 04:35:17 <gavinandresen> ⦠then install strace in the chroot environment, then rerun configure...
94 2013-10-07 04:36:46 <Luke-Jr> maybe easier to work on something else until cfields wakes up - strace isn't necessarily guaranteed to turn up anything useful
95 2013-10-07 04:45:29 <gavinandresen> Luke-Jr: maybe. If you have bandwidth and time: http://jenkins.bluematt.me/pull-tester/216ca8b7d7a55d85676a13c875aaec716a3cc945/configure_strace.log
96 2013-10-07 05:14:14 <warren> gavinandresen: [pid 25518] stat64("/usr/bin/moc-qt4", {st_mode=S_IFREG|0755, st_size=1058968, ...}) = 0
97 2013-10-07 05:14:26 <warren> gavinandresen: the moc-qt4 preference might be interfering
98 2013-10-07 05:15:31 <Luke-Jr> ah, yeah
99 2013-10-07 05:15:40 <Luke-Jr> it's preferring moc-qt4 over moc
100 2013-10-07 05:15:56 <Luke-Jr> regardless of location
101 2013-10-07 05:16:15 <Luke-Jr> I suppose we should prioritise whatever is found in the --with-qt-bindir
102 2013-10-07 05:28:34 <warren> hmm, Diapolo said, "I'm using Qt Creator and the bitcoin-qt.pro file from before Autotools,"
103 2013-10-07 05:33:21 <michagogo> cloud|warren: have you gbuilt win32 as of the commit that was HEAD when I built last week?
104 2013-10-07 05:33:46 <michagogo> cloud|And can you compare hashes?
105 2013-10-07 05:34:19 <warren> michagogo|cloud: sorry, been very busy
106 2013-10-07 05:34:34 <michagogo> cloud|No problem
107 2013-10-07 05:35:33 <michagogo> cloud|I just want to know that I have a working gitian before I try to make time for the dep upgrade stuff
108 2013-10-07 05:36:17 <warren> please recruit more gitian builders
109 2013-10-07 05:36:31 <warren> relying on devs for every little thing is time consuming
110 2013-10-07 05:36:38 <warren> gitian building doesn't require much skill
111 2013-10-07 05:36:47 <michagogo> cloud|Agreed.
112 2013-10-07 05:37:43 <michagogo> cloud|ACTION doesn't really know how he'd go about recruiting more... :-/
113 2013-10-07 05:38:08 <warren> post about it on that forum that is sometimes up
114 2013-10-07 05:41:51 <michagogo> cloud|warren: lol, nice timing
115 2013-10-07 05:43:03 <CassieHeart_> Wow its quiet in here . echo echo echo
116 2013-10-07 05:44:17 <gmaxwell> CassieHeart_: please don't just make noise here. This is supposted to be "working" channel, not just general chat.
117 2013-10-07 05:44:25 <gmaxwell> feel free to chat in #bitcoin
118 2013-10-07 05:45:44 <CassieHeart_> sorry :( I was just in #bitcoin Lf a web developer who knows bitcoin they sent me here ..
119 2013-10-07 06:45:32 <gavinandresen> warren: thanks, linking host/bin/moc to host/bin/moc-qt4 seems to workaround the problem. I'll file a bug to fix autotools.
120 2013-10-07 06:49:26 <warren> great
121 2013-10-07 07:54:56 <michagogo> warren: Just registered on bitcointalk. Once I'm out of newbland, I'll try to write a call for gitianbuilders
122 2013-10-07 07:57:24 <warren> michagogo: what is your bitcointalk username? one of the admins can approve your account manually.
123 2013-10-07 07:57:32 <michagogo> <--
124 2013-10-07 11:55:54 <michagogo> cloud|Is the -salvagewallet flag what I remember it being? Namely, "rename wallet.dat, copy keypairs from it to a new wallet.dat, and rescan"?
125 2013-10-07 11:56:27 <sipa> yes
126 2013-10-07 11:56:28 <michagogo> cloud|Which would basically result in the wallet keys, but losing transactions and metadata such as address labels?
127 2013-10-07 11:56:46 <sipa> indeed
128 2013-10-07 11:57:08 <michagogo> cloud|That's what I thought -- just wanted to make sure I'm not screwing this guy up: https://bitcointalk.org/index.php?PHPSESSID=7942nso8fd46ufum9uq4d58ca7&topic=306389.msg3291036#msg3291036
129 2013-10-07 11:59:57 <michagogo> cloud|stuck in his wallet, preventing him from sending the remaining balance)
130 2013-10-07 11:59:57 <michagogo> cloud|(tl;dr: he imported a paper wallet into Bitcoin-Qt, spent part of it, moving some into change addresses, and then swept the key with a webwallet. About half the bitcoins were still there. He then tried to send the entire balance of the not-yet-caught-up B-Qt wallet to the webwallet, which failed because it was a double-spend, but the transaction's still
131 2013-10-07 12:13:53 <skinnkavaj> sipa
132 2013-10-07 12:14:10 <skinnkavaj> Is it possible to create pgp key online?
133 2013-10-07 12:14:24 <skinnkavaj> like you can generate a private key online
134 2013-10-07 12:15:18 <michagogo> cloud|skinnkavaj: Erm, why?
135 2013-10-07 12:15:42 <skinnkavaj> michagogo|cloud: I don't bother downloading and using pgp program
136 2013-10-07 12:15:49 <skinnkavaj> So hard to use i think
137 2013-10-07 12:16:05 <michagogo> cloud|Sure, there are websites that will generate a key for you, but they're not a good idea to use
138 2013-10-07 12:16:34 <skinnkavaj> Who would steal my identity even, its not like im DPR
139 2013-10-07 12:17:36 <michagogo> cloud|...a key that someone else generates for you is not a key that can be trusted to only exist with you
140 2013-10-07 12:19:42 <TD> hello
141 2013-10-07 12:20:56 <TD> petertodd: ping. is there a reason your testnet dns seed sometimes returns a single ip (23.21.243.183) ?
142 2013-10-07 12:20:58 <skinnkavaj> michagogo|cloud: Are there not any mail clients with built in pgp?
143 2013-10-07 12:21:01 <TD> it seems to return just this about half the time
144 2013-10-07 12:21:35 <michagogo> cloud|skinnkavaj: I'm sure there are plenty of clients that either have it built in or have a plugin, yes
145 2013-10-07 12:22:06 <michagogo> cloud|skinnkavaj: http://www.gnupg.org/related_software/frontends.html#mua
146 2013-10-07 12:22:08 <TD> ok, i just saw it return a different single IP
147 2013-10-07 12:22:46 <TD> and now it seems stuck there
148 2013-10-07 12:23:38 <michagogo> cloud|TD: Are you asking it directly?
149 2013-10-07 12:23:42 <TD> yeah
150 2013-10-07 14:47:34 <swulf--> gmaxwell: around?
151 2013-10-07 17:25:56 <davec> hey guys - I found a case that I think would make sense to add to the block aceptance regression test suite
152 2013-10-07 17:27:03 <davec> apparently transaction script that contain invalid opcodes are allow so long as they invalid opcode doesn't get executed. It doesn't seem like a particularly good idea to me to allow a script with invalid opcodes in it even when they aren't executed, but it can't be changed now
153 2013-10-07 17:27:27 <davec> due to this section:
154 2013-10-07 17:27:28 <davec> else if (fExec || (OP_IF <= opcode && opcode <= OP_ENDIF))
155 2013-10-07 17:27:28 <davec> switch (opcode)
156 2013-10-07 17:28:21 <davec> at any rate, definitely seems to be a corner case that I think having in the block acceptance regression test suite would be worthwhile
157 2013-10-07 17:32:30 <dhill> bitcoind devs want to check out https://github.com/conformal/btcscript/issues/1 ?
158 2013-10-07 17:33:37 <Luke-Jr> dhill: why? it's a bug in some other software
159 2013-10-07 17:35:37 <dhill> Luke-Jr: did you read it?
160 2013-10-07 17:40:12 <gmaxwell> davec: I thought the block tester tested that case already.
161 2013-10-07 17:41:57 <BlueMatt> gmaxwell: doesnt ring a bell...someone should totally implement that
162 2013-10-07 17:42:09 <davec> It doesn't seem to. There are quite a few checks around opcodes, but we pass all the regression tests and this case wasn't hit
163 2013-10-07 17:42:34 <BlueMatt> davec: please fix block-tester :)
164 2013-10-07 17:43:01 <davec> sure, I'll take a look at adding it.
165 2013-10-07 17:45:18 <Luke-Jr> dhill: yes
166 2013-10-07 18:04:46 <michagogo> gmaxwell: Do you know who I'd ask to get out of newbville on bct?
167 2013-10-07 18:06:19 <gmaxwell> michagogo: I would have whitelisted you when you mentioned it last night... except the whitelist api is gone now as a security precaution.
168 2013-10-07 18:06:32 <gmaxwell> michagogo: post in the newbie forum and ask to be let out of the box. :)
169 2013-10-07 18:06:59 <michagogo> I saw somewhere it was supposed to happen at 4 hours + 1 post or something, but that doesn't seem to have happened
170 2013-10-07 18:07:32 <michagogo> Or does "1 post" need to be a new thread?
171 2013-10-07 18:07:37 <c0rw1n> wut? hours are counted as time
172 2013-10-07 18:07:43 <c0rw1n> gah imanidiot
173 2013-10-07 18:07:52 <c0rw1n> posts are counted as time
174 2013-10-07 18:08:04 <c0rw1n> you need to post to earn time logged
175 2013-10-07 18:08:07 <c0rw1n> srsly
176 2013-10-07 18:08:49 <michagogo> https://bitcointalk.org/index.php?topic=306389.msg3291036#msg3291036
177 2013-10-07 18:08:50 <michagogo> This was 11 hours ago...
178 2013-10-07 18:08:55 <c0rw1n> yes
179 2013-10-07 18:08:57 <c0rw1n> opst moar
180 2013-10-07 18:09:12 <c0rw1n> grr
181 2013-10-07 18:09:12 <c0rw1n> post moar
182 2013-10-07 18:09:12 <michagogo> "All it takes to move up is 1 post and 4 hours elapsed since that post."
183 2013-10-07 18:09:12 <michagogo> https://bitcointalk.org/index.php?topic=15911.0
184 2013-10-07 18:09:15 <michagogo> Maybe I'm missing something here?
185 2013-10-07 18:09:21 <michagogo> :-/
186 2013-10-07 18:47:11 <gcX46> can someone please donate me some testnet coins: moMSd6bwMuhMMukj4EqGPsLk1D8THE8FPh
187 2013-10-07 18:51:00 <helo> gcX46: sending...
188 2013-10-07 18:51:29 <gcX46> helo: thank you
189 2013-10-07 18:55:24 <helo> gcX46: let me know when you see it. looks like my testnet wallet (on android) is a bit behind...
190 2013-10-07 18:55:47 <gcX46> helo: I see it
191 2013-10-07 18:56:02 <helo> interesting... my wallet says it isn't sent yet :o
192 2013-10-07 18:56:36 <gcX46> helo: 5650292052926ed687ecb4921779adbf8d6189dd5a301645abc8363e3994944f
193 2013-10-07 18:57:00 <helo> yep, that's the one
194 2013-10-07 19:16:44 <ryan-c> What's the current testnet block height?
195 2013-10-07 19:19:20 <davec> 103332
196 2013-10-07 19:25:14 <ryan-c> anyone have any testnet nodes i can connect to?
197 2013-10-07 19:26:09 <michagogo> ryan-c: I do
198 2013-10-07 19:26:32 <ryan-c> michagogo: pm me the address?
199 2013-10-07 19:27:07 <michagogo> lol, I did about 2 seconds before you said that
200 2013-10-07 19:28:46 <michagogo> ryan-c: it's up
201 2013-10-07 19:29:21 <michagogo> (also, I have 59.167.130.238, 199.231.187.226, and 176.9.136.229 as peers)
202 2013-10-07 19:29:37 <michagogo> as well as 46.105.165.227
203 2013-10-07 20:36:56 <f12adf> Hi, where can I find the most obsolete version of Bitcoin client?
204 2013-10-07 20:47:10 <Luke-Jr> f12adf: why?
205 2013-10-07 20:51:45 <maaku> is there any concensus on good ways to distribute historical data in a hypothetical future where most nodes are pruning?
206 2013-10-07 20:52:11 <maaku> i.e., anything which performs better than a naïve DHT overlay
207 2013-10-07 20:55:43 <phantomcircuit> maaku, yes
208 2013-10-07 20:56:11 <phantomcircuit> put a compressed version of which block ranges a peer has into the addr message
209 2013-10-07 20:57:49 <phantomcircuit> if you wanted to be ridiculous about it you could do a bitfield
210 2013-10-07 20:58:14 <phantomcircuit> but that's like 37KB just to tell which blocks you have
211 2013-10-07 21:00:21 <f12adf> Luke-Jr: It doesn't matter for now.
212 2013-10-07 21:00:26 <gmaxwell> phantomcircuit: only if you ignore sparseness, which would be silly. The data is naturally sparse. A single range is just the one specific extreme, which assumes sparseness and contigiousness.
213 2013-10-07 21:00:56 <gmaxwell> (and the contigious assumption is usually pretty good too)
214 2013-10-07 21:01:18 <Luke-Jr> f12adf: well you're question is ambiguous for now
215 2013-10-07 21:01:26 <Luke-Jr> what defines "most obsolete"? and "Bitcoin client"?
216 2013-10-07 21:02:07 <Luke-Jr> your*
217 2013-10-07 21:02:56 <maaku> i think nodes storing a range of items by hash is what I meant by naïve DHT
218 2013-10-07 21:03:11 <maaku> are there reasons that storing numbered block ranges would be better?
219 2013-10-07 21:03:21 <maaku> maybe this is better for #bitcoin-wizards
220 2013-10-07 21:05:02 <phantomcircuit> maaku, the information needs to be propagated in a censorship resistant way
221 2013-10-07 21:05:05 <gmaxwell> maaku: yes, because the actual access patterns are range dense!
222 2013-10-07 21:05:18 <phantomcircuit> a naive DHT is not even remotely censorship resistant
223 2013-10-07 21:06:00 <phantomcircuit> im actually fairly surprised the RIAA/MPAA haven't hired someone to fill the bittorrent DHT with nonsense yet
224 2013-10-07 21:06:04 <gmaxwell> also, using hash ranges means that to keep your storage constant you have to be constantly updating your descriptors.
225 2013-10-07 21:08:06 <maaku> phantomcircuit: there's no reason you'd be able to PUT arbitrary data in the dht.. it'd simply be a way for nodes to decide which data to keep (e.g, "250MB of data centered on 0xa8f72ce02..." or "250MB of data starting from block #230100)
226 2013-10-07 21:08:25 <maaku> gmaxwell: that makes sense
227 2013-10-07 21:08:25 <roconnor> sipa: is there any proposal to include unspent transactions in the blockchain?
228 2013-10-07 21:08:57 <maaku> well, you'd put arbitrary data in the DHT by putting it in the blockchain.. the dht is just an index of that data
229 2013-10-07 21:09:07 <maaku> roconnor: what do you mean?
230 2013-10-07 21:09:26 <roconnor> maaku: I mean as a required part of the block header, presumably in the coinbase script.
231 2013-10-07 21:09:28 <maaku> hash commitments? see : https://bitcointalk.org/index.php?topic=88208.0
232 2013-10-07 21:09:43 <roconnor> maaku: like how the block height is stored.
233 2013-10-07 21:09:45 <maaku> and : https://bitcointalk.org/index.php?topic=204283.0
234 2013-10-07 21:12:16 <roconnor> maaku: so ... no official BIP
235 2013-10-07 21:12:29 <maaku> it's only just gotten to that stage
236 2013-10-07 21:12:36 <maaku> hopefully i'll be able to write a series of bips soon
237 2013-10-07 21:12:45 <maaku> it's been prototyping work up until now
238 2013-10-07 21:12:54 <maaku> (imho a BIP should come with working code)
239 2013-10-07 21:16:14 <gmaxwell> I will oppose the schemes that force full-nodes to carry address indexes, unless their cost can be shown to be truly insubstantial.
240 2013-10-07 21:16:49 <gmaxwell> (which I don't believe is possible)
241 2013-10-07 21:17:40 <maaku> i don't think it is possible to get less than a 2x performance hit (two indices, double the effort)
242 2013-10-07 21:17:53 <maaku> as it is currently it's actually slightly worse than that
243 2013-10-07 21:18:09 <gmaxwell> Right. :(
244 2013-10-07 21:18:26 <gmaxwell> I think it's really unfortunate that the discussion has conflated authenticated utxo which is useful for validation, with authenticated address indexes which are useful only for some kinds of stateless wallet services (and really, even those perhaps not unless you use very few addresses).
245 2013-10-07 21:18:37 <roconnor> maaku: Well, I'd like to comment on the design and recommon the tree contain the transaction depth and/or the total work done at that depth and/or the transaction time in order for clients to assess the confidence in the transaction not being rolled back.
246 2013-10-07 21:18:56 <roconnor> *recommend
247 2013-10-07 21:19:38 <maaku> roconnor: tree does contain the transaction depth; total work done and time is extractable from the block headers
248 2013-10-07 21:20:00 <maaku> rather it contains the transaction height, from which you can calculate the depth
249 2013-10-07 21:20:08 <gmaxwell> roconnor: height of output creation is probably generally useful. Our current non-authenticated utxo data has that, though its needed for imposing the coinbase spending rule and probably wouldn't be in that... it does seem useful.
250 2013-10-07 21:20:20 <gmaxwell> And as maaku says, knowing that you get the rest from knowing the headers.
251 2013-10-07 21:20:36 <roconnor> maaku: that's nice. I'm not really interested in time anyways. But how can you say the tree does it when there is no published proposed spec?
252 2013-10-07 21:20:51 <gmaxwell> roconnor: he's referring to his code.
253 2013-10-07 21:21:10 <maaku> actually the height is the only value in the index which is not strictly needed for validation (since the coinbase rules are handled differently), but it was so rediculously useful...
254 2013-10-07 21:21:30 <gmaxwell> maaku: yea thats why I said "probably wouldn't be in that".
255 2013-10-07 21:21:34 <roconnor> good good.
256 2013-10-07 21:23:06 <gmaxwell> roconnor: You ever see my crazy "alt ideas" page?
257 2013-10-07 21:23:45 <roconnor> er I forget.
258 2013-10-07 21:24:18 <gmaxwell> roconnor: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
259 2013-10-07 21:24:53 <roconnor> ACTION wants to make an alt-chain
260 2013-10-07 21:25:46 <maaku> meh.. work on bitcoin
261 2013-10-07 21:25:55 <c0rw1n> yeah
262 2013-10-07 21:25:59 <maaku> ...says the guy who made his own alt-chain
263 2013-10-07 21:26:06 <c0rw1n> don't reinvent the wheel unless it's a better mousetrap
264 2013-10-07 21:26:11 <roconnor> practicality isn't my strong point.
265 2013-10-07 21:26:27 <c0rw1n> altcoin-in-a-box
266 2013-10-07 21:26:31 <c0rw1n> make it happen
267 2013-10-07 21:26:34 <c0rw1n> plz
268 2013-10-07 21:26:36 <c0rw1n> k
269 2013-10-07 21:26:38 <c0rw1n> thx
270 2013-10-07 21:26:45 <c0rw1n> in javascript
271 2013-10-07 21:27:19 <roconnor> gmaxwell: I've been mulling the idea of replacing scripts with arbitrary linear circuts.
272 2013-10-07 21:27:24 <gmaxwell> roconnor's altcoin would be some kind of elegant inductive proof which can't be instantiated in any finite universe. :P
273 2013-10-07 21:27:34 <roconnor> gmaxwell: exactly
274 2013-10-07 21:27:59 <c0rw1n> whoa d00D
275 2013-10-07 21:28:10 <c0rw1n> "inductive proof which can't be instantiated in any finite universe"
276 2013-10-07 21:28:56 <c0rw1n> and they said SR is down, well here's one guy with the good sense to keep a buffer stash
277 2013-10-07 21:29:18 <gmaxwell> roconnor: ah, I've tossed out some pretty far rocket science script-alternative ideas: https://bitcointalk.org/index.php?topic=277389.0
278 2013-10-07 21:29:23 <roconnor> gmaxwell: "POW which involves queries against the UTXO set" yea, this is such an intriguing idea.
279 2013-10-07 21:29:32 <c0rw1n> oooh nice
280 2013-10-07 21:29:56 <c0rw1n> but does a merkle tree not functionally do that?
281 2013-10-07 21:30:10 <c0rw1n> ah not qith queries, or rather a constant query
282 2013-10-07 21:30:50 <roconnor> c0rw1n: I think the more general idea is to tie mining speed to the speed of valdiating blocks.
283 2013-10-07 21:31:13 <roconnor> So the best miners are also the most useful miners.
284 2013-10-07 21:31:39 <c0rw1n> well bitcoin already does that, the miners who et the coin are the miners who hash the block
285 2013-10-07 21:32:08 <roconnor> c0rw1n: well miners only have to hash the block once.
286 2013-10-07 21:32:22 <roconnor> c0rw1n: so that could take a long time and there would be no appreciable overhead.
287 2013-10-07 21:32:42 <c0rw1n> ah so your idea hashes the block several times? or all utxos every time?
288 2013-10-07 21:32:42 <roconnor> That said, this idea is not obviously a good thing. It is simply intriguing.
289 2013-10-07 21:33:14 <c0rw1n> all utxos every time is fucking awesome, but how do you prove that if you don't hash the full history?
290 2013-10-07 21:33:22 <c0rw1n> erm
291 2013-10-07 21:33:24 <roconnor> c0rw1n: The idea would be something like needed to append some sort of "fake" transactions to the exisiting set of transactions allong with a proof of failure.
292 2013-10-07 21:33:39 <c0rw1n> wait wut, drunk mindblown
293 2013-10-07 21:33:55 <c0rw1n> bookmarking that into READ ME folder
294 2013-10-07 21:33:55 <gmaxwell> c0rw1n: Most bitcoin "miners" are not actually miners, they are people just blindly selling computation to a few super large miners... that suggested idea might go some of the distance to addressing that.
295 2013-10-07 21:33:58 <roconnor> The proof being required to prove that you did the work of trying to validate.
296 2013-10-07 21:34:28 <gmaxwell> roconnor: I'm very happy that you actually understand the idea (and that it's by no means obviously correct, just interesting) from that crappy little page. :)
297 2013-10-07 21:34:45 <roconnor> gmaxwell: well, I think you've presented it to me before.
298 2013-10-07 21:34:48 <c0rw1n> orite the forst post is by gmaxwell
299 2013-10-07 21:35:03 <c0rw1n> woha
300 2013-10-07 21:35:19 <c0rw1n> whadafuq, netsplit ?
301 2013-10-07 21:35:26 <c0rw1n> doesnt say so
302 2013-10-07 21:35:39 <gmaxwell> roconnor: :)
303 2013-10-07 21:35:45 <roconnor> gmaxwell: I haven't read this CointWitness post before, but it would be the killer feature for an alt-chain
304 2013-10-07 21:35:55 <c0rw1n> or a webchain
305 2013-10-07 21:36:00 <c0rw1n> offchain marketplaces
306 2013-10-07 21:36:52 <c0rw1n> can that be done in javascript lite enough for viral web replication? I mean a node.js webserver that replicates to all visitors
307 2013-10-07 21:36:54 <roconnor> gmaxwell: BTW, one idea that I have for my alt-chain is taking signature out of the transaction hash.
308 2013-10-07 21:37:15 <roconnor> gmaxwell: signatures would still be required but wouldn't be part of the hash, so could be replaced with other signatures.
309 2013-10-07 21:37:28 <roconnor> gmaxwell: the idea being that all signatures are created equal.
310 2013-10-07 21:37:52 <c0rw1n> that would solve the raidv&ing of marketplaces and the idiot regulations on the exchanges and the ads on internet and the walled gardens
311 2013-10-07 21:37:55 <gmaxwell> right, kind of a no-brainer thing to do. Esp if you restructure transactions into a tree structure.
312 2013-10-07 21:41:29 <gmaxwell> roconnor: the other idea thats had me somewhat excited in the recent past is that the realization that in pairing cryptographic there exist compact one way aggregatable signatures. E.g. given {{Pubkey_n0,...},{Message_n0,...},Signature_n} and {{Pubkey_m0,...},{Message_m0,...},Signature_m} you can securely compute {{Pubkey_n0,Pubkey_m0...},{Message_n0,Message_m0,...},Signature_nm} a single signature value for a group of pubkeys and ...
313 2013-10-07 21:41:35 <gmaxwell> ... messages.
314 2013-10-07 21:41:55 <gmaxwell> And you can't ungroup them.. this lets you do neat anonymization things, as well as it has some very interesting anti-censorship properties.
315 2013-10-07 21:42:16 <roconnor> gmaxwell: is that some sort of weak form of homomorphic encryption?
316 2013-10-07 21:42:30 <gmaxwell> E.g. you can merge a bunch of transaction into a larger mega-transaction and from there they cannot be ungrouped.
317 2013-10-07 21:43:37 <c0rw1n> gmaxwell isn't that the holy grail of perfect laundry? just aksin'
318 2013-10-07 21:43:50 <c0rw1n> set that up in a money loop of inner transactions
319 2013-10-07 21:44:00 <c0rw1n> boom untraceable forever
320 2013-10-07 21:44:18 <roconnor> your miner could launder by pulling in innocent peoples transactions. :D
321 2013-10-07 21:44:33 <c0rw1n> in btc or in cw?
322 2013-10-07 21:44:38 <gmaxwell> roconnor: sort of, pairing short signatures are based on the weird property that you can distinguish a diffie-hellman produced point without being able to actually solve the diffie-hellman problem... plus paritial homomorphic behavior from addition in the EC group.
323 2013-10-07 21:44:43 <gmaxwell> roconnor: yea, yep exactly.
324 2013-10-07 21:44:59 <gmaxwell> roconnor: see also: https://bitcointalk.org/index.php?topic=290971.0
325 2013-10-07 21:45:16 <c0rw1n> ok my mind is so fuckin blown i can't even make sense of the tech
326 2013-10-07 21:46:13 <c0rw1n> hey gmaxwell
327 2013-10-07 21:46:29 <roconnor> gmaxwell: I don't understand chain folding
328 2013-10-07 21:46:58 <BCB> on a transaction with two ouputs how do you know which one is the change address
329 2013-10-07 21:47:05 <gmaxwell> roconnor: the pairing stuff actually results in signature algorithims which are far simpler and provably secure than ECDSA, but the underlying gap-DHP hardness assumption is much newer and less well studied than just the hardness of the DLP.
330 2013-10-07 21:47:12 <gmaxwell> BCB: you don't.
331 2013-10-07 21:47:34 <BCB> Sara Mickeljohn does
332 2013-10-07 21:47:39 <maaku> BCB: ask the person that made it
333 2013-10-07 21:47:40 <c0rw1n> BCB even in regular bitcoin you don't
334 2013-10-07 21:47:52 <c0rw1n> if you were askin about the coinwitness
335 2013-10-07 21:48:20 <gmaxwell> roconnor: for folding. Observe: the lowest block hash ever is currently 0000000000000000004bb6e7e2661661ba9809062d90c3121933d6d02c8bd763
336 2013-10-07 21:48:22 <c0rw1n> (am rather too drunk to talk here possibly)
337 2013-10-07 21:48:34 <c0rw1n> wait wut
338 2013-10-07 21:49:19 <gmaxwell> roconnor: this has about 73.75 zero bits. Currently, estimation from our sum-difficulty directly suggests that we've done 72.545276 bits of work.
339 2013-10-07 21:49:21 <c0rw1n> are you saying that the lowest block hash is provably the merkle root of all previous transactions forever and thus that e could prune those?
340 2013-10-07 21:49:38 <c0rw1n> considering we'd keep utxos i suppose
341 2013-10-07 21:49:49 <gmaxwell> roconnor: meaning that you can take unusually low (multiple of the difficulty) headers as proof of the overall work, and chain them up.
342 2013-10-07 21:49:52 <c0rw1n> or am i too stupid or drunk
343 2013-10-07 21:51:09 <gmaxwell> roconnor: so instead of validating 262280 headers, I could validate some number of level 0 headers, then step up and then validate some number of level 1 headers (which there are 262280/2^n for some n).. then some number of level 2.. and so on, and prove the total difficulty to myself with log_n(height) headers inspected.
344 2013-10-07 21:53:32 <gmaxwell> or, in other words, instead of mining a single linked-list of headers, you mine floor(log(height)) linked lists, each a multiple of the difficulty apart... taking header difficulty validation from linear in chain length to log.
345 2013-10-07 21:54:11 <roconnor> gmaxwell: okay, I'll have to think about it. I'm a little fuzzy but it seems plausible.
346 2013-10-07 21:57:39 <gmaxwell> it's not a very important idea ... unless you radically decrease the time between blocks.
347 2013-10-07 21:58:12 <gmaxwell> which itself isn't an obviously viable thing to do... since at some speed latency starts doing bad things to your network.
348 2013-10-07 21:58:31 <roconnor> gmaxwell: This aggregate signature scheme is almost as good as having encrypted transaction amounts.
349 2013-10-07 21:59:51 <gmaxwell> roconnor: I agree. ... and beyond the privacy impacts, the anti-censorship properties are potentially very interesting.
350 2013-10-07 22:00:29 <gmaxwell> "Sorry, censoring minerâ you take all our transactions or none" also ... it would potentially reduce the incentive to reorg the chain to steal the prior miner's fees.
351 2013-10-07 22:20:17 <CodeShark> Going over BIP0032 again - I'm thinking it would be a good idea in general to separate internal binary standards from externally presented encodings (i.e. base58check) in all documentation and implementations
352 2013-10-07 22:20:53 <CodeShark> for instance, in much of my older code I had combined the bitcoin address formats with the cryptographic modules - but in more recent code, I've maintained a strict separation
353 2013-10-07 22:21:33 <CodeShark> there's absolutely no reason, for instance, why a secp256k1 class should know anything about base58 encoding
354 2013-10-07 22:23:27 <CodeShark> anyhow, sorry to tout the obvious :p
355 2013-10-07 22:25:52 <CodeShark> I guess the point is that I've seen a lot of code that mixes the base58 encoding stuff with core internal structures when the base58 code should strictly be confined to a very thin layer between UI and core
356 2013-10-07 22:27:35 <CodeShark> the documentation should not encourage people to think of base58 encodings as core structures
357 2013-10-07 22:27:59 <CodeShark> (esp developers)
358 2013-10-07 22:28:55 <CodeShark> programmatic interfaces should practically never be required to deal with base58 encodings
359 2013-10-07 22:29:18 <CodeShark> we could use far stronger checksums and far more efficient encodings than ASCII base58
360 2013-10-07 22:31:10 <CodeShark> the only real purpose for base58check encoding is copy/paste from clipboard, really
361 2013-10-07 22:33:53 <CodeShark> and URLs, I suppose