1 2013-08-02 00:01:49 <Graet> gmaxwell, i know u went, sorry its late Bitcoin version v0.8.3.0-g40809ae-beta () mining node Bitcoin version v0.8.2-40-g3d66111-dirty-beta (2013-05-31 07:26:44 -0700) non-mining node that also crashed
2 2013-08-02 00:02:43 <sipa> Graet: what kind of RPCs do you run against the non-mining node?
3 2013-08-02 00:03:18 <Graet> we pull data for block stats
4 2013-08-02 00:03:30 <Graet> confirms, amount etc
5 2013-08-02 00:03:40 <sipa> do you have logs for that one?
6 2013-08-02 00:04:49 <sipa> i need sleep; i'll hear it later
7 2013-08-02 00:05:10 <Graet> i'll pastebin and link you sipa
8 2013-08-02 00:05:13 <michagogo> [04:36:14] <sipa> (or playing with timestamps)
9 2013-08-02 00:05:15 <Graet> cheers, rest well
10 2013-08-02 00:05:27 <michagogo> Would that include mining with a system clock set 20 mins ahead?
11 2013-08-02 01:09:05 <warren> TheUni: please ping me when you're around
12 2013-08-02 01:12:18 <TheUni> pong
13 2013-08-02 01:41:39 <jgarzik> TheUni, what's left, on autotools? Would like to merge that.
14 2013-08-02 01:41:55 <TheUni> jgarzik: still quite a bit i'm afraid
15 2013-08-02 01:42:06 <TheUni> i have lots of work done locally
16 2013-08-02 01:42:32 <TheUni> I'm a bachelor this weekend, hoping to get it knocked out then
17 2013-08-02 01:43:07 <jgarzik> heh
18 2013-08-02 01:43:08 <jgarzik> cool
19 2013-08-02 01:43:57 <TheUni> jgarzik: mind if i shoot you a pm?
20 2013-08-02 01:46:03 <Luke-Jr> I thought autotools was ready :<
21 2013-08-02 01:48:29 <jgarzik> TheUni, sure
22 2013-08-02 01:53:17 <gavinandresen> jgarzik: I'd like to merge the payment protocol before autotools
23 2013-08-02 01:54:02 <gavinandresen> it'll require changes to auto tools, because of the new protocol buffer dependency
24 2013-08-02 01:59:50 <jgarzik> gavinandresen, as you like, but I don't think it's a big deal either way. if autotools came first, it would be a couple lines addition to configure.ac and Makefile.am
25 2013-08-02 01:59:51 <jgarzik> gavinandresen, as you like, but I don't think it's a big deal either way. if autotools came first, it would be a couple lines addition to configure.ac and Makefile.am
26 2013-08-02 02:01:22 <gavinandresen> ok. Given how much work it was to tweak gitian and mingw to do all the right things, I doubt it is just a couple lines of code, but I hope to be pleasantly surprised
27 2013-08-02 02:01:44 <TheUni> gavinandresen: can you point me to the work that was required?
28 2013-08-02 02:02:21 <gavinandresen> TheUni: sure, one sec
29 2013-08-02 02:02:44 <gavinandresen> TheUni: it is all part of https://github.com/bitcoin/bitcoin/pull/2539
30 2013-08-02 02:03:37 <gavinandresen> In particular, the changes to bitcoin-qt.pro and the addition of share/qt/protobuf.pri to use protoc as another compiler
31 2013-08-02 02:04:56 <TheUni> that's no problem, we already do the same thing to generate all of the qt files
32 2013-08-02 02:05:03 <gavinandresen> The gitian changes were to compile a native protoc, that is then used during cross-compiling (but building a target protobuf library that is linked against)
33 2013-08-02 02:05:43 <TheUni> i'm going to go ahead and guess that protoc has zero buildsystem smarts?
34 2013-08-02 02:06:18 <TheUni> wow, autotools. I take that back :)
35 2013-08-02 02:07:55 <gavinandresen> The other would-have-been-easy-if-I-knew-how-but-was-hard change required was compiling Qt with -openssl-linked, so QtNetwork uses static openssl libraries
36 2013-08-02 02:08:31 <gavinandresen> In hindsight, it might have been easier to just modify the Windows installer to ship openssl DLLs
37 2013-08-02 02:08:38 <Luke-Jr> probably smaller too
38 2013-08-02 02:08:56 <Luke-Jr> ACTION wonders if ld is smart enough to identify duplicated static libs
39 2013-08-02 02:09:19 <TheUni> Luke-Jr: not static libs, static object files
40 2013-08-02 02:09:28 <gavinandresen> QtNetwork.a with -openssl-linked doesn't have the openssl .a's in it (I don't think)
41 2013-08-02 02:09:29 <TheUni> it'll drop static functions with lto
42 2013-08-02 02:09:47 <Luke-Jr> TheUni: but LTO isn't safe yet?
43 2013-08-02 02:09:54 <Luke-Jr> or is that just Gentoo being paranoid on me?
44 2013-08-02 02:10:11 <TheUni> Luke-Jr: i've had good luck with it in >=4.7
45 2013-08-02 02:10:17 <gavinandresen> -static-linked just tells Qt not to go trying to dlopen at runtime
46 2013-08-02 02:10:24 <Luke-Jr> TheUni: our Windows builds use like 4.2 :/
47 2013-08-02 02:10:31 <TheUni> gc-sections can be used as well
48 2013-08-02 02:10:32 <Luke-Jr> gavinandresen: ah
49 2013-08-02 02:10:44 <TheUni> gavinandresen: ok, thanks. i should be able to adapt your work easy enough i think
50 2013-08-02 02:11:16 <gavinandresen> TheUni: great!
51 2013-08-02 02:11:22 <gavinandresen> I don't know nuthin about autotools....
52 2013-08-02 02:11:25 <TheUni> gavinandresen: .a's don't link with other .a's
53 2013-08-02 02:11:36 <TheUni> that's basically why libtool was created
54 2013-08-02 02:12:00 <TheUni> it's your responsibility to keep the dependency chain and link them all into the final object
55 2013-08-02 02:12:42 <TheUni> so if you built a static qt with a static openssl, you'd have to link them both into the final .exe
56 2013-08-02 02:15:02 <jgarzik> SIGH
57 2013-08-02 02:15:15 <jgarzik> oh good grief. The wiki is infected with AGPL code, https://en.bitcoin.it/wiki/Protocol_specification#getblocks
58 2013-08-02 02:15:38 <jgarzik> when our MIT/X11-licensed code is also available
59 2013-08-02 02:16:15 <jgarzik> Which is better? (a) reference implementation, liberal license or (b) not reference implementation, more restrictive license
60 2013-08-02 02:19:22 <Luke-Jr> ACTION noted that a number of months ago <.<
61 2013-08-02 02:29:49 <phantomcircuit> jgarzik, that is a lot cleaner ...
62 2013-08-02 02:29:56 <phantomcircuit> iirc there used to be pseudo code for that somewhere
63 2013-08-02 02:35:26 <jgarzik> sipa, Following up on a forum post, that jogged a memory.
64 2013-08-02 02:35:43 <jgarzik> sipa, Did the creation of CBlockHeader change the binary output of the "headers" message?
65 2013-08-02 02:37:50 <jgarzik> sipa, Looking at v0.4.0, it appears to me like we serialize a CBlock, thus including a vtx==0 trailing varint
66 2013-08-02 02:37:58 <jgarzik> sipa, but with CBlockHeader, that seems absent.
67 2013-08-02 02:39:47 <phantomcircuit> jgarzik, does it really matter?
68 2013-08-02 02:39:55 <jgarzik> sipa, vHeaders and "headers" message never set SER_BLOCKHEADERONLY
69 2013-08-02 02:40:35 <jgarzik> phantomcircuit, Sure. You read garbage after the first header, if you miss this detail, on certain new versions of bitcoind.
70 2013-08-02 02:41:18 <phantomcircuit> afaik there aren't any listening 0.4.0 nodes
71 2013-08-02 02:41:50 <jgarzik> phantomcircuit, This is a very recent change. Replace 0.4.0 with 0.7.0 if you like.
72 2013-08-02 02:41:54 <jgarzik> maybe even 0.8.09
73 2013-08-02 02:41:58 <jgarzik> 0.8.0
74 2013-08-02 02:42:21 <phantomcircuit> ah
75 2013-08-02 02:42:38 <phantomcircuit> i was thinking you mean actually 0.4.0
76 2013-08-02 02:42:44 <phantomcircuit> which would have been a bit pedantic :)
77 2013-08-02 02:42:57 <jgarzik> Change merged Nov 24, 2012.
78 2013-08-02 02:43:14 <jgarzik> pull req #2013
79 2013-08-02 02:43:33 <phantomcircuit> so you'd end up with corrupted headers entries
80 2013-08-02 02:43:40 <phantomcircuit> after the first one
81 2013-08-02 02:43:41 <jgarzik> https://github.com/bitcoin/bitcoin/pull/2013
82 2013-08-02 02:43:51 <jgarzik> phantomcircuit, correct
83 2013-08-02 02:44:00 <phantomcircuit> or if you were being smart you'd hit an assert verifying that txn_count == 0
84 2013-08-02 02:44:37 <jgarzik> canary values are not always tripped by garbage data, especially with extra bits are zero-initialized ;p
85 2013-08-02 02:44:40 <jgarzik> but I get the point
86 2013-08-02 02:49:37 <phantomcircuit> i should scan the bitcoin network again for versions
87 2013-08-02 02:51:06 <Luke-Jr> wow, 0.8.x has almost taken over the whole network already
88 2013-08-02 02:54:25 <jgarzik> ACTION is writing an SPV client in node.js (BitPay likes node.js), and is dealing with this and bloom filter issue
89 2013-08-02 02:54:45 <jgarzik> from SPV client perspective, it would be useful to simply assume public nodes are >= 0.8.1 or whatever......
90 2013-08-02 02:55:37 <phantomcircuit> jgarzik, just run your own local bitcoind node and only do spv stuff with it
91 2013-08-02 02:55:44 <phantomcircuit> that's actually what im doing :/
92 2013-08-02 02:56:33 <phantomcircuit> Luke-Jr, initial results suggest that the vast majority of the network is 0.8.1/0.8.3
93 2013-08-02 02:59:46 <phantomcircuit> http://pastebin.com/raw.php?i=Q7CiaUXc
94 2013-08-02 02:59:48 <phantomcircuit> initial results
95 2013-08-02 03:01:31 <jgarzik> OK
96 2013-08-02 03:02:09 <jgarzik> The CBlockHeader merge 7818d230a first appeared in v0.8.0.
97 2013-08-02 03:03:01 <jgarzik> So, "headers" response is different for <= 0.7.2 and >= 0.8.0
98 2013-08-02 03:03:22 <Diablo-D3> jgarzik: but dont we already know thats possible?
99 2013-08-02 03:03:30 <Diablo-D3> because of the bdb fuckery
100 2013-08-02 03:03:50 <jgarzik> Diablo-D3, no
101 2013-08-02 03:04:08 <Diablo-D3> so yet another 0.8.x vs earlier issue?
102 2013-08-02 03:04:33 <phantomcircuit> jgarzik, did the protocol version change in 0.8.0?
103 2013-08-02 03:04:35 <phantomcircuit> im guessing no
104 2013-08-02 03:05:18 <jgarzik> Diablo-D3, yes
105 2013-08-02 03:05:44 <Diablo-D3> jgarzik: #goddamnitsomuch
106 2013-08-02 03:06:23 <phantomcircuit> jgarzik, yeah actually it did
107 2013-08-02 03:06:24 <phantomcircuit> convenient
108 2013-08-02 03:06:38 <phantomcircuit> protocol version 70001 doesn't have txn_count
109 2013-08-02 03:06:57 <jgarzik> phantomcircuit, Yes. Bloom filters were added.
110 2013-08-02 03:07:03 <phantomcircuit> ah right
111 2013-08-02 03:07:06 <jgarzik> protover rev for that
112 2013-08-02 03:07:20 <phantomcircuit> ok so errata that the headers format changed also
113 2013-08-02 03:07:37 <phantomcircuit> should be easy enough to work around and conveniently means not having to check sub_version
114 2013-08-02 03:11:08 <Luke-Jr> phantomcircuit: http://luke.dashjr.org/programs/bitcoin/files/charts/security.html
115 2013-08-02 03:11:30 <Luke-Jr> phantomcircuit: or http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
116 2013-08-02 03:12:01 <phantomcircuit> Luke-Jr, i assume that includes nodes which connected to you?
117 2013-08-02 03:12:08 <Luke-Jr> phantomcircuit: nope, just listening nodes
118 2013-08-02 03:12:16 <Luke-Jr> nobody connects to bitcoin-seeder nodes (yet)
119 2013-08-02 03:12:39 <phantomcircuit> there's no way there's 45k 0.8.1 nodes...
120 2013-08-02 03:12:52 <Luke-Jr> phantomcircuit: have the list of IPs??? http://luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt
121 2013-08-02 03:13:18 <Luke-Jr> holy crap, I sure hope there's something wrong with the graph here: http://luke.dashjr.org/programs/bitcoin/files/charts/bestblocks.html
122 2013-08-02 03:13:35 <Luke-Jr> otherwise.. only 18% are on the current best block? :|
123 2013-08-02 03:13:41 <phantomcircuit> firefox is not happy
124 2013-08-02 03:13:51 <Luke-Jr> maybe I need to filter it somehow better
125 2013-08-02 03:13:58 <Luke-Jr> phantomcircuit: it's 50 MB
126 2013-08-02 03:16:33 <TheUni> gavinandresen: any ETA for getting the protobuf stuff in?
127 2013-08-02 03:16:56 <petertodd> Luke-Jr: what exactly is that graph of?
128 2013-08-02 03:17:14 <petertodd> Luke-Jr: (best block graph)
129 2013-08-02 03:17:37 <Luke-Jr> petertodd: best block reported by listening nodes. I'm guessing it must be including nodes I haven't connected to in a long time or something :/
130 2013-08-02 03:17:58 <petertodd> Luke-Jr: hmm... I thought we didn't tell peers what our best blocks were, only our startingheight
131 2013-08-02 03:18:01 <gavinandresen> TheUni: as soon as I get an ACK or two
132 2013-08-02 03:18:07 <Luke-Jr> petertodd: same thing
133 2013-08-02 03:18:22 <Luke-Jr> petertodd: startingheight = best block at time connection is established
134 2013-08-02 03:18:32 <petertodd> Luke-Jr: right, but what happens with a long-lived peer?
135 2013-08-02 03:18:33 <petertodd> Luke-Jr: right, but what happens with a long-lived peer?
136 2013-08-02 03:18:49 <Luke-Jr> gavinandresen: something I can easily test on testnet?
137 2013-08-02 03:18:59 <gavinandresen> Luke-Jr: yes
138 2013-08-02 03:19:02 <TheUni> gavinandresen: ok. just trying to figure out timing for my stuff. sounds like it should sync up nicely.
139 2013-08-02 03:19:07 <TheUni> i'll wait for yours and rebase
140 2013-08-02 03:19:08 <Luke-Jr> petertodd: bitcoin-seeder doesn't do long-lived connections I think
141 2013-08-02 03:20:03 <petertodd> Luke-Jr: hmm... check that - doesn't seem right to me
142 2013-08-02 03:20:16 <Luke-Jr> gavinandresen: https://github.com/gavinandresen/QA/blob/master/PaymentRequestTest.md is latest?
143 2013-08-02 03:20:34 <Luke-Jr> petertodd: there's a heck of a lot more peers than there used to be - it's probably just not polling them as often
144 2013-08-02 03:21:12 <gavinandresen> Luke-Jr: compile from the payment request branch or get binaries from the pull-tester...
145 2013-08-02 03:21:27 <Luke-Jr> gavinandresen: right, just wanted to check I was using the right test plan
146 2013-08-02 03:21:46 <petertodd> Luke-Jr: sounds about right, I just tried restarting a node and my reconnecting incoming peers all have recent block heights
147 2013-08-02 03:21:55 <Luke-Jr> also, I'm planning to test master with paymentrequest merged in..
148 2013-08-02 03:21:57 <gavinandresen> Luke-Jr: yes, that's the right test plan. If you want extra credit, test over Tor, too
149 2013-08-02 03:22:17 <Luke-Jr> hmm, Tor doesn't like me, but I'll give it a shot
150 2013-08-02 03:22:51 <gavinandresen> ???. speaking of which, I need to test over Tor, I taught the server-side code to replace $CLIENT_IP in payment messages so I can see what IP address it sees....
151 2013-08-02 03:24:26 <Luke-Jr> I wonder if theymos can get the bitcoin reddit to promote test plans with "paid" ad type stuff
152 2013-08-02 03:25:08 <Diablo-D3> >ads
153 2013-08-02 03:25:10 <Diablo-D3> >reddit
154 2013-08-02 03:25:11 <Diablo-D3> wat
155 2013-08-02 03:25:13 <Luke-Jr> wow, you put bounties on this and it still hasn't been tested? XD
156 2013-08-02 03:25:52 <Luke-Jr> whee, 30 weeks behind on testnet
157 2013-08-02 03:28:15 <gavinandresen> I paid a couple of bounties, but stopped testing because of the openssl-linked issue
158 2013-08-02 03:28:36 <gavinandresen> (then spent a lot of time working that out, then moved to Australia....)
159 2013-08-02 03:30:55 <Luke-Jr> hmm
160 2013-08-02 03:31:22 <Luke-Jr> I wonder what happens if I try to use payment protocol on a testnet-in-a-box.. ie, if the merchant has a transaction with invalid-to-them inputs
161 2013-08-02 03:32:10 <maaku> what does psmisc do and why is it in the deps-win32.yml?
162 2013-08-02 03:32:18 <Luke-Jr> maaku: killall command
163 2013-08-02 03:32:44 <maaku> ah ok thank you
164 2013-08-02 03:41:00 <gavinandresen> Luke-Jr: the payment protocol doesn't affect transaction confirmation/acceptance at all, transactions are still confirmed through the block chain. The demo website code doesn't validate the transaction in the Payment message at all.
165 2013-08-02 03:42:51 <Luke-Jr> hmm
166 2013-08-02 03:43:18 <Luke-Jr> for some reason, the link isn't doing anything
167 2013-08-02 03:43:34 <Luke-Jr> just silently exiting
168 2013-08-02 03:43:42 <Luke-Jr> I wonder if my mainnet client is interfering
169 2013-08-02 03:44:10 <Luke-Jr> oh, nope.. manually opening testnet client reveals a bunch of sends in the tab
170 2013-08-02 03:49:42 <gavinandresen> Luke-Jr: running on Linux?
171 2013-08-02 03:50:31 <gavinandresen> ??? and can you run a stock 0.8.3 and see if clicking on a bitcoin: link behaves the same?
172 2013-08-02 03:51:13 <gavinandresen> (mmm??? except I'm not sure 0.8.3 handled test net bitcoin: links properly)
173 2013-08-02 03:52:40 <TheUni> gavinandresen: feel free to ping me for issues like openssl link in the future. That's my bread+butter.
174 2013-08-02 03:53:35 <gavinandresen> mmmm??? bread and butter....
175 2013-08-02 03:54:17 <TheUni> sounds like your problem is that you were using vegemite instead ;)
176 2013-08-02 03:56:56 <sipa> jgarzik: the headers message doesn't use CBlockHeader but CBlock, specifically for that reason
177 2013-08-02 03:57:12 <sipa> jgarzik: there is even a comment about it in the code
178 2013-08-02 03:57:24 <sipa> jgarzik: does it somehow work differently?
179 2013-08-02 04:03:44 <arioBarzan> there is a way better than sipa's one in pull/2861 for adding watch-only addresses. anybody interested to discuss the issue?
180 2013-08-02 04:06:41 <Luke-Jr> gavinandresen: yes, Linux.
181 2013-08-02 04:06:47 <Luke-Jr> I just found a potential vulnerability :p
182 2013-08-02 04:07:22 <gavinandresen> Luke-Jr: in the payment request code? cool!
183 2013-08-02 04:07:36 <Luke-Jr> sortof. it's rendering HTML in the PaymentACK message :/
184 2013-08-02 04:08:21 <gavinandresen> I think wumpus mentioned that??? should be a trivial fix
185 2013-08-02 04:08:28 <Luke-Jr> probably
186 2013-08-02 04:08:45 <Luke-Jr> I think I just crashed my browser trying to do a different one :/
187 2013-08-02 04:12:18 <sipa> arioBarzan: not again, please
188 2013-08-02 04:12:35 <sipa> arioBarzan: if you really dislike it, implement it differently yourself
189 2013-08-02 04:17:05 <Luke-Jr> yeah, my browser's hung
190 2013-08-02 04:17:07 <Luke-Jr> blah
191 2013-08-02 04:18:07 <d34th> Luke-Jr: pastebin the html?
192 2013-08-02 04:28:33 <arioBarzan> sipa: I understand your frustration. I don't have intention to bother you again about this specific issue.
193 2013-08-02 04:30:14 <arioBarzan> Thanks to sipa's clarification about his frustration with my recent criticism, I correct myself. is there anybody other than sipa wants to give me a chance to explain a suggestion about the algorithm for watch-only implementation?
194 2013-08-02 04:30:21 <arioBarzan> I told algorithm because although I could write code, that code, I suspect, would not be of a good quality. However that doesn't mean that people like me do not understand the algorithm behind the code.
195 2013-08-02 04:32:43 <gavinandresen> what is the use-case for watch-only addresses that encrypt-with-a-random-password wallets doesn't solve?
196 2013-08-02 04:33:07 <sipa> gavinandresen: it needs you having the private key
197 2013-08-02 04:33:25 <sipa> it doesn't work with p2sh (which now have a crippled wallet detection)
198 2013-08-02 04:33:44 <gavinandresen> sipa: what is the p2sh use case?
199 2013-08-02 04:33:55 <Luke-Jr> arioBarzan: watch-only makes so much more sense after HD wallets
200 2013-08-02 04:34:13 <sipa> detecting transactions to a p2sh address for which you do not have all keys (but some)
201 2013-08-02 04:34:17 <Luke-Jr> gavinandresen: see a corporate account?
202 2013-08-02 04:34:26 <sipa> or even none at all, if you do the signing separately
203 2013-08-02 04:35:09 <freewil> see https://github.com/bitcoin/bitcoin/issues/1928
204 2013-08-02 04:35:46 <gavinandresen> sipa: I'm still not seeing the use case. If you want to detect payments to a p2sh address, you need to addmultisigaddress in any case, yes?
205 2013-08-02 04:36:09 <gavinandresen> the wallet doesn't automatically create every combinatorial p2sh address for the addresses in your wallet.....
206 2013-08-02 04:36:17 <sipa> gavinandresen: of course not
207 2013-08-02 04:36:34 <sipa> gavinandresen: but now ismine only works if you have all keys for a multisig
208 2013-08-02 04:36:39 <CodeShark> creating a multisig redeemscript doesn't require private keys
209 2013-08-02 04:36:49 <gavinandresen> right???.
210 2013-08-02 04:37:00 <sipa> which makes senae
211 2013-08-02 04:37:16 <sipa> but you also want to be able to detect transactions that interest you
212 2013-08-02 04:37:29 <gavinandresen> I'm reacting negatively because I managed to confuse MYSELF with watch-only addresses and blockchain.info
213 2013-08-02 04:37:29 <sipa> even if you can't spend them using the wallet code
214 2013-08-02 04:37:50 <sipa> you may have different means to spend them
215 2013-08-02 04:37:55 <gavinandresen> I added a watch-only blockchain.info address, promptly forgot about it, then was confused when I saw my balance was bigger than I remembered
216 2013-08-02 04:38:04 <CodeShark> in any merchant setting, the transaction processing apps will undoubtedly be different than the apps used to sign from accounts or withdraw bitcoins
217 2013-08-02 04:38:08 <gavinandresen> ??? so I tried to spend, and was further confused when the "send" failed
218 2013-08-02 04:38:35 <CodeShark> watch-only wallets are a first step towards support for transaction processing
219 2013-08-02 04:38:55 <CodeShark> in a real scalable sense
220 2013-08-02 04:38:55 <sipa> well i don't expect that thia will be very gui-integrated
221 2013-08-02 04:39:09 <gavinandresen> Watch-only wallets I'm all for. Watch-only addresses???.
222 2013-08-02 04:39:10 <sipa> the real solution for that is separate wallets imho
223 2013-08-02 04:39:40 <sipa> i don't think watch-only wallets if viable before we have multiwallet
224 2013-08-02 04:39:48 <gavinandresen> I agree. So back to my original question: is there a compelling use-case that makes you think we need this in the RPC interface now?
225 2013-08-02 04:40:26 <sipa> it's easy, and there is a lot of demand for it
226 2013-08-02 04:40:51 <CodeShark> the fact multiwallet haven't been integrated yet was one of the main reasons I've hesitated on 2121
227 2013-08-02 04:40:51 <sipa> our existing interface is artificially crippled to require the private key to be able to watch transactions
228 2013-08-02 04:41:09 <CodeShark> multiwallet support is more fundamental
229 2013-08-02 04:41:22 <gavinandresen> I see, so the use case is "detect payments"
230 2013-08-02 04:41:26 <CodeShark> yes
231 2013-08-02 04:41:26 <sipa> yes
232 2013-08-02 04:42:05 <arioBarzan> if we had watch-only already implemented, we could add code for sweeping private key of a normal address and essentially make it watch-only.
233 2013-08-02 04:42:10 <gmaxwell> gavinandresen: makes life easier for people who have secure offline keys (the encrypt and toss feels pretty unsafe to do), makes them have less reason to depend on not always online websites that already offer the functionality. And its really useful for excercising the wallet code by adding a bunch of random stuff.
234 2013-08-02 04:43:05 <gmaxwell> and, yea, I think it goes hand in hand with multiwallet.. ideally you don't mix spendable and watching wallet stuff.
235 2013-08-02 04:43:15 <gavinandresen> Mmm. Are we imagining people will detect payments with -walletnotify, or list transactions? Or getbalance?
236 2013-08-02 04:43:32 <gavinandresen> If it just affected -walletnotify then I think I'd be more comfortable with the feature
237 2013-08-02 04:43:32 <sipa> either; or listunspent
238 2013-08-02 04:43:50 <freewil> i use listsinceblock
239 2013-08-02 04:43:51 <gmaxwell> listunspent is a lot of my thinking, in fact.
240 2013-08-02 04:43:52 <CodeShark> a subscription protocol would be better than -walletnotify or polling
241 2013-08-02 04:43:53 <gavinandresen> Adding watch-only transactions to get balance makes me VERY nervous
242 2013-08-02 04:44:12 <sipa> walletnotify is useless without a way to query the wallet about it...
243 2013-08-02 04:44:16 <sipa> gavinandresen: how so?
244 2013-08-02 04:44:41 <sipa> i can make getbalance not count watchonly stuff
245 2013-08-02 04:44:54 <gavinandresen> There's probably lots of code that assumes that you can always send getbalance bitcoins
246 2013-08-02 04:45:03 <gmaxwell> thats kind of why I said goes hand in hand with multiwallet.. mixing is weird. from a code perspective it makes sense that everything should handle the mixed case, but if you're going to mix it would really be good for the balance outputs to be split into watched balance and spendable balance.
247 2013-08-02 04:45:05 <sipa> i doubt that
248 2013-08-02 04:45:22 <gmaxwell> external code.
249 2013-08-02 04:45:40 <sipa> creating transactions requests the set of spendable coins, and watxh-only ones are not included there
250 2013-08-02 04:45:44 <gavinandresen> There might be audit code that checks to make sure list-all-transactions-and-sum-up-amounts matches get balance....
251 2013-08-02 04:46:11 <gmaxwell> it would with watch.
252 2013-08-02 04:46:18 <gavinandresen> I'm uncomfortable because watch-only transactions might break people's assumptions
253 2013-08-02 04:46:39 <gavinandresen> ??? and, therefore, break their code in weird, unexpected ways.
254 2013-08-02 04:47:10 <sipa> well yes, things will change of course
255 2013-08-02 04:47:22 <gmaxwell> at least its safe if you do not use it.
256 2013-08-02 04:47:24 <warren> how different is watch-only from locked wallet without passphrase? (sorry dumb question)
257 2013-08-02 04:47:27 <gmaxwell> Nothing changes out from under you.
258 2013-08-02 04:47:36 <sipa> warren: answered that above
259 2013-08-02 04:47:39 <gavinandresen> We can say "if you add a watch-only address, then be careful" , but I just have an uncomfortable feeling that doing the quick&easy thing here will come back to bite us
260 2013-08-02 04:48:15 <gmaxwell> gavinandresen: That all goes away, I think, if we use multiwallet and a wallet is either all or no watch, enh?
261 2013-08-02 04:48:27 <CodeShark> that was the original idea, gmaxwell
262 2013-08-02 04:48:31 <sipa> yeah
263 2013-08-02 04:48:35 <gavinandresen> Conservative thing would be to have -walletnotify tell you about watch-only, and get transaction return them, but no change to other API
264 2013-08-02 04:48:57 <gavinandresen> And that would match "the feature is detecting transactions"
265 2013-08-02 04:49:17 <CodeShark> sipa decided to bring the watch-only address stuff up to date because of the demand for that specific functionality and the fact it is far simpler than the multiwallet stuff
266 2013-08-02 04:49:21 <gmaxwell> that would also make it useless for "I need to gather the data to spend these with an offline signing wallet"
267 2013-08-02 04:49:39 <sipa> if multiwallet was further along, i would suggest to only have watch-only wallets, and only enable importaddress for those
268 2013-08-02 04:49:42 <gavinandresen> gmaxwell: ?? get transaction / getrawtransaction ??
269 2013-08-02 04:49:55 <gavinandresen> what other data do you need?
270 2013-08-02 04:50:04 <sipa> gettransaction, listtransactions, getbalance "account", listunspent, ...
271 2013-08-02 04:50:21 <CodeShark> it wouldn't take me very long to finish integrating the multiwallet stuff - just been busy with a bunch of other stuff lately
272 2013-08-02 04:50:21 <sipa> are all useful for detecting and creating transactions for which you have keys offline
273 2013-08-02 04:50:49 <CodeShark> I already had working multiwallet implementations for both RPC and Bitcoin-Qt several months ago
274 2013-08-02 04:50:58 <sipa> i know :(
275 2013-08-02 04:51:01 <gmaxwell> gavinandresen: what sipa said. hm would your concern be satisfied if only balance were split into two fields? I think that would be fairly straight forward in the current implementation (minus gui impact)
276 2013-08-02 04:51:02 <sipa> ACTION pokes CodeShark
277 2013-08-02 04:51:47 <gavinandresen> gmaxwell: yes, that would go a long way
278 2013-08-02 04:51:47 <sipa> listunspent and validateaddress already distinguish the two cases
279 2013-08-02 04:52:07 <arioBarzan> gavinandresen: what if people want sweep one specific private key or even never give it to the bitcoind? watch-only would help a lot.
280 2013-08-02 04:52:08 <sipa> that would be easy i think, yes
281 2013-08-02 04:53:33 <gavinandresen> if old code gets old behaviour I'll be 100% happy
282 2013-08-02 04:53:47 <sipa> it does?
283 2013-08-02 04:53:58 <sipa> old code doesn't call importaddress
284 2013-08-02 04:54:02 <CodeShark> if you never use importaddress, you won't get into trouble
285 2013-08-02 04:54:10 <CodeShark> if you do, you should know what you're doing
286 2013-08-02 04:54:12 <sipa> but i see your point
287 2013-08-02 04:54:43 <gavinandresen> I mean: old code that calls listunspent or list transactions shouldn't see watch-only. New code can pass an extra flag, or you run with a -watchonly command-line flag, or....
288 2013-08-02 04:54:48 <CodeShark> and yes, mixing watch-only with spendable addresses in a single wallet means less clear usability
289 2013-08-02 04:55:26 <CodeShark> I'll see if I find some time these days to finish integrating 2407
290 2013-08-02 05:05:05 <arioBarzan> for a spend transaction, it would be nice to prioritize the spendable coins and then if those were enough it would be signed with existing private keys. otherwise it could give us a rawtransaction and then tell "go ahead sign it and send it yourself"
291 2013-08-02 05:06:59 <Luke-Jr> gavinandresen: confirmed master testnet does not make itself visible opening URIs
292 2013-08-02 05:11:55 <gavinandresen> Luke-Jr: thanks! I didn't change any of that code, so expected it to work the same.
293 2013-08-02 05:12:35 <gavinandresen> Luke-Jr: and tweaking the GUI for all this will have to wait for somebody who actually knows Qt...
294 2013-08-02 05:13:28 <Luke-Jr> gavinandresen: it may be possible my window manager is doing some kind of stupidly aggressive focus stealing prevention
295 2013-08-02 05:13:46 <Luke-Jr> although I have it configured to go easy on stuff :/
296 2013-08-02 05:14:12 <Luke-Jr> lol, actually, it looks like I have focus-stealing prevention disabled entirely
297 2013-08-02 05:14:19 <Luke-Jr> so much for that theory
298 2013-08-02 05:36:33 <gmaxwell> arioBarzan: I like the idea of being able to do that kind of thing, but that requires totally redoing our APIs. I suspect we'll need to make those changes for multiparty wallets too and that should probably drive that change.
299 2013-08-02 09:31:37 <tgs3> you know the new bitcoin.org page is horribly unusable, right?
300 2013-08-02 09:32:44 <tgs3> on other projects like debian.org or i2p it takes me 0.5 second on avg to find the download link, with bitcoin.org its 20 sec and counting :)
301 2013-08-02 09:33:07 <tgs3> not everyone will know that it's on github
302 2013-08-02 09:35:34 <sipa> i think the idea is to have bitcoin.org move away from being about the reference implementation, and more about the ecosystem as a whole
303 2013-08-02 09:35:44 <tgs3> well it blows
304 2013-08-02 09:35:59 <sipa> feel free to make suggestions
305 2013-08-02 09:36:03 <gmaxwell> tgs3: make proposed patches.
306 2013-08-02 09:36:23 <tgs3> + <a href="/en/download/">Download Bitcoin client</a>
307 2013-08-02 09:36:33 <gmaxwell> I think your commentary blows, but I propose you patch it by submitting and hashing out improvements instead of just complaints. :P
308 2013-08-02 09:36:36 <sipa> http://bitcoin.org/en/choose-your-wallet
309 2013-08-02 09:36:46 <tgs3> gmaxwell: already pasted the diff :)
310 2013-08-02 09:37:30 <sipa> linking to download/ directly would be treating the reference client specially
311 2013-08-02 09:37:49 <sipa> though i do agree that it's not obvious at all where to find download links in general
312 2013-08-02 09:38:05 <tgs3> what is bad in linkint to the MAIN client?!
313 2013-08-02 09:38:22 <gmaxwell> some people prefer that new users be directed to other options instead.
314 2013-08-02 09:38:51 <gmaxwell> (I leave that as the weasily 'some people' because I don't quite agree, not really being happy with any of the alternatives)
315 2013-08-02 09:39:08 <tgs3> + <a href="/en/download/">Download Bitcoin reference client</a> or <a href="https://duckduckgo/?q=bitcoin+client+download">Search online for other clients on your own</a>
316 2013-08-02 09:39:46 <tgs3> also we could link bitcoin.it wiki, and wikipedia, list of bitcoin clients.
317 2013-08-02 09:39:47 <gmaxwell> You are missing the point there. Bitcoin.org is not supposted to be the reference client.
318 2013-08-02 09:40:14 <tgs3> gmaxwell: yes, this point imight be invalid, because users expect it to be.
319 2013-08-02 09:40:22 <gmaxwell> And the argument that it should be is weakened by the current poor initial expirence with the reference client. If it were made much better we'd have a stronger thing to do there.
320 2013-08-02 09:40:33 <tgs3> same like users expect to go with skype.com and download "the skype"
321 2013-08-02 09:40:49 <sipa> tgs3: go to bittorrent.org
322 2013-08-02 09:40:54 <sipa> tgs3: find me a download link
323 2013-08-02 09:41:05 <gmaxwell> tgs3: skype doesn't then sit around unusable for two days, thrashing the computer.. etc.
324 2013-08-02 09:41:28 <tgs3> sipa: if we are like them, some users will be turned off right at the begining
325 2013-08-02 09:41:38 <tgs3> gmaxwell: then make a bounty to fix refclient? :)
326 2013-08-02 09:43:28 <sipa> the reference client has a moral obligation to represent the highest security level the system is intended to provide, imho
327 2013-08-02 09:43:30 <tgs3> can we then link https://en.bitcoin.it/wiki/Clients
328 2013-08-02 09:43:58 <tgs3> can we then link https://en.bitcoin.it/wiki/Clients first, and then "or download Orginal Client that is most reviewed but also less comfortable to use" ?
329 2013-08-02 09:44:14 <sipa> that's pretty much what the choose your wallet page says
330 2013-08-02 09:44:25 <tgs3> btw bitcoin.it has mysql connection limit problems
331 2013-08-02 09:49:45 <Cylta> What is the name of protocol that able to tranfer data through _sound_? (like in modems). So, speaker from one side and microphone from other side would able to transfer data between computers.
332 2013-08-02 09:51:48 <gmaxwell> sipa: agreed in general, but security that "no one" uses is zero.
333 2013-08-02 09:52:15 <sipa> well, it's not like nobody uses it
334 2013-08-02 09:52:22 <gmaxwell> sipa: so decisions to not do things to optimize the initial expirence will further result in people being recommended away from the reference software.
335 2013-08-02 09:52:54 <sipa> oh, i don't mean not optimize (hell, i think i've been contributing to that part significantly...)
336 2013-08-02 09:52:55 <gmaxwell> I can't believe that there is no way to have our cake and eat it too.
337 2013-08-02 09:53:11 <gmaxwell> sipa: yea, you're doing all that work. :P I'm just making sure you don't realize how important it is!