1 2014-01-29 00:00:39 <brisque> jgarzik: interesting that it's bitcoinj, I wasn't expecting that.
2 2014-01-29 00:07:42 <brisque> jgarzik: https://github.com/blockchain/Sharedcoin/commit/efb4c712a176b5d80f17d04f437f147f0a1039e1#diff-eb215df10bf99447deff1be803570019L123
3 2014-01-29 00:08:54 <brisque> I'm sure they've changed it now, but there's nothing quite like hardcoded API keys.
4 2014-01-29 00:13:50 <Ademan-remote> are there any alternatives to TP's testnet faucet?
5 2014-01-29 00:14:32 <Ademan-remote> nvm, I should RTFM more
6 2014-01-29 00:47:16 <lechuga_> any1 know much about ripple?
7 2014-01-29 00:47:33 <lechuga_> curious what the #bitcoin-dev view is on them
8 2014-01-29 00:50:13 <lianj> i o u
9 2014-01-29 00:58:15 <lechuga_> ?
10 2014-01-29 01:01:54 <lechuga_> ah just got lianj's reference
11 2014-01-29 02:00:06 <ProfMac> I want to read the code that decides which chain to use/orphan. I want to clarify the "length" vs "total difficulty" ideas. Can someone point me to a source file name, and an identifier or line number to search?
12 2014-01-29 02:04:23 <sipa> ProfMac: https://github.com/bitcoin/bitcoin/blob/v0.8.6/src/main.cpp#L1243
13 2014-01-29 02:04:46 <sipa> setBlockIndexValid contains references to all valid blocks, ordered by amount of work
14 2014-01-29 02:17:45 <ProfMac> sipa, thanks.
15 2014-01-29 02:23:33 <swulf--> sipa: i had a thought about bip70, the payment protocol and was wondering what you thought
16 2014-01-29 02:41:48 <ProfMac> also ? [20:04] <sipa> ProfMac: https://github.com/bitcoin/bitcoin/blob/v0.8.6/src/main.cpp#L2585
17 2014-01-29 03:11:19 <super3> is Luke-Jr around? i'm just about done with proof-of-pizza
18 2014-01-29 03:24:24 <ProfMac> what is proof-of-pizza?
19 2014-01-29 03:31:08 <Luke-Jr> super3:
20 2014-01-29 03:31:18 <Luke-Jr> what are you doing with it?
21 2014-01-29 03:31:22 <brisque> Luke-Jr: https://bitcointalk.org/index.php?topic=437841.0
22 2014-01-29 03:56:24 <SomeoneWeird> super3, lol that's great
23 2014-01-29 03:57:17 <super3> ha ha, have Luke-Jr and TheBlueMatt to thank
24 2014-01-29 06:24:17 <michagogo> cloud|super3: what's proof of pizza?
25 2014-01-29 06:26:21 <justanotheruser> michagogo|cloud: pretty cool. It is ASIC resistant and has backing of 3 bitcoin devs.
26 2014-01-29 06:26:32 <michagogo> cloud|...uh
27 2014-01-29 06:35:17 <sipa> justanotheruser: baking, not backing
28 2014-01-29 06:55:47 <monolithik> anyone have some unused testnet coins they can send me? the faucet seems to be broken
29 2014-01-29 07:03:05 <michagogo> cloud|monolithik: I'm not at my computer atm, or I would send you some
30 2014-01-29 07:03:06 <michagogo> cloud|(And I can easily give you unused ones)
31 2014-01-29 07:03:23 <Luke-Jr> monolithik: you forgot to give an address
32 2014-01-29 07:05:45 <michagogo> cloud|Luke-Jr: I think next time someone does that I'll mine them a block onto a new address and just give them the privkey
33 2014-01-29 07:12:21 <monolithik> thanks Luke-Jr & michagogo|cloud, someone else in #bitcoin sent me some already.
34 2014-01-29 08:12:51 <McJuicy> hey guys, I have a question about getting started on developing the bitcoind client
35 2014-01-29 08:13:21 <McJuicy> what IDE / program should I use to get an overview of the code
36 2014-01-29 08:13:50 <McJuicy> I can understand the pieces, but I'm having a hard time understanding the project as a whole.
37 2014-01-29 08:13:56 <McJuicy> Any suggestions?
38 2014-01-29 08:35:07 <sipa> MCM-Mike: i personally don't use an ide
39 2014-01-29 08:35:34 <sipa> i think the people working on the gui use qt creator
40 2014-01-29 08:35:57 <sipa> eh
41 2014-01-29 08:36:04 <wumpus> the guy left already...
42 2014-01-29 09:08:12 <stonecoldpat> whats the best method to read the block chain on your computer?
43 2014-01-29 09:08:29 <stonecoldpat> (so parse it through another program)
44 2014-01-29 09:17:51 <wumpus> stonecoldpat: depends on what you want to do, you can access the blockchain from bitcoind with 'getblockhash' and 'getblock' command
45 2014-01-29 09:19:13 <wumpus> stonecoldpat: you can get the parsed as well as unparsed data
46 2014-01-29 11:15:46 <stonecoldpat> wumpus: I want to do some analysis of the entire chain, so im not sure if those websites provide that type of service (being able to query each transaction)
47 2014-01-29 11:16:07 <stonecoldpat> wumpus: i know the blockchain is stored locally, not sure if someone has made a program that can do magic on it
48 2014-01-29 11:18:29 <wumpus> stonecoldpat: I'm not talking about a website
49 2014-01-29 11:18:44 <wumpus> stonecoldpat: I just mentioned RPC commands which are already part of bitcoind
50 2014-01-29 11:18:58 <wumpus> no need for any external website
51 2014-01-29 11:20:17 <stonecoldpat> ahhhh ok
52 2014-01-29 11:20:20 <stonecoldpat> i understand what you mean haha sorry
53 2014-01-29 11:20:55 <wumpus> you can easily use those to go over the entire blockchain
54 2014-01-29 11:20:58 <stonecoldpat> i understand now, ill have a look into that method
55 2014-01-29 11:21:06 <stonecoldpat> yeah thanks for the heads up
56 2014-01-29 12:29:57 <abishek> how do I get the balance of my wallet using RPC with minConf>=5
57 2014-01-29 12:31:06 <wumpus> getbalance "*" 5 ?
58 2014-01-29 12:31:34 <abishek> wumpus, * indicates all accounts?
59 2014-01-29 12:31:52 <wumpus> it's a bit sneaky as it's not mentioned in the help
60 2014-01-29 12:31:57 <wumpus> yes it means all
61 2014-01-29 12:32:19 <abishek> yes, i had spent about an hour to figure this out. Thnx a lot
62 2014-01-29 12:32:35 <wumpus> pretty misleading, it doesn't do anything with accounts actually when you speicfy "*"
63 2014-01-29 12:32:59 <sipa> yeah, i wish there were separate calls getbalance and getaccountbalance :)
64 2014-01-29 12:33:14 <sipa> so we could scrap the accounts stuff without leaving legacy arguments in old rpcs
65 2014-01-29 12:33:17 <sipa> :)
66 2014-01-29 12:33:27 <wumpus> I guess JSON null would have been better for leaving out non-used arguments, instead of giving a special magical value of '*', but hey it's impossible to change anymore
67 2014-01-29 12:33:31 <wumpus> sipa: yes!
68 2014-01-29 12:35:49 <disident> Hello, where/how can i get testnets coins quick ?
69 2014-01-29 12:35:50 <disident> thanks
70 2014-01-29 12:45:16 <wumpus> anyway, updated the doc and examples https://github.com/bitcoin/bitcoin/pull/3597/files
71 2014-01-29 12:45:59 <abishek> wumpus, I am using PHP to make RPC calls, when there is an error on the RPC call, how do I get the error message? All I receive is a HTTP 500 error. thats all
72 2014-01-29 12:47:38 <wumpus> abishek: you should get a more detailed error structure with the error
73 2014-01-29 12:49:13 <wumpus> (the resulting object has a non-null "error" field if there was an error)
74 2014-01-29 12:49:25 <CodeShark> abishek, I would highly recommend testing out the RPC calls by using a command line tool like curl before attempting any integration with any apps
75 2014-01-29 12:50:06 <abishek> CodeShark, with curl, it works but when I perform an RPC call using an RPC client, it throws an error and I am not able to understand what is causing it
76 2014-01-29 12:51:20 <CodeShark> 500 server error doesn't sound like bitcoind
77 2014-01-29 12:52:05 <wumpus> the 500 is generated here: https://github.com/bitcoin/bitcoin/blob/master/src/rpcserver.cpp#L342
78 2014-01-29 12:53:01 <CodeShark> hmm
79 2014-01-29 12:53:33 <wumpus> I don't think it's nice to return a HTTP level error in case of an application error, but it's always been like that and it would be near-impossible to change
80 2014-01-29 12:54:51 <abishek> its so difficult to actually understand what the error is, atleast if it get written to a log file on bitcoin as to what the error was, will be helpful to understand
81 2014-01-29 12:55:32 <wumpus> is there a way to still get the received data when it signals an error? ie, you need the message attached to the 500 response
82 2014-01-29 12:55:37 <abishek> all am doing is calling the sendfrom(account, address, amount, 5, desc); and it is throwing an error.
83 2014-01-29 12:55:46 <wumpus> I don't know enough about PHP to tell
84 2014-01-29 12:56:32 <CodeShark> I remember the php jsonrpcclient class being a bitch to use for error handling
85 2014-01-29 12:56:52 <abishek> wumpus, but this is more a general question, to my understanding if this is the case in PHP, then it also is the case with the other languages right?
86 2014-01-29 12:56:59 <CodeShark> so if you're going to use php, ditch any such wrappers and just use the curl library
87 2014-01-29 12:58:04 <wumpus> abishek: yes, in the languages I know it's pretty easy to get the message no matter what the HTTP response code, it's just different per language/framework...
88 2014-01-29 12:59:07 <CodeShark> in principle error 500 should be reserved for internal server configuration issues and other such stuff when you don't want to expose the details of the issue to the caller
89 2014-01-29 12:59:23 <wumpus> preaching to the choir CodeShark :)
90 2014-01-29 13:04:04 <gavinandresen> wumpus: why would it be near impossible to change?
91 2014-01-29 13:04:46 <disident> where can i get free test net coins ?
92 2014-01-29 13:04:49 <gavinandresen> wumpus: if you have handle-500-error-code that does not get called, you should STILL have handle-error-set-in-JSON-code that does the right thing
93 2014-01-29 13:05:07 <gavinandresen> wumpus: (thinking about compatibilityâ¦.)
94 2014-01-29 13:05:18 <CodeShark> any well-written client shouldn't break
95 2014-01-29 13:05:31 <CodeShark> however, not all clients necessarily are well-written :)
96 2014-01-29 13:05:42 <wumpus> gavinandresen: because it's impossible to know what people did on the client side, if there ever is a RPC redesign this should be taken into account of course
97 2014-01-29 13:06:41 <gavinandresen> mmm. I'd vote for always returning 200, and letting badly written clients break.
98 2014-01-29 13:06:43 <abishek> wumpus, CodeShark, crap, found the issue. the amount that I was passing was '0.0001' and it should be 0.0001, it should be a decimal and not a string...
99 2014-01-29 13:07:47 <gavinandresen> wumpus: how close do you think we are to tagging 0.9rc1 ? I think it is time....
100 2014-01-29 13:08:02 <wumpus> gavinandresen: I'd still like to merge some pull requests
101 2014-01-29 13:08:22 <gavinandresen> wumpus: email me a list and I'll help review/test between meetings
102 2014-01-29 13:08:28 <wumpus> mainly ui stuff
103 2014-01-29 13:08:30 <wumpus> ok
104 2014-01-29 13:09:27 <wumpus> also #3581 still needs to be solved but we couldn't agree on a solution
105 2014-01-29 13:10:18 <gavinandresen> wumpus: FYI: there is a problem getting the code signing certificate renewed (DNS for bitcoinfoundation.org has the wrong address)⦠I'm working on resolving that (but I don't control DNS updates for bitcoinfoundation.org and the person who does is being difficult)
106 2014-01-29 13:11:37 <wumpus> gavinandresen: so we have to wait for that before being able to do a release anyway
107 2014-01-29 13:12:17 <gavinandresen> wumpus: I think if necessary we could have people test an unsigned release candidate
108 2014-01-29 13:12:56 <gavinandresen> wumpus: un-code-signed, that is, it'd still be gitian built and gpg signed of course
109 2014-01-29 13:12:58 <wumpus> that's true
110 2014-01-29 13:18:24 <wumpus> any opinions on #3581 here? should it return a list of records or a list of strings?
111 2014-01-29 13:21:24 <gavinandresen> wumpus: I don't care, pick one and go with it.
112 2014-01-29 13:22:22 <wumpus> I picked one, then the only person caring about the issue thought it should be the other way around
113 2014-01-29 13:25:52 <wumpus> well, going to fix the tab chain in #3585 first then it can be merged, that's the last of the GUI changes that really needs to get in
114 2014-01-29 13:53:27 <wumpus> hmm, the bitcoin-qt.exe produced by gitian still has no icon or .exe metadata, let's see why...
115 2014-01-29 13:56:24 <wumpus> ah, should be a simple fix
116 2014-01-29 14:32:42 <wumpus> gavinandresen: ok, I think 0.9.0rc1 can be tagged
117 2014-01-29 14:33:47 <gavinandresen> wumpus: awesome
118 2014-01-29 14:34:47 <TD> w00t
119 2014-01-29 14:41:39 <wallet42> rc1, rc1, rc1 !! :)
120 2014-01-29 14:42:40 <jcorgan> congratulations
121 2014-01-29 14:43:20 <TD> that's, like, a years worth of work right?
122 2014-01-29 14:45:34 <wumpus> TD: almost exactly, I see the release of 0.8.0rc1 was 2013-02-09 15:50
123 2014-01-29 14:49:43 <kinlo> very interested to read the release notes
124 2014-01-29 14:50:46 <wumpus> those still need to be written
125 2014-01-29 14:52:29 <Jouke> wil it contain payment protocol?
126 2014-01-29 14:52:50 <wumpus> yes, it will contain everything that is in the master branchr currently
127 2014-01-29 14:53:07 <Jouke> Damnit, you guys are going too fast.
128 2014-01-29 14:54:02 <TD> Jouke: too fast?
129 2014-01-29 14:54:05 <TD> hmmm :) i disagree :)
130 2014-01-29 14:55:50 <wumpus> we've picked up the pace a bit in the last few months
131 2014-01-29 14:55:56 <Jouke> Nah, now I have to pull an employee off a project to let him actually finish the payment protocol implementation. But, that is our problem :P
132 2014-01-29 14:56:00 <TD> yes. more contributors. at least i see this with bitcoinj too
133 2014-01-29 14:56:13 <TD> gavinandresen: beta payment protocol support in android wallet: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
134 2014-01-29 14:56:18 <TD> jgarzik: poke
135 2014-01-29 14:58:13 <Jouke> TD: cool
136 2014-01-29 14:59:56 <gavinandresen> To git@github.com:bitcoin/bitcoin.git
137 2014-01-29 14:59:57 <gavinandresen> * [new tag] v0.9.0rc1 -> v0.9.0rc1
138 2014-01-29 15:00:31 <wumpus> gavinandresen:wait, I think we still need to bump the version numbers
139 2014-01-29 15:00:48 <gavinandresen> - [deleted] v0.9.0rc1
140 2014-01-29 15:00:48 <gavinandresen> To git@github.com:bitcoin/bitcoin.git
141 2014-01-29 15:01:23 <wumpus> let's see what all has to be changed, seems there are more and more places to be updated every version
142 2014-01-29 15:01:40 <gavinandresen> wumpus: I'm about to run away to a meeting.....
143 2014-01-29 15:02:14 <wumpus> okay, let's do it later then, we still need release notes too...
144 2014-01-29 15:02:50 <wumpus> It would be great to have all version info in one place, I wonder how other projects handle this
145 2014-01-29 15:04:06 <jgarzik> TD, pong
146 2014-01-29 15:04:33 <TD_> jgarzik: payment protocol? :D
147 2014-01-29 15:08:13 <TD2> annoying. for some reason the testnet faucets are down
148 2014-01-29 15:10:46 <wumpus> ok, bumped the version numbers
149 2014-01-29 15:10:59 <sipa> gavinandresen, wumpus, jgarzik: can you please have a look at #3370 and #3514?
150 2014-01-29 15:11:30 <sipa> (the second includes the first)
151 2014-01-29 15:12:06 <jgarzik> TD2, email jgarzik@bitpay.com an address, and you will get testnet coins in a couple minutes
152 2014-01-29 15:14:13 <TD2> thanks
153 2014-01-29 15:20:41 <michagogo> cloud|Wow, already time for a release candidate?
154 2014-01-29 15:21:38 <michagogo> cloud|ACTION wonders how many we'll need
155 2014-01-29 15:25:35 <wumpus> ...already?
156 2014-01-29 15:26:37 <sipa> it's been ages since 0.8
157 2014-01-29 15:27:10 <wumpus> yeah, indeed
158 2014-01-29 15:28:34 <wumpus> I'll take a look at those pulls later sipa, currently writing release notes, but you think those should be merged before the rc?
159 2014-01-29 15:28:51 <jcorgan> wumpus: in gnuradio we have the version numbers as build system variables (we use cmake, but autotools of course supports this too), and have a .in file to substitute them into global variables and defined symbols that can be referenced anywhere in the software. One place to change that updates anywhere the version number gets used.
160 2014-01-29 15:30:12 <wumpus> jcorgan: yep, we have those too now, I see the autotools switch cut down on the number of places that have to be changed
161 2014-01-29 15:30:36 <wumpus> some documents and scripts still have to be changed individually, but it's not as bad as it used to be
162 2014-01-29 15:30:51 <wumpus> I hope I got them all though: https://github.com/bitcoin/bitcoin/commit/f9a2f088820574ce3c6d06bd9f4ea711184eadad
163 2014-01-29 15:31:48 <wumpus> (I'm actually not sure why the CLIENT_VERSION_* still need to be replicated in clientversion.h, is there a case where we build without HAVE_CONFIG_H?)
164 2014-01-29 15:43:46 <wumpus> there's certainly a lot of commits, writing the 0.9 release notes is a lot of work :)
165 2014-01-29 15:48:43 <michagogo> cloud|Hmm, why do we wait until near release time for those?
166 2014-01-29 15:49:20 <michagogo> cloud|(Why not keep a running set going as changes are made?)
167 2014-01-29 15:50:05 <wumpus> yes, why...
168 2014-01-29 15:50:35 <wumpus> people submitting pull requests should update the release notes too! :P
169 2014-01-29 15:51:19 <wumpus> most of the commits don't have to be in the release notes, luckily, lots of internal non-user-affecting changes
170 2014-01-29 16:26:04 <Sleepnbum> any ideas when the next version of bitcoind will be released?
171 2014-01-29 16:26:25 <aynstein> define released? Like full release?
172 2014-01-29 16:26:36 <wumpus> Sleepnbum: 0.9.0rc1 will likely be tagged today
173 2014-01-29 16:28:03 <Sleepnbum> thanks!
174 2014-01-29 16:47:30 <super3> wumpus, are we going to use github for releases this time?
175 2014-01-29 16:49:28 <wumpus> super3: I don't think so
176 2014-01-29 16:50:40 <wumpus> github release functionality is a bit funky to use, you can't just upload files AFAIK
177 2014-01-29 16:51:15 <wumpus> so we could put the tarballs on github, but the windows installer? I don't know
178 2014-01-29 16:52:33 <sipa> wumpus: iirc github did add some interface for releasing binaries
179 2014-01-29 16:52:40 <sipa> never tried or checked it
180 2014-01-29 16:52:59 <wumpus> me neither... did anyone here ever use github for releases?
181 2014-01-29 16:53:34 <super3> i used it a few days ago
182 2014-01-29 16:54:01 <sipa> wumpus: https://github.com/blog/1547-release-your-software
183 2014-01-29 16:54:03 <wumpus> so, can you comment? can you upload binaries as seperate files without checking them in the repository?
184 2014-01-29 16:54:43 <super3> wumpus, yes. you just drag and drop binaries into their little uploader
185 2014-01-29 16:54:55 <super3> it even snapshots the code in .zip and tar.gz
186 2014-01-29 16:55:15 <super3> and has a place where you can make a fancy little changelog
187 2014-01-29 16:56:31 <sipa> our source code releases should be deterministically built though, ideally
188 2014-01-29 16:57:24 <super3> https://github.com/bitcoin/bitcoin/issues/3224
189 2014-01-29 16:57:37 <super3> https://github.com/blog/1547-release-your-software
190 2014-01-29 17:23:25 <stonecoldpat> guys - with bitcoin messages
191 2014-01-29 17:23:29 <stonecoldpat> is that sent alongside the transaction?
192 2014-01-29 17:23:44 <sipa> define 'bitcoin message' ?
193 2014-01-29 17:24:01 <stonecoldpat> sorry, i remember hearing that when you send a transaction, a message can accompany it
194 2014-01-29 17:24:06 <sipa> (the answer is most likely no, there are no messages inside transactions)
195 2014-01-29 17:24:06 <stonecoldpat> as in, its attached
196 2014-01-29 17:24:09 <sipa> no
197 2014-01-29 17:24:18 <sipa> either you're talking about:
198 2014-01-29 17:24:55 <sipa> * the signed message feature in some clients (which has nothing to do with transactions, and is not online, it just signs a message with an address locally, proving you're the owner)
199 2014-01-29 17:25:10 <sipa> * the comment field you can add to a transaction in some clients (which is local only)
200 2014-01-29 17:25:27 <sipa> * the comment field you can add to transactions on blockchain.info (which is only on that site)
201 2014-01-29 17:25:53 <sipa> * the OP_RETURN extra output that will be allowed in 0.9 of the reference client, but that is for committing to metadata, not messages
202 2014-01-29 17:26:25 <stonecoldpat> ah, its most likely the blockchain.info one im thinking off then (example I was thinking off, was when messages went sent to the FBI about the confiscated bitcoins)
203 2014-01-29 17:27:09 <stonecoldpat> OP_RETURN, will users who create transaction have control over the meta-data sent?
204 2014-01-29 17:27:51 <Luke-Jr> OP_RETURN is just a more painless way to abuse Bitcoin, it isn't meant to be used
205 2014-01-29 17:28:01 <Luke-Jr> and might be reverted since people keep taking it as an endorsement
206 2014-01-29 17:28:12 <Luke-Jr> s/painless/less painful/
207 2014-01-29 17:28:58 <stonecoldpat> ok, so it isn't something to be relied upon then?
208 2014-01-29 17:29:16 <sipa> if you want to send a message along with a transaction, use the payment protocol
209 2014-01-29 17:29:24 <sipa> (which will hopefully become available soon)
210 2014-01-29 17:29:44 <sipa> there's no point in spamming the entire world and the history of every full node ever in history with your personal message
211 2014-01-29 17:29:44 <stonecoldpat> i'll look into that, thanks sipa
212 2014-01-29 17:30:13 <wumpus> 0.9.0rc1 release notes (preliminary): http://hastebin.com/lojofeqahi.vhdl
213 2014-01-29 17:30:50 <Luke-Jr> wumpus: OP_RETURN is listed in there twice, and should probably be revisited
214 2014-01-29 17:31:07 <wumpus> LOL, indeed
215 2014-01-29 17:31:23 <Luke-Jr> wumpus: should I go ahead and change the spaces to dashes for the message thing?
216 2014-01-29 17:32:07 <wumpus> Luke-Jr: that would be consistent
217 2014-01-29 17:32:18 <Luke-Jr> wumpus: goal of splitting that apart from proposals is to hopefully get it in for 0.9 so we don't have to change the messages between versions BTW
218 2014-01-29 17:32:48 <jcorgan> lol that chrome or hastebin is applying VHDL syntax highlighting due to the URL
219 2014-01-29 17:33:10 <wumpus> Luke-Jr: yes, makes sense, you only change the messages so I don't think your pull is controversial
220 2014-01-29 17:34:02 <wumpus> jcorgan: hehe, I accidentally selected vhdl probably
221 2014-01-29 17:35:45 <wumpus> Luke-Jr: sipa also has pulls that he would like to have in 0.9 (#3370 and #3514) so I'm not entirely sure about the release today, but it can't hurt to have the release notes ready
222 2014-01-29 17:39:32 <jcorgan> wumpus: does running 0.9x on a 0.8x database upgrade it in a way that prevents it from being used again with 0.8?
223 2014-01-29 17:39:44 <wumpus> jcorgan: no, that should be fixed
224 2014-01-29 17:39:52 <jcorgan> ah ok
225 2014-01-29 17:40:07 <Luke-Jr> wumpus: repushed
226 2014-01-29 17:40:10 <wumpus> there was a bug with leveldb renaming files, but that is no longer the case
227 2014-01-29 17:40:43 <jcorgan> got it, hard to keep track of it all
228 2014-01-29 17:43:31 <jcorgan> minor typo line 168, extra word
229 2014-01-29 17:46:50 <jcorgan> if configure --disable-wallet isn't used, i assume the cli -disable wallet isn't needed, might clairfy
230 2014-01-29 17:47:11 <jcorgan> is used, argh
231 2014-01-29 17:49:50 <Luke-Jr> hmm
232 2014-01-29 17:50:02 <Luke-Jr> can the wallet be disabled at runtime?
233 2014-01-29 17:58:08 <wumpus> jcorgan: you can use both, but there's indeed no point
234 2014-01-29 17:58:17 <wumpus> Luke-Jr: yes, with the -disable-wallet option
235 2014-01-29 18:36:22 <super3> gah that changelog is huge
236 2014-01-29 18:37:51 <super3> makes me really excited for v1.0
237 2014-01-29 18:38:06 <sipa> you mean 0.10? :)
238 2014-01-29 18:38:25 <sipa> ... for some reason 0.10 sounds so much less complete than 0.9
239 2014-01-29 18:39:17 <super3> will we have fancy headers first by 1.0?
240 2014-01-29 18:39:18 <jcorgan> should have called it 0.09
241 2014-01-29 18:53:48 <Luke-Jr> jcorgan: 0.9 and 0.09 are the same thing
242 2014-01-29 18:54:00 <Luke-Jr> except the latter has a leading zero
243 2014-01-29 18:54:37 <jcorgan> my comment was snarky response to sipa. 0.09 -> 0.10 seems better than 0.9 -> 0.10
244 2014-01-29 18:57:06 <petertodd> wumpus: "Document and test OP_RESERVED weirdness" <- doesn't need to be in the release notes
245 2014-01-29 18:58:20 <wumpus> right
246 2014-01-29 18:58:21 <petertodd> wumpus: "Fix off-by-one errors in use of IsFinalTx()" I'd change that to "Accept of nLockTime transactions that finalize in the next block"
247 2014-01-29 18:58:44 <petertodd> wumpus: s/of//
248 2014-01-29 18:58:45 <wumpus> Accept of?
249 2014-01-29 18:58:51 <wumpus> ah
250 2014-01-29 19:04:13 <petertodd> wumpus: "Performance optimization for bloom filters" that was a DoS attack fix, and do you want to duplicate already released fixes?
251 2014-01-29 19:05:26 <CodeShark> 0.09 -> 0.10 will get sorted properly in most contexts :)
252 2014-01-29 19:05:43 <CodeShark> 0.9 -> 0.10 will not
253 2014-01-29 19:05:57 <sipa> if you use proper version ordering, it will :)
254 2014-01-29 19:06:05 <petertodd> CodeShark: there's actually standard version number comparison routines out there in various languages you know - Python has one
255 2014-01-29 19:06:37 <CodeShark> it's trivial to sort correctly if you're the one who is coding :p
256 2014-01-29 19:06:43 <CodeShark> problem is when using tools other people wrote
257 2014-01-29 19:07:29 <petertodd> CodeShark: meh, why don't you go complain about the order of the credits in the release notes? that'd be productive
258 2014-01-29 19:07:32 <petertodd> ACTION ducks
259 2014-01-29 19:07:35 <CodeShark> lol
260 2014-01-29 19:08:03 <CodeShark> I wasn't trying to be productive
261 2014-01-29 19:08:38 <super3> well we did rebrand to bitcoin core, could probably get away with starting the versioning for that anywhere we want
262 2014-01-29 19:09:04 <sipa> let's call it Bitcoin Core NT 3.51
263 2014-01-29 19:09:07 <CodeShark> lol
264 2014-01-29 19:09:50 <super3> as long at its not Bitcoin ME, i'm happy
265 2014-01-29 19:11:09 <wumpus> petertodd: right, if it already is in 0.8.6 it shouldn't be in the list
266 2014-01-29 19:12:43 <wumpus> the order of the credits is simply how git shortlog produced it, it's strange that it's case senstively sorted but meh
267 2014-01-29 19:12:45 <petertodd> wumpus: also, stick the release notes in the git repo IMO... we don't seem to have done that - good for historic value
268 2014-01-29 19:13:19 <sipa> there's even a file for that!
269 2014-01-29 19:13:42 <wumpus> sipa: but that one is removed after every release so not really useful for historic value
270 2014-01-29 19:14:14 <sipa> it's still in git history
271 2014-01-29 19:14:20 <wumpus> making a directory with all the historical release notes would make sense
272 2014-01-29 19:14:24 <sipa> and i wouldn't mind having all changelogs, actually
273 2014-01-29 19:14:25 <petertodd> wumpus: mainly it should be easy to look them up when you're trying to figure out what people thought had changed
274 2014-01-29 19:14:25 <sipa> yeah
275 2014-01-29 19:14:45 <sipa> including the historic stuff would be nice
276 2014-01-29 19:14:53 <sipa> you might need to pull that off bitcointalk :)
277 2014-01-29 19:15:03 <wumpus> either bitcointalk or sourceforge
278 2014-01-29 19:15:10 <sipa> or mail
279 2014-01-29 19:15:13 <petertodd> sipa: exactly the problem!
280 2014-01-29 19:15:20 <sipa> petertodd: agree
281 2014-01-29 19:15:36 <gmaxwell> yea, changelogs have been hugely helpful for me in the past figuring out what version some change was merged in when the specific commit isn't instantly obvious, and even with the commit figuring out where something was released takes a little effort (esp due to backporting)
282 2014-01-29 19:15:53 <sipa> digging through git log to find when something changed is painful
283 2014-01-29 19:16:03 <BlueMatt> wumpus: its on the wiki
284 2014-01-29 19:16:09 <BlueMatt> it just hasnt been updated since like 0.7
285 2014-01-29 19:16:14 <BlueMatt> but it has all the changes before then
286 2014-01-29 19:16:17 <sipa> oh wow, so recent
287 2014-01-29 19:16:24 <BlueMatt> ok, maybe not so recent
288 2014-01-29 19:16:27 <BlueMatt> like 0.5 or 6
289 2014-01-29 19:16:27 <sipa> (seriously, i would expect it to be until 0.3.20 or so)
290 2014-01-29 19:16:36 <wumpus> ok so at least the information is in multiple places then :)
291 2014-01-29 19:16:38 <BlueMatt> no, I spent an hour or two like a year ago updating it
292 2014-01-29 19:16:49 <sipa> kwel
293 2014-01-29 19:16:51 <sipa> *kewl
294 2014-01-29 19:16:55 <BlueMatt> 0.6
295 2014-01-29 19:17:01 <BlueMatt> en.bitcoin.it/wiki/Changelog
296 2014-01-29 19:17:26 <sipa> march 2012
297 2014-01-29 19:17:29 <BlueMatt> wumpus: where else is the info?
298 2014-01-29 19:17:35 <BlueMatt> sipa: ok, fine, 1.5 years ago
299 2014-01-29 19:18:38 <Ademan> is it possible to accurately measure the orphan rate of the block chain? I guess if you connected to a lot of clients you could probably reasonably expect to receive nearly all blocks, and be witness to nearly all orphans?
300 2014-01-29 19:19:16 <petertodd> Ademan: define accurate
301 2014-01-29 19:19:42 <Ademan> petertodd: "satisfies my subjective desire for accuracy" :-p
302 2014-01-29 19:20:10 <Ademan> uh, I dunno... but the idea that it would miss as few events were blocks were orphaned as possible
303 2014-01-29 19:20:38 <sipa> Ademan: technically, the block chain has no forks
304 2014-01-29 19:20:51 <sipa> as the block chain is defined as the longest chain through the block tree :)
305 2014-01-29 19:21:16 <sipa> (that's nitpicking, of course)
306 2014-01-29 19:21:24 <Ademan> lol
307 2014-01-29 19:21:28 <sipa> the problem is that your node will never see all blocks
308 2014-01-29 19:21:54 <petertodd> Ademan: I'll bet you blockchain.info has 90% of all orphans
309 2014-01-29 19:25:03 <Ademan> I was interested in measuring the orphan rate of different cryptos with different block times, but I suspect since the propagation of blocks is more or less a fixed rate, but the block time is reducing (I assume nodes won't forward blocks in a shorter chain?) that the accuracy of measurement will decrease
310 2014-01-29 19:25:36 <Ademan> s/but the block time is reducing/but for cryptos with shorter block times/
311 2014-01-29 19:25:58 <sipa> block size hugely impacts propagation speed
312 2014-01-29 19:26:05 <sipa> which makes it really hard to compare things
313 2014-01-29 19:26:07 <petertodd> Ademan: easiest thing to do is convince said crypto's to propagate block headers separately :)
314 2014-01-29 19:27:09 <BlueMatt> sipa/gmaxwell: someone should definitely update the wiki changelog page :)
315 2014-01-29 19:27:22 <Ademan> sipa: ah that makes sense
316 2014-01-29 19:27:34 <petertodd> BlueMatt: ...with a link to http://github.com/bitcoin/bitcoin/doc/release-notes/
317 2014-01-29 19:28:28 <BlueMatt> petertodd: what, this one? https://github.com/bitcoin/bitcoin/blob/master/doc/release-nots.md
318 2014-01-29 19:28:37 <BlueMatt> the empty one that hasnt been updated in 8 months?
319 2014-01-29 19:28:44 <Ademan> petertodd: how open would you be to backwards incompatible changes to python-bitcoinlib's bitcoin.rpc.Proxy ? :-D
320 2014-01-29 19:29:00 <sipa> BlueMatt: well, i wouldn't object to putting all changelogs in that directory
321 2014-01-29 19:29:06 <sipa> including old ones
322 2014-01-29 19:29:10 <BlueMatt> well, ok, sure
323 2014-01-29 19:29:10 <petertodd> BlueMatt: hehe, well above I was saying we should have a archival directory in git
324 2014-01-29 19:29:20 <BlueMatt> someone should do that, then, too :)
325 2014-01-29 19:29:30 <petertodd> Ademan: what do you want to do?
326 2014-01-29 19:29:40 <BlueMatt> what happened to the people I met in miami who were saying they could write docs if it would be useful for devs?
327 2014-01-29 19:31:04 <Ademan> petertodd: well it's already done. But it annoyed me that RawProxy.__init__() read the config file by default, making it impossible/really annoying to construct a raw proxy from explicitly specified username/password/port/hostname information, so I took the meat from the existing init and moved it into a class method from_config() and made init "lower level"
328 2014-01-29 19:31:05 <petertodd> BlueMatt: oh sorry, I pointed them to some post-modern poetry classes - they seemed really psyched
329 2014-01-29 19:31:20 <sipa> petertodd: Vogon poetry?
330 2014-01-29 19:31:25 <Ademan> Wasn't sure if I should even bother submitting a pull request since it'd break code
331 2014-01-29 19:31:41 <petertodd> Ademan: ? that's only by default though, there are the keyword arguments for that
332 2014-01-29 19:31:57 <petertodd> Ademan: I mean, I was just using that library with dogecoin last night
333 2014-01-29 19:32:01 <petertodd> sipa: worse
334 2014-01-29 19:32:12 <BlueMatt> petertodd: ahhhhh, damn you
335 2014-01-29 19:32:12 <sipa> petertodd: then there's just 2 options left
336 2014-01-29 19:34:30 <Ademan> petertodd: well, if you shove everything into the service_url, sure, but otherwise not exactly...
337 2014-01-29 19:34:43 <Ademan> which is kind of silly since the init eventually tears the service_url apart anyways
338 2014-01-29 19:35:35 <petertodd> Ademan: well, meh :)
339 2014-01-29 19:36:15 <Ademan> petertodd: but I had forgotten about that, it is possible. my changes soothe my OCD but it's probably not worth breaking code for
340 2014-01-29 19:36:45 <petertodd> Ademan: yeah, although frankly I'd be surprising if there's all that much code out there to break!
341 2014-01-29 19:37:42 <petertodd> Ademan: are you using jgarzik's master branch, or my pythonize one?
342 2014-01-29 19:38:06 <Ademan> petertodd: pythonize
343 2014-01-29 19:38:18 <petertodd> Ademan: ah cool, how do you like it?
344 2014-01-29 19:38:33 <Ademan> I like it but I don't know how it diverges from jgarzik's lol
345 2014-01-29 19:39:00 <petertodd> Ademan: it doesn't so much diverge as it breaks things :P
346 2014-01-29 19:39:36 <petertodd> Ademan: basically CNode and other networking stuff is broken right now
347 2014-01-29 19:39:54 <Ademan> oh, bad times, I hadn't gotten far enough to notice that yet
348 2014-01-29 19:40:15 <petertodd> Ademan: yeah, OTOH for use with RPC it works pretty well
349 2014-01-29 19:40:29 <petertodd> Ademan: oh, and I think SigntureHash() is broken right now
350 2014-01-29 19:40:35 <Ademan> speaking of irritating my OCD though... CWhyDoThisInPythonCamelCaseImpliesType!!!
351 2014-01-29 19:41:39 <petertodd> Ademan: quite delibrately to match the C++ source-code
352 2014-01-29 19:41:56 <Ademan> ah...
353 2014-01-29 19:42:19 <petertodd> Ademan: CTransaction in py is a pretty much exact copy of CTransaction in bitcoin in terms of what it does
354 2014-01-29 19:42:22 <petertodd> Ademan: (etc.)
355 2014-01-29 19:43:04 <Ademan> interesting, I didn't know that, I still haven't read (much) of the bitcoin source
356 2014-01-29 19:44:58 <petertodd> Ademan: you really should, it's actually quite simple code, on the surface...
357 2014-01-29 19:46:33 <Ademan> probably, I can't say I'm using bitcoin *completely* trustlessly unless I do :-p
358 2014-01-29 19:47:03 <Ademan> what's the goal of the pythonize branch though?
359 2014-01-29 19:47:39 <Ademan> It's what I based my work on since for whatever reason killerstorm picked it
360 2014-01-29 19:47:56 <petertodd> Ademan: oh, killerstorm is using it too?
361 2014-01-29 19:48:27 <Ademan> yeah for colored coins actually, unless that changed, I haven't done any work on it since a couple weeks before finals
362 2014-01-29 19:48:38 <petertodd> Ademan: basically just to take jgarzik's code and make it follow python coding standards reasonably closely for ease of use, but without sacrificing speed or the ability to late use Cython or a compiled module
363 2014-01-29 19:49:03 <petertodd> Ademan: (I've wrote a bunch of Cython and compiled python modules a few years back)
364 2014-01-29 19:49:47 <Ademan> ah cool. Right now there's no way to build the main bitcoin tree as a shared library is thre?
365 2014-01-29 19:49:50 <Ademan> there* even
366 2014-01-29 19:50:16 <petertodd> Ademan: not yet, but I may get a chance to do that as part of my new job
367 2014-01-29 19:50:34 <sipa> petertodd: new job... the one you have, or a newer one?
368 2014-01-29 19:50:35 <Ademan> oh nice!
369 2014-01-29 19:50:44 <petertodd> sipa: ha, mastercoin
370 2014-01-29 19:50:46 <sipa> ok
371 2014-01-29 19:50:58 <Ademan> uh oh :-p
372 2014-01-29 19:51:30 <Ademan> so now you want to merge my changes into python-bitcoinlib so it breaks colored coins?
373 2014-01-29 19:51:50 <petertodd> Ademan: keep in mind I said a few months ago that it was an idea sufficiently stupid as to be indistinguishable from a scam... and JR basically said "Point taked. How about you go fix it then if you're so smart?"
374 2014-01-29 19:51:55 <petertodd> s/taked/taken/
375 2014-01-29 19:52:28 <petertodd> Ademan: ha, even less likely! I'll have to find their code and start looking at it
376 2014-01-29 19:53:07 <Ademan> btw, the NYC hearings are going on right now
377 2014-01-29 19:53:15 <jgarzik> Ademan, huh?
378 2014-01-29 19:53:30 <Ademan> http://www.totalwebcasting.com/view/?id=nysdfs
379 2014-01-29 19:53:43 <jgarzik> petertodd, can you run a comparison and see if merging your branch would regress anything?
380 2014-01-29 19:54:02 <petertodd> jgarzik: well... according to the unit tests it wouldn't :P
381 2014-01-29 19:54:07 <Ademan> oh wow this guy is trying to say bitcoin isn't a currency because its price is volatile
382 2014-01-29 19:54:08 <jgarzik> Ademan, wasn't aware there was a second day?
383 2014-01-29 19:54:14 <petertodd> jgarzik: it'd break pynode for sure though
384 2014-01-29 19:54:20 <Ademan> jgarzik: neither was I, someone in #bitcoin-pricetalk pointed it out
385 2014-01-29 19:55:18 <jgarzik> petertodd, I'll fix it up, just to get moving
386 2014-01-29 19:55:52 <petertodd> jgarzik: thanks, I've got a lot of paid work right now
387 2014-01-29 19:56:15 <petertodd> jgarzik: I wrote a ECDH addon for CKey last night btw
388 2014-01-29 19:57:20 <sipa> wumpus, jgarzik, gmaxwell, gavinandresen: if i could get bip32 support ready this weekend... worth delaying rc1 for?
389 2014-01-29 19:57:35 <petertodd> sipa: bip32 for the wallet?
390 2014-01-29 19:57:40 <sipa> yes
391 2014-01-29 19:58:07 <petertodd> sipa: I'd suggest a 0.10 for that purely on the basis that it is wallet related
392 2014-01-29 19:58:31 <petertodd> sipa: and totally ok to make 0.10 a bit32-only release so people can start testing just that earlier than not
393 2014-01-29 19:58:47 <petertodd> *bip32
394 2014-01-29 20:00:11 <sipa> perhaps best
395 2014-01-29 20:00:21 <sipa> decent integration will require gui changes, rpc changes, ...
396 2014-01-29 20:00:29 <sipa> dump format integration
397 2014-01-29 20:00:32 <gavinandresen> sipa: I'd like us to get in the habit of smaller, more frequent releases again
398 2014-01-29 20:00:43 <sipa> gavinandresen: ack on that, actually
399 2014-01-29 20:00:53 <sipa> 0.9 has been going on for way too long already
400 2014-01-29 20:00:56 <petertodd> sipa: yup, so release "all those cool 0.9 changes" and then 0.10 can be "and if you're really adventurous..."
401 2014-01-29 20:00:56 <sipa> ok
402 2014-01-29 20:02:21 <petertodd> heh, where kernel releases did odd/even you almost want to do stable/unstable/holy-fuck-the-wallets-changing around here :P
403 2014-01-29 20:02:22 <jgarzik> sipa, 0.10 imo
404 2014-01-29 20:03:01 <jgarzik> sipa, though I'm yur motivated you can always stick a default-disabled tech preview toy for people to play with in there
405 2014-01-29 20:03:34 <jgarzik> I'm a big fan of default-disabled tech previews. Get the code building, and easy to enable for early adopters
406 2014-01-29 20:03:41 <jgarzik> get it in tree and building, I mean
407 2014-01-29 20:03:52 <sipa> btw, libsecp256k1 has been autotoolsified
408 2014-01-29 20:04:22 <sipa> i have code changes for key.pp to integrate it, but someone'll have to integrate it in the build system
409 2014-01-29 20:04:34 <EasyAt> Didn't we already have a .1? What was before .2?
410 2014-01-29 20:04:46 <petertodd> EasyAt: 0.1 != 0.10
411 2014-01-29 20:05:01 <EasyAt> mercy
412 2014-01-29 20:05:03 <sipa> or even: 0.1.0 != 0.10
413 2014-01-29 20:05:10 <petertodd> EasyAt: there are projects out there upup to 0.38
414 2014-01-29 20:05:15 <petertodd> s/upup/upto/
415 2014-01-29 20:06:12 <petertodd> EasyAt: http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html
416 2014-01-29 20:06:30 <wumpus> sipa: I'd prefer to not do such large wallet changes last-minute
417 2014-01-29 20:06:49 <sipa> fair enough
418 2014-01-29 20:06:51 <wumpus> doing more frequent major releases sounds good to me though
419 2014-01-29 20:07:04 <sipa> the problem is a feeling of promises i guess
420 2014-01-29 20:07:09 <wumpus> 0.9 was going on for too long
421 2014-01-29 20:07:18 <Ademan> It doesn't appear that any of the coinjoin bounty was paid out to whoever created the existing centralized coinjoin implementation, what's up with that?
422 2014-01-29 20:07:30 <petertodd> Ademan: you mean blockchain.info?
423 2014-01-29 20:07:38 <petertodd> Ademan: or you mean the guy from months ago?
424 2014-01-29 20:08:00 <sipa> if you've been postponing a new release for a long time, it feels like you ought to bring many improvements
425 2014-01-29 20:08:04 <petertodd> Ademan: a few people suggested it be paid out based on real-world impact fwiw
426 2014-01-29 20:08:20 <sipa> while not releasing makes it actually harder to get new features tested
427 2014-01-29 20:08:29 <Ademan> petertodd: the guy from a few months ago
428 2014-01-29 20:08:40 <andytoshi> Ademan: do you mean me?
429 2014-01-29 20:08:42 <jgarzik> sipa, push it to HEAD immediately after tagging 0.9-final
430 2014-01-29 20:08:42 <wumpus> there is already so much stuff in 0.9
431 2014-01-29 20:08:52 <jgarzik> release early, release often
432 2014-01-29 20:08:53 <Ademan> andytoshi: I do, I was going to pop into #bitcoin and hunt for your nick :-p
433 2014-01-29 20:08:58 <sipa> jgarzik: secp, you mean?
434 2014-01-29 20:08:59 <jgarzik> let's get 0.10 out the door :)
435 2014-01-29 20:09:06 <jgarzik> sipa, secp + HD
436 2014-01-29 20:09:09 <petertodd> Ademan: yeah, OTOH his code isn't getting actually used
437 2014-01-29 20:09:20 <andytoshi> Ademan: i have a bot announcing cjs and i show up pretty often to answer questions and encourage people to join
438 2014-01-29 20:09:22 <andytoshi> and still nobody
439 2014-01-29 20:09:28 <Ademan> hey, they're talking about "colorful coins" in the hearing
440 2014-01-29 20:09:43 <jgarzik> gavinandresen, +1
441 2014-01-29 20:09:53 <andytoshi> i think uptake is a solvable problem, and the bounty should be contingent on that
442 2014-01-29 20:10:10 <Ademan> andytoshi: ah
443 2014-01-29 20:10:17 <petertodd> andytoshi: you need a "lobby" mode where you can leave a long-running coinjoin going for people who don't need to have a tx done in any particular timeframe
444 2014-01-29 20:10:44 <Ademan> definitely, I'm structuring my work around a "coinjoind" that just runs with some parameters...
445 2014-01-29 20:10:54 <Ademan> sits there, and waits
446 2014-01-29 20:11:00 <andytoshi> Ademan: you have a 'coinjoind' which you are developing?
447 2014-01-29 20:11:02 <petertodd> andytoshi: bc.i's coinjoin implementation is succesful because it's really fast
448 2014-01-29 20:11:25 <petertodd> andytoshi: piuk said about 50% of the joins have more than one non-bc.i participant
449 2014-01-29 20:12:06 <Ademan> andytoshi: I'm running with the p2p implementation you pointed me to, you can see my fork on github but there's nothing to see yet, I basically just moved stuff around so that I can grok the existing code haha
450 2014-01-29 20:12:26 <Ademan> well, I'm moving forward as of like 8pm on BART last night...
451 2014-01-29 20:12:33 <Ademan> but just barely
452 2014-01-29 20:13:10 <andytoshi> petertodd: i thought you needed to be logged into bc.i to use their joiner?
453 2014-01-29 20:13:14 <andytoshi> i can't even find a link
454 2014-01-29 20:13:22 <petertodd> andytoshi: you do
455 2014-01-29 20:13:42 <andytoshi> ok, so how can you join with non-bc.i participants?
456 2014-01-29 20:13:57 <petertodd> andytoshi: bc.i has a hot wallet that they mix funds into - I mean non-hotwallet participant/actual bc.i user
457 2014-01-29 20:14:40 <petertodd> andytoshi: point is the UI is that your tx goes through relatively fast with reasonable privacy regardless of whether or not anyone else is doing a join at the exact same time
458 2014-01-29 20:15:01 <andytoshi> they can only do that because they have many users
459 2014-01-29 20:15:08 <andytoshi> and all these people trust them with their privkeys
460 2014-01-29 20:15:18 <andytoshi> if people would send me private keys i could do fast joins too :)
461 2014-01-29 20:15:22 <petertodd> andytoshi: not just that - they still need to get those users to actualy use the feature too
462 2014-01-29 20:15:38 <petertodd> andytoshi: remember that the actual process is still client-side - they're not signing on your behalf
463 2014-01-29 20:16:25 <petertodd> andytoshi: see, if you had a feature where I could leave a client running with a few hundred worth of BTC and would join with anyone else who showed up your thing would be a lot more popular
464 2014-01-29 20:16:44 <andytoshi> petertodd: ok, thx. i will implement that
465 2014-01-29 20:17:01 <gmaxwell> andytoshi: yea, make it so that it can move all the coins from bin A into bin B.
466 2014-01-29 20:17:16 <andytoshi> should the client be an actual wallet then?
467 2014-01-29 20:17:22 <andytoshi> i guess it should be
468 2014-01-29 20:17:22 <petertodd> andytoshi: no problem. Also critically, make it so that you can say "I don't care exactly how much each tx moves; match what the other participants want."
469 2014-01-29 20:17:44 <petertodd> andytoshi: kinda yeah, using the bitcoin-core RPC interface/wallet is fine
470 2014-01-29 20:17:56 <andytoshi> i don't think RPC is fine, i think that's a barrier to adoption
471 2014-01-29 20:18:14 <petertodd> andytoshi: *no* because the long-running version of it can use RPC, the other one can be whatever
472 2014-01-29 20:18:20 <Ademan> andytoshi: barrier to what adoption?
473 2014-01-29 20:18:28 <petertodd> andytoshi: you've got two separate user-groups there, at least initially
474 2014-01-29 20:18:39 <gmaxwell> the fact that it's apparently hard for j-random-bitcoin-qt user to turn on RPC is annoying. We should probably be automatically setting up a config.
475 2014-01-29 20:18:40 <Luke-Jr> ACTION seconds Ademan
476 2014-01-29 20:19:15 <Ademan> *while* I'm here, why can't bitcoind listen on a unix domain socket instead of a plain socket? Using filesystem permissions to secure communication would be a nice option.
477 2014-01-29 20:19:18 <Luke-Jr> gmaxwell: Settings buttons "Generate API key" and "Save API key"?
478 2014-01-29 20:19:20 <gmaxwell> andytoshi: but what petertodd is saying is that there are people like himself who would setup a wallet with a bunch of coins in it to oppturnistically join with ~all comers. That kind of user is fine on the RPC.
479 2014-01-29 20:19:42 <petertodd> Ademan: because no-one has submitted a pull-req :)
480 2014-01-29 20:19:50 <gmaxwell> Ademan: we already use the filesystems permissions to secure it by virtue of the rpc'password'.
481 2014-01-29 20:19:56 <andytoshi> yeah, i hear petertodd. that's definitely something i will work on
482 2014-01-29 20:20:08 <andytoshi> this week i have been working on replacing the server with something much less retarded