1 2014-01-13 00:03:43 <gmaxwell> yes, it's including the subsidy, you can tell because if you go to the 'all time' graph the numbers halved at the subsidy change.
2 2014-01-13 00:05:38 <TD> gmaxwell: more simply, it tells you what the charts mean on the charts index page
3 2014-01-13 00:05:41 <TD> ACTION -> sleep
4 2014-01-13 00:06:27 <gmaxwell> "A chart showing miners revenue as as percentage of the transaction volume" isn't really clear.
5 2014-01-13 00:46:12 <Luke-Jr> andytoshi: static linking is always bad :P
6 2014-01-13 00:46:36 <Luke-Jr> andytoshi: I compile BFGMiner for Windows essentially the same as I do for Linux
7 2014-01-13 00:53:22 <andytoshi> Luke-Jr: agreed, i just can't track down this dll
8 2014-01-13 00:54:33 <andytoshi> can you give me a ./configure line to compile bfgminer for windows? i'd like to see how it behaves
9 2014-01-13 00:57:06 <andytoshi> never mind, --target=mingw32 does it
10 2014-01-13 00:57:44 <Luke-Jr> I use ./configure --prefix='C:\\Program Files\\BFGMiner\\' CFLAGS='-Wall -O1 -ggdb -march=i686' --enable-cpumining --enable-opencl --enable-adl --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --build=i686-pc-linux-gnu --host=i686-pc-mingw32 --enable-scrypt --enable-ztex
11 2014-01-13 00:58:06 <Luke-Jr> well, when testing lately..
12 2014-01-13 03:39:39 <gmaxwell> Jim Burton's pgp key isn't signed by any key I reconize. If one of you gets the chance to fix that, you probably should.
13 2014-01-13 03:48:11 <phantomcircuit> gmaxwell, sign the key as untrusted
14 2014-01-13 03:48:25 <phantomcircuit> be quizicle when that gives it higher standing than unsigned in gnupg
15 2014-01-13 03:50:57 <gmaxwell> I don't want to sign it, but I'd like to know that its legit. Though with the number of people randomly signing everything they run across... you can't tell anymore short of actually asking the signer.
16 2014-01-13 04:04:33 <Mr_Psmith> gmaxwell: Thanks for posting in here
17 2014-01-13 04:04:58 <gmaxwell> Mr_Psmith: hah, were you tuning in to ask the same thing?
18 2014-01-13 04:05:25 <Mr_Psmith> gmaxwell: Aye. I was able to verify I had the same key fingerprint for that guy, but other than that, he said "Is it safe?" and all I could say was "Probably."
19 2014-01-13 04:05:56 <gmaxwell> Mr_Psmith: yea, "well based on the fact that attacks are rare, the answer was still 'probably' before you checked" :P
20 2014-01-13 04:06:23 <fanquake> ;;tslb
21 2014-01-13 04:06:26 <gribble> Time since last block: 7 hours, 55 minutes, and 26 seconds ago
22 2014-01-13 04:06:34 <gmaxwell> lol
23 2014-01-13 04:06:48 <fanquake> Been like that for a while now heh
24 2014-01-13 05:47:37 <tpm476> hi
25 2014-01-13 05:47:50 <tpm476> i am looking for help
26 2014-01-13 05:48:01 <tpm476> in developing a custom mining software
27 2014-01-13 05:48:21 <tpm476> and i am trying to support the getblocktemplate json
28 2014-01-13 05:48:25 <tpm476> but i am confused
29 2014-01-13 05:48:33 <tpm476> anyone could help me ?
30 2014-01-13 05:48:48 <Luke-Jr> tpm476: read (or use) libblkmaker?
31 2014-01-13 05:48:56 <Luke-Jr> or ask specific questions at least
32 2014-01-13 05:49:03 <tpm476> okay
33 2014-01-13 05:49:08 <tpm476> firstly
34 2014-01-13 05:49:46 <tpm476> bitcond -testnet , doesnt return an expected response when the getblocktemplate is invoker
35 2014-01-13 05:50:22 <tpm476> i.e. no coinbasetxn data and transaction list return
36 2014-01-13 05:51:34 <tpm476> let me start up my test server and give you the real data
37 2014-01-13 05:53:14 <tpm476> oh sorry , i am using the testnet-box
38 2014-01-13 05:53:23 <tpm476> not the testnet
39 2014-01-13 05:53:39 <Luke-Jr> tpm476: try sending a transaction
40 2014-01-13 05:53:45 <Luke-Jr> tpm476: coinbasetxn is indeed not included, as bitcoind couldn't care less what you put
41 2014-01-13 05:54:10 <tpm476> okay ,
42 2014-01-13 05:54:44 <tpm476> does it mean i must invoker a transaction in order to coinbasetxn from the getblocktemplate then ?
43 2014-01-13 05:55:47 <Luke-Jr> bitcoind won't give you coinbasetxn no matter what, you will need to provide it yourself
44 2014-01-13 05:56:15 <Luke-Jr> eg https://gitorious.org/bitcoin/libblkmaker/source/8d1946930153a418d9d7394f362a7cc0de77040b:blkmaker.c#L44
45 2014-01-13 05:56:48 <tpm476> hmm
46 2014-01-13 05:57:07 <tpm476> okay , i will try to digest it first
47 2014-01-13 06:02:40 <tpm476> so the coinbasetxn is actually provided by the pool , i am right to say that ?
48 2014-01-13 06:04:37 <Luke-Jr> tpm476: yes, pools provide it
49 2014-01-13 06:46:09 <tpm476> is there any simpler doc that explains how the coinbasetxn is generated ?
50 2014-01-13 06:46:49 <tpm476> or there an alternative to getting the coinbasetxn for mining purposes ?
51 2014-01-13 06:47:14 <Luke-Jr> https://en.bitcoin.it/wiki/Protocol_specification#tx perhaps
52 2014-01-13 06:47:45 <Luke-Jr> tpm476: what are your goals with a new miner btw?
53 2014-01-13 06:49:01 <tpm476> trying to implement hashing algorithm based on pre - generated dictonary
54 2014-01-13 06:49:32 <tpm476> sounds like it will fail already , but i am just want to test out my theories
55 2014-01-13 06:49:58 <Luke-Jr> might be easier to just use libblkmaker directly then?
56 2014-01-13 06:50:13 <Luke-Jr> it can give you the 80 byte block headers you'd hash
57 2014-01-13 06:50:24 <tpm476> i dont really understand c ++ / c , that's the problem
58 2014-01-13 06:50:38 <Luke-Jr> python-blkmaker then? :P
59 2014-01-13 06:50:51 <tpm476> i am using java , and the diablo miner is still using getwork
60 2014-01-13 06:51:23 <Luke-Jr> I see. Don't know any Java implementations yet.
61 2014-01-13 06:51:37 <tpm476> in fact i was using getwork , but until some one told me about the getblocktemplate
62 2014-01-13 06:52:03 <Luke-Jr> getwork is probably fine for testing ideas out
63 2014-01-13 06:52:18 <Luke-Jr> although note you'll want to un-flip the numbers most likely
64 2014-01-13 06:52:18 <tpm476> k
65 2014-01-13 06:52:40 <Luke-Jr> so take the first 80 bytes of data, and reverse the order of each 32-bit block
66 2014-01-13 06:52:44 <Luke-Jr> then you have the block header
67 2014-01-13 06:52:56 <Luke-Jr> but even that may be irrelevant for your needs
68 2014-01-13 07:03:55 <tpm476> okay , thanks
69 2014-01-13 07:25:41 <wumpus> sipa: I'm not sure about #3520, you're trying to add HD wallet support without touching the wallet code? :)
70 2014-01-13 07:32:15 <gmaxwell> Baby steps.
71 2014-01-13 07:34:46 <wumpus> but it's bound to confuse people a lot, what are they supposed to do with the generated keys and addresses?
72 2014-01-13 07:35:40 <wumpus> or is this meant with use of the raw transactions API, if you do the key management completely outside the daemon?
73 2014-01-13 07:36:13 <gmaxwell> wumpus: thats what I thought, fwiw, but I'm no more a mind reader than you. :)
74 2014-01-13 07:36:47 <warren> wumpus: maybe we'll have HD wallet support outside of the wallet, some of which are watch-only, mixed into your balance. Not confusing at all.
75 2014-01-13 07:36:53 <gmaxwell> unfortuantely the bip32 code in bitcoin is pretty deeply integrated into the overall codebase, or I'd suggest just making it a seperate utility we could ship. (though that wouldn't help people who wanted rpc access to it because they're coding in objective brainfuck or something)
76 2014-01-13 07:36:59 <wumpus> heh, in that case it should come with a big warning, I'm sure people will otherwise try to use it with importprivkey
77 2014-01-13 07:37:35 <wumpus> warren: okay, not confusing at all, I'll shut up about it, let's just merge it and see then
78 2014-01-13 07:37:48 <warren> wumpus: I'm never sarcastic.
79 2014-01-13 07:37:59 <wumpus> warren: I'm never sarcastic either
80 2014-01-13 07:38:12 <wumpus> :D
81 2014-01-13 07:39:18 <wumpus> gmaxwell: there is a place for some kind of library stuff that could be in bitcoind but doesn't use any of the reasons for the daemon for existing (network, blockchain or wallet)
82 2014-01-13 07:39:35 <wumpus> gmaxwell: in which case putting it in the daemon is only a bottleneck
83 2014-01-13 07:40:59 <wumpus> it could be an external utility as well, but that'd mostly be useful for command-line
84 2014-01-13 07:42:26 <wumpus> command-line key and transaction manipulation is something that Amir and al are making the 'sx' utility for
85 2014-01-13 07:45:44 <wumpus> but I really don't like to make people depend on bitcoind (which is at heart a full node) for all kind of auxiliary things. you'd force someone to run a full node to be able to use BIP32 functionality.
86 2014-01-13 07:45:58 <wumpus> which is good for the number of full nodes of course
87 2014-01-13 07:49:37 <gmaxwell> wumpus: one doesn't exclude the other though.
88 2014-01-13 07:49:53 <gmaxwell> And the rpc does have the benefit of being all languages callable.
89 2014-01-13 07:49:58 <gmaxwell> and working as a commandline tool.
90 2014-01-13 07:50:30 <wumpus> yes, RPC has that advantage, but it doesn't need to be RPC on bitcoind
91 2014-01-13 07:50:45 <wumpus> it could be miscfunstuffd too
92 2014-01-13 07:52:44 <warren> wumpus: I'm playing with watch-only, found another bug
93 2014-01-13 07:52:53 <warren> need to retest in actual bitcoin master ...
94 2014-01-13 07:53:34 <gmaxwell> wumpus: ::nods::
95 2014-01-13 07:54:01 <wumpus> warren: seems to be full of bugs lately
96 2014-01-13 07:54:09 <wumpus> warren: I'm happy we didn't merge it yet
97 2014-01-13 07:54:51 <wumpus> warren: but yes, please report any bugs with that in pull #3383
98 2014-01-13 07:55:07 <warren> wumpus: confirming it's in master before I do, I did another backport to 0.8
99 2014-01-13 07:55:27 <warren> it was working until it decided to change isminetype from 0 to 1 for no reason
100 2014-01-13 07:55:39 <warren> well, for no good reason
101 2014-01-13 08:04:49 <warren> wumpus: master + watchonly does not build for me
102 2014-01-13 08:05:31 <wumpus> warren: I just did a rebase and full buld of that pull, worked fine for me
103 2014-01-13 08:05:47 <warren> http://0bin.net/paste/TKi+MS6R3B5Fxekt#YtXZ7qpH2GqBljll2TOU9wMcoK0E+dc3Mh6pxhTWaWA=
104 2014-01-13 08:06:04 <warren> makes no sense ...
105 2014-01-13 08:06:08 <wumpus> did you make clean first?
106 2014-01-13 08:06:12 <warren> oh
107 2014-01-13 08:15:51 <Lifeofcray> https://twitter.com/BitEmber coinye giveaway at 50k
108 2014-01-13 08:22:33 <tpm476> hi
109 2014-01-13 08:22:57 <tpm476> can anyone here explain how coinbasetxn is generated by the pool using getblocktemplate ?
110 2014-01-13 08:25:05 <warren> anyone have testnet coins? I need ~20 inputs to test something.
111 2014-01-13 08:25:07 <michagogo> cloud|Lifeofcray: this is not the place for that. L
112 2014-01-13 08:25:15 <michagogo> cloud|That.*
113 2014-01-13 08:25:56 <warren> mxCseC2bisCMb7eFjBnPZEKN1Y2yJe8d14
114 2014-01-13 08:54:48 <fanquake> Is anyone else unable to build master on osx? Been trying with QT4/5 and consistently getting build errors.
115 2014-01-13 08:55:34 <fanquake> moc_bitcoingui.cpp:190:22: error: no member named 'trayIconActivated' in 'BitcoinGUI'
116 2014-01-13 08:57:46 <wumpus> fanquake: could be a regression due to the GUI merges this weekend
117 2014-01-13 08:58:12 <wumpus> I can check windows and linux, but not macosx
118 2014-01-13 09:03:43 <wumpus> (as there is no cross build for that)
119 2014-01-13 09:06:56 <fanquake> mmm not yet. I think theuni was working on building deterministic osx dmgs from linux. Although I can't seem to find the branch with that work anymore.
120 2014-01-13 09:07:15 <wumpus> yes, there is work on that, but it's very hard
121 2014-01-13 09:07:57 <wumpus> in any case, have you checked it's not just a matter of make clean?
122 2014-01-13 09:08:44 <wumpus> hmm - trayIconActivated shouldn't even exist on macosx
123 2014-01-13 09:09:06 <wumpus> it's all in #ifndef Q_OS_MAC
124 2014-01-13 09:10:54 <fanquake> Yea. Originally I thought it might have been because I was building with qt4, so i cleaned up, and then tried building again with qt5 and got the same result.
125 2014-01-13 09:11:05 <wumpus> I see the problem https://github.com/bitcoin/bitcoin/commit/ec41342
126 2014-01-13 09:11:23 <wumpus> can you change that line to MOC_DEFS+=$(DEFS) -I$(top_srcdir)/src
127 2014-01-13 09:11:40 <fanquake> Sure.
128 2014-01-13 09:11:55 <wumpus> (it's now completely overriding the MOC_DEFS, causing the macosx def to be lost)
129 2014-01-13 09:14:06 <warren> wumpus: hmm
130 2014-01-13 09:14:31 <warren> wumpus: I was unable to reproduce my own suspected bug because I ran into the issue that kyledrake complained about
131 2014-01-13 09:16:19 <wumpus> warren: have you tried your own suggestion?
132 2014-01-13 09:16:25 <Happzz> i was wondering, how secure is an encrypted wallet.dat
133 2014-01-13 09:16:35 <warren> wumpus: huh?
134 2014-01-13 09:16:59 <wumpus> warren: that you made to kyledrake, about 3502
135 2014-01-13 09:17:39 <warren> I didn't really have a suggestion
136 2014-01-13 09:17:53 <wumpus> then test with #3502 merged
137 2014-01-13 09:17:59 <warren> oh, I did, it's broken
138 2014-01-13 09:18:07 <warren> or at least his address isn't showing any watchonly inputs
139 2014-01-13 09:18:23 <warren> ACTION tries a different address
140 2014-01-13 09:19:20 <fanquake> wumpus Seems to have fixed the issue, and build time decreased at least 80%.
141 2014-01-13 09:19:38 <warren> wumpus: hmm, his test address doens't work, a random other one does.
142 2014-01-13 09:20:53 <lechuga__> "Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them."
143 2014-01-13 09:21:05 <lechuga__> so what does that imply
144 2014-01-13 09:21:33 <lechuga__> if the nodes dont relay them could these ever be useful?
145 2014-01-13 09:23:19 <wumpus> miners can include them for you directly
146 2014-01-13 09:23:39 <lechuga__> how would i give them directly to miners
147 2014-01-13 09:24:04 <wumpus> some pools have APIs for that
148 2014-01-13 09:24:34 <lechuga__> are u awar eof any?
149 2014-01-13 09:24:36 <lechuga__> specifically
150 2014-01-13 09:25:01 <wumpus> no, do your own research
151 2014-01-13 09:26:00 <warren> wumpus: hmm, my bug didn't happen in master, and kyledrake's address is just different somehow
152 2014-01-13 09:26:17 <warren> wumpus: on 0.8 if I rename the label of a watchonly address it changes isminetype to 1
153 2014-01-13 09:26:49 <warren> trying to backport it to 0.8.6 for kyledrake
154 2014-01-13 09:28:18 <lechuga__> looks like i can send the txs to hub nodes
155 2014-01-13 09:31:45 <warren> I'll figure it out.
156 2014-01-13 09:32:24 <sipa> wumpus: there are already python, go, java, c++ libraries out there that can do bip32 derivation
157 2014-01-13 09:33:16 <sipa> wumpus: it's in the same class of operations as decoderawtransaction
158 2014-01-13 09:34:43 <wumpus> sipa: yes, it is
159 2014-01-13 09:35:05 <wumpus> but I'm personally not really happy on extending that class more and more
160 2014-01-13 09:35:40 <sipa> well, i can't imagine not having any "reference" implementation for that functionality
161 2014-01-13 09:35:44 <wumpus> and as this looks like wallet functionality it might get people to make some terrible errors, as they think it's integrated with the wallet
162 2014-01-13 09:36:04 <sipa> the plan obviously is to integrate it with the wallet
163 2014-01-13 09:36:21 <sipa> i'm happy to wait with merging it until that is implemented too
164 2014-01-13 09:36:45 <wumpus> it just confuses me, I'm ok with merging it, it doesn't get in the way or anything like that
165 2014-01-13 09:36:58 <sipa> agree about potential confusing
166 2014-01-13 09:38:05 <sipa> shipping 0.9 with hdderive but without actual bip32 wallet sounds dangerous and confusing indeed
167 2014-01-13 09:38:05 <wumpus> but we've been trying to discourage people from doing per-key manipulations with bitcoind for ages, and now we introduce a nice way to generate privkeys/addresses without the wallet... which is cool, if there wasn't already wallet functionality in bitcoind
168 2014-01-13 09:38:34 <wumpus> right
169 2014-01-13 09:39:07 <sipa> i don't believe not having functionality will discourage people from doing key manipulation, though i agree with the sentiment
170 2014-01-13 09:39:13 <gmaxwell> sipa: I would point out that we could switch to use the bip32 in a straight line private derrive only with just a few lines of code.
171 2014-01-13 09:39:34 <sipa> the only solution is to have working easy solutions that avoid it
172 2014-01-13 09:39:40 <gmaxwell> they're doing key manipulation anyways, with random python code that google turns up which may never even have been tested.
173 2014-01-13 09:39:57 <wumpus> sipa: and the thing is that doing key manipulation is fine and dandy, if not combined with the current wallet implementation
174 2014-01-13 09:40:13 <sipa> hell, there's already a website that can do what hdderive can
175 2014-01-13 09:40:47 <wumpus> right, let's just add a serious warning then
176 2014-01-13 09:41:01 <sipa> wumpus: ok, let's wait until we have *some* deterministic wallet implementation befote merging hdderive?
177 2014-01-13 09:41:18 <wumpus> *this is a independent utility function and does not allow turning the bitcoind wallet into a determinstic wallet*
178 2014-01-13 09:41:43 <sipa> that text is also useful as documentation
179 2014-01-13 09:43:11 <wumpus> sipa: currently the functionality is unavailable when building with --disable-wallet, that makes no sense :)
180 2014-01-13 09:43:18 <warren> wumpus: what changed in https://github.com/bitcoin/bitcoin/pull/3383 an hour ago?
181 2014-01-13 09:45:09 <sipa> wumpus: i thought about that
182 2014-01-13 09:45:11 <wumpus> warren: rebased to master
183 2014-01-13 09:45:21 <warren> k
184 2014-01-13 09:45:39 <sipa> wumpus: but if you don't build in a wallet, i assume you just want a relay node that does not do any walleting
185 2014-01-13 09:45:50 <wumpus> sipa: it's key manipulation utility functionality, not wallet functionality, so belongs in rpcmisc.cpp with the other utility stuff IMO
186 2014-01-13 09:45:57 <sipa> ok
187 2014-01-13 09:46:07 <wumpus> sipa: sure, but we crossed that line with validateaddress and such already
188 2014-01-13 09:46:41 <sipa> i hate it that we have rpcs that may ir may not have wallet functionality, and work differently between the cases
189 2014-01-13 09:46:45 <wumpus> sipa: that was my initial opinion too, but jgarzik made a good point that everything that can be available without wallet should be, and deciding what to put where can wait until real modularization
190 2014-01-13 09:46:56 <sipa> createrawtransaction for example
191 2014-01-13 09:47:00 <wumpus> sipa: ... me too
192 2014-01-13 09:47:04 <wumpus> it really complicates things
193 2014-01-13 09:47:52 <wumpus> validateaddress just validates an address without wallet, but with wallet it's suddenly 'show address details'
194 2014-01-13 09:47:54 <warren> these util features would help bitcoin core compete with the alt implementations too...
195 2014-01-13 09:48:08 <warren> while it is confusing, it isn't wrong
196 2014-01-13 09:48:37 <wumpus> getinfo is the worst offender here, showing information about all kinds of unrelated concerns
197 2014-01-13 09:48:47 <sipa> moving the wallet specific part of validateaddress to getaddressinfo or so would not hurt
198 2014-01-13 09:48:55 <sipa> and getinfo is a kitchen sink
199 2014-01-13 09:49:10 <gmaxwell> getinfo is also bad because getting the balances is _slow_.
200 2014-01-13 09:49:28 <sipa> getwalletinfo go go go
201 2014-01-13 09:49:28 <wumpus> warren: how would that be? as the utility code is unrelated to everything, they can easily merge it with their own versions too
202 2014-01-13 09:49:51 <wumpus> getwalletinfo and getaddressinfo, good ideas
203 2014-01-13 09:49:55 <gmaxwell> yea, stripping all the wallet stuff from getinfo would be good.
204 2014-01-13 09:50:08 <warren> wumpus: alt implemenations tend to be written in <other language>
205 2014-01-13 09:50:20 <wumpus> warren: ahhh right.. I was confused with ALTcoins
206 2014-01-13 09:51:06 <sipa> perhaps have getwalletinfo and getnodeinfo
207 2014-01-13 09:51:17 <sipa> with getinfo a deprecated merge of both
208 2014-01-13 09:51:34 <wumpus> getblockchaininfo :P
209 2014-01-13 09:51:36 <wumpus> good idea sipa
210 2014-01-13 09:52:13 <sipa> maybe it would depend on how we decouple things when modularizing
211 2014-01-13 09:52:29 <sipa> node, valudatation engine, blockchain database
212 2014-01-13 09:52:36 <sipa> may become separate parts
213 2014-01-13 09:52:48 <sipa> bah, validation
214 2014-01-13 09:56:45 <lechuga__> ah eligius has a way to push txs directly
215 2014-01-13 09:59:12 <CodeShark> <--- is happy to see efforts underway to remove wallet dependencies from bitcoind :)
216 2014-01-13 09:59:24 <wumpus> CodeShark: yes, finally
217 2014-01-13 10:00:44 <CodeShark> is the immediate plan to split the two processes completely? or is there an interim step where we just have two separate builds?
218 2014-01-13 10:01:05 <sipa> right now, the wallet is just an optional part
219 2014-01-13 10:01:12 <wumpus> the interim step is to be able to build entirely without wallet
220 2014-01-13 10:01:14 <CodeShark> optional meaning compiletime option?
221 2014-01-13 10:01:19 <sipa> yes
222 2014-01-13 10:01:28 <CodeShark> ok
223 2014-01-13 10:01:33 <sipa> ./configure --disable-wallet
224 2014-01-13 10:01:45 <sipa> which also removes the bdb dependency of the build
225 2014-01-13 10:01:49 <CodeShark> right
226 2014-01-13 10:02:09 <TD> good morning
227 2014-01-13 10:02:15 <CodeShark> good morning, TD
228 2014-01-13 10:02:22 <sipa> good morning, infidels
229 2014-01-13 10:02:50 <wumpus> CodeShark: next step will be modularizing bitcoind, so that it's easier to experiment with alternative wallet implementations, including ones that run in a seperate process
230 2014-01-13 10:03:14 <CodeShark> alright - I'm very interested in this part of the process especially
231 2014-01-13 10:03:20 <sipa> ACTION still likes to see the wallet run on an SPV core
232 2014-01-13 10:03:57 <sipa> so the GUI could either run directly as an SPV node, or it could fork a full node in the backgrouns and -connect to it
233 2014-01-13 10:04:15 <wumpus> CodeShark: see #3440 and #3465 for plans
234 2014-01-13 10:04:50 <wumpus> sipa: I'm not so sure about that anymore; good SPV wallets exist, what would ours add?
235 2014-01-13 10:05:08 <sipa> wumpus: not requiring a full node
236 2014-01-13 10:05:50 <TD> isn't that circular?
237 2014-01-13 10:05:55 <TD> you just defined SPV :)
238 2014-01-13 10:05:56 <sipa> and it can still easily integrate with one (allow running one transparently if resources allow...)
239 2014-01-13 10:05:59 <CodeShark> we can still provide proofs of tx inclusion of blockchain without requiring the client to connect via p2p protocol
240 2014-01-13 10:06:08 <CodeShark> *proofs of tx inclusion in blockchain
241 2014-01-13 10:06:14 <TD> well, we can start on that by embedding a micro-jvm into bitcoin-qt and then checking to see if localhost:8333 is open :)
242 2014-01-13 10:06:17 <wumpus> I mean, multibit could do the same (fork a full node on the background)
243 2014-01-13 10:06:27 <TD> although for security reasons i'm not sure it's such a great idea to do loopback sockets :)
244 2014-01-13 10:06:35 <TD> on multi-user systems that sounds like a recipe for MITM
245 2014-01-13 10:07:19 <sipa> wumpus: i think it is silly to burden our wallet implementation (which is bloated and has flaws, but works) by requiring a full node underneath which it does not use for anything it all
246 2014-01-13 10:08:01 <wumpus> sure, you have a point for consistency
247 2014-01-13 10:08:11 <CodeShark> the SPV layer probably deserves to run as a separate process as well (or at the very least have good libraries for it)
248 2014-01-13 10:08:43 <wumpus> I'd like a bitcoin-qt-spv as well
249 2014-01-13 10:08:59 <gmaxwell> from a priv sep perspective I'd certantly like it if nothing with private key access was in the same memory space as something connecting to untrusted nodes.
250 2014-01-13 10:09:05 <CodeShark> right now my current architecture is something like p2p <-> SPV-to-higher-level-IPC <-> wallet
251 2014-01-13 10:09:25 <sipa> bitcoin-core-lightweight-wallet-gui
252 2014-01-13 10:10:06 <CodeShark> or not even necessarily IPC - could be signals/slots within the same process
253 2014-01-13 10:10:14 <wumpus> gmaxwell: indeed, and sharing a blockchain daemon would be possible between multiple wallets run by multiple users
254 2014-01-13 10:10:41 <wumpus> multiple different wallet implementations even
255 2014-01-13 10:11:53 <CodeShark> we could have an SPV service running which can be called from different bitcoin-enabled applications
256 2014-01-13 10:12:08 <CodeShark> which provides a high level API for receiving SPV-proofs and state updates
257 2014-01-13 10:12:25 <TD> frankly i think running full nodes on end-user systems is doomed in the long run. not that many people are using desktop systems outside of offices anymore, and the trend on laptops is to care a lot about energy usage
258 2014-01-13 10:12:40 <CodeShark> obviating the need for each and every bitcoin-enabled app to have to worry about the SPV logic, which is far from trivial
259 2014-01-13 10:12:51 <TD> so it's probably not worth doing funny logic for the case where both run on the same machine
260 2014-01-13 10:12:56 <wumpus> TD: people are also running bittorrent on end user systems
261 2014-01-13 10:13:20 <wumpus> which similarly consumes a lot of bandwidth, power and disk space
262 2014-01-13 10:13:29 <TD> for downloading, sure? i thought they had to spend a ton of effort trying to get people to seed
263 2014-01-13 10:13:41 <wumpus> it's just a matter of motivating them it's a good thing
264 2014-01-13 10:13:53 <sipa> TD: i like the approach i suggested because it foesn't care about whether it's running on the same system or not, or whether they have a full node or not
265 2014-01-13 10:13:54 <wumpus> oh sure
266 2014-01-13 10:13:58 <TD> sipa: sure
267 2014-01-13 10:14:15 <TD> sipa: you're preaching to the choir here, i spent years on spv for exactly this reason :-)
268 2014-01-13 10:14:18 <CodeShark> sipa, that's exactly yhe approach I'm currently using
269 2014-01-13 10:14:21 <CodeShark> *the
270 2014-01-13 10:14:21 <sipa> haha
271 2014-01-13 10:14:33 <CodeShark> yeah, I think we're all on the same page here
272 2014-01-13 10:14:34 <TD> i'd like to implement a bitcoind compatible JSON-RPC API on top of bitcoinj at some point
273 2014-01-13 10:14:38 <wumpus> but I wouldn't like it when only big companies with huge servers could run a full node
274 2014-01-13 10:14:49 <TD> so people can retarget apps between them easily, if they can fit into that API. then it's really easy to trade off security vs resource usage
275 2014-01-13 10:15:07 <lianj> wumpus: but thats what it will be like
276 2014-01-13 10:15:18 <sipa> CodeShark: what exactly does the layer in between do? send notifications of "connect this block, disconnect this block" ?
277 2014-01-13 10:15:18 <TD> wumpus: ah, we won't get there any time soon. most crappy VPS's have less RAM and disk than most laptops. but ... they run 24/7 and nobody cares about their heat or power usage (much)
278 2014-01-13 10:15:28 <TD> wumpus: if they make a lot of noise, again, who cares.
279 2014-01-13 10:15:50 <CodeShark> yes, sipa - it could even provide higher level messages such as "transaction satisfying filter X received 6 confirmations"
280 2014-01-13 10:16:03 <sipa> right
281 2014-01-13 10:16:13 <wumpus> TD: people are running full nodes on their desktop pcs/laptops, and will be for the considerable future
282 2014-01-13 10:16:22 <sipa> makes sense if you want to run many wallets
283 2014-01-13 10:16:57 <wumpus> but sure, it's not something for end users that simple want a wallet
284 2014-01-13 10:16:59 <TD> if you compare usage numbers for bitcoin-qt stable/listening nodes vs something like blockchain.info, which just blew past 1 million wallets ...... i'm not sure that's much of a comparison
285 2014-01-13 10:17:02 <TD> yeah
286 2014-01-13 10:17:22 <sipa> TD: not a fair comparison
287 2014-01-13 10:17:22 <wumpus> I'm not trying to say 'a majority of users should be running a full node' or something like that
288 2014-01-13 10:17:39 <lianj> daily/weekly active
289 2014-01-13 10:18:05 <sipa> TD: i'm not sure many of those b.i users would choose a full node or even SPV wallet, if it was feature-wise comparable and 0 resource usage
290 2014-01-13 10:18:44 <sipa> wumpus: my goal is "it should be easy to run a full node, if you want to"
291 2014-01-13 10:18:52 <wumpus> sipa: right
292 2014-01-13 10:19:12 <sipa> hiw many people do (as long as it's sufficient for the network) doean't matter that much
293 2014-01-13 10:19:14 <wumpus> running a full node should be decoupled from 'wallet' as much as possible
294 2014-01-13 10:19:28 <TD> right, probably a lot of them are wanting the other things it provides (zero start/setup time, free tech support, etc)
295 2014-01-13 10:19:39 <gmaxwell> I don't think I've encountered a single business at the local bitcoin meetup which is running a node. They ~all use coinbase or bc.i apis.
296 2014-01-13 10:20:13 <sipa> gmaxwell: which may be due to lack of good wallet api integration in bitcoind
297 2014-01-13 10:20:22 <wumpus> gmaxwell: apart from exchanges and trading sites and such
298 2014-01-13 10:20:25 <TD> or the total and complete lack of documentation, maybe?
299 2014-01-13 10:20:27 <gmaxwell> heck, one told me that they tried to use bitcoinj but the resource requirements were too high. (something about java memory usage and large numbers of transactions?)
300 2014-01-13 10:20:49 <sipa> though i guess in general, businesses like to depend on things they can sue if it goes wrong
301 2014-01-13 10:20:51 <TD> if you arrived at bitcoin.org and didn't know anything, you would have no way to learn the bitcoind API even existed
302 2014-01-13 10:20:53 <TD> let alone how to use it
303 2014-01-13 10:21:03 <TD> gmaxwell: it stores all transactions in RAM, yes, not a database.
304 2014-01-13 10:21:16 <TD> gmaxwell: it's not really designed for the merchant/payment processor use case.
305 2014-01-13 10:21:48 <TD> memory usage is sort of competing with finishing HD wallets for my time at the moment because some big wallets are running out of ram on android too
306 2014-01-13 10:21:58 <TD> building an O(1) wallet in every dimension is quite tricky though
307 2014-01-13 10:22:12 <sipa> not theoretically possible :)
308 2014-01-13 10:22:35 <TD> that's why i said it's quite tricky. be optimistic, man! we still aren't sure that P != NP, right?
309 2014-01-13 10:22:39 <SomeoneWeird> but practically? :P
310 2014-01-13 10:22:45 <gmaxwell> No one complained about that, though its true, and perhaps they would have if they'd gotten that far. As far as I can tell it was resource usage on VPS systems that threw people the most. but also more than that, I got the impression that a lot of people who are doing web startups are really comfortable and familar with third party provided callbacky web service for services... they already use them for a bunch of things they do like email.
311 2014-01-13 10:22:55 <TD> yeah
312 2014-01-13 10:23:40 <TD> well you can certainly sync a wallet on a VPS no problem, but if you have lots of transactions then it'll run out of RAM and start swapping eventually. no clue at what level of transaction traffic that would occur though. if they run a bitcoind then i guess that'd already take most of the resources
313 2014-01-13 10:23:57 <TD> "web startups" are just bad news for decentralisation all round really
314 2014-01-13 10:24:10 <sipa> i think, businesses in general
315 2014-01-13 10:24:13 <TD> the web is itself a decentralised system, but things within it are practically impossible to decentralise
316 2014-01-13 10:24:23 <TD> and people just aren't used to thinking in that way
317 2014-01-13 10:24:36 <gmaxwell> (this was surprising to me) in any case I'm not sure a lot of people would even look for bitcoind documents, like.. I think they don't all even know how to log into the unix shell their VPS provides. (I don't say this to criticize, it's just "run a daemon" is kind of outside of the workflow for some folks: apparently they use services that provide things like postgresql or mongo or memcached as a clicky option on a webpage)
318 2014-01-13 10:24:54 <TD> right, things like heroku or app engine
319 2014-01-13 10:25:06 <TD> on one hand i love how easy these tools have made bringing up a quick web site or service that scales
320 2014-01-13 10:25:24 <gmaxwell> yea, heroku was what one guy was using. This stuff is almost completely foreign to me, so it was a bit eye opening.
321 2014-01-13 10:25:28 <TD> on the other hand outsourcing isn't really compatible with low-trust systems
322 2014-01-13 10:25:41 <TD> coinbase is such a glaring SPOF it hurts. and based in california! argh
323 2014-01-13 10:25:57 <lianj> yea, some wordpress shop accepting bitcoin (at least currently) will have a hard und unpleasent time running bitcoind himself and building upon that
324 2014-01-13 10:26:04 <shesek> its pretty much impossible to run bitcoind on heroku, you have a filesystem that should be used as readonly
325 2014-01-13 10:26:24 <gmaxwell> One person commented about needing to keep his personal bitcoins in many different web wallets "because you never know which one will get hacked next!" ... it was in humor but also serious.
326 2014-01-13 10:26:27 <shesek> heroku isn't really meant for running that kind of stuff
327 2014-01-13 10:26:31 <TD> well you obviously wouldn't do that. you would run bitcoind on a server you own and then have heroku call out to it over SSL. that's what gavin did for the faucet
328 2014-01-13 10:26:33 <TD> (on app engine)
329 2014-01-13 10:26:48 <warren> hi, could someone please mine testnet?
330 2014-01-13 10:27:04 <wumpus> warren: just use -regtest man :)
331 2014-01-13 10:27:15 <sipa> a colleague had written some DHT database for finding peers, and suggested bitcoin could use it for bootstrapping
332 2014-01-13 10:27:18 <TD> gmaxwell: yes what i take away from all of this is that we need way better documents and explanations on the website for developers. the current website rocks for end users but has zip for anyone who is wondering how to build a bitcoin startup
333 2014-01-13 10:27:31 <sipa> he didn't have an answer to how to bootstrap the DHT though :p
334 2014-01-13 10:27:40 <gmaxwell> sipa: "but how do you find the dht peers" "oh it just connects to my webserver"
335 2014-01-13 10:27:40 <TD> lol
336 2014-01-13 10:28:39 <shesek> couldn't it be possible to (ab)use the bittorrent dht for bootstraping peers?
337 2014-01-13 10:28:57 <shesek> not saying that its a particularly good idea... but should be possible
338 2014-01-13 10:29:10 <gmaxwell> it's not necessary (bittorrent dht has the same bootstrapping problem too)
339 2014-01-13 10:29:14 <TD> the current bootstrap mechanisms work fine
340 2014-01-13 10:30:08 <shesek> how does it currently work? dns and irc? (irc being off by default iirc)
341 2014-01-13 10:30:22 <wumpus> for all the problems bitcoin has, bootstrapping isn't one
342 2014-01-13 10:30:36 <TD> dns
343 2014-01-13 10:30:41 <TD> irc is gone for a long time now already
344 2014-01-13 10:30:50 <shesek> I'm not sure how fine that is... its probably the most centralized part of bitcoin right now
345 2014-01-13 10:30:50 <warren> wumpus: not having used that before, I'm confused
346 2014-01-13 10:30:51 <TD> there's also a hard coded list of seeds that we routinely forget to update
347 2014-01-13 10:31:01 <warren> wumpus: -regtest seems to run mainnet
348 2014-01-13 10:31:10 <shesek> someone gaining access to the dns server could quite easily abuse it
349 2014-01-13 10:31:23 <wumpus> warren: on master it doesn't
350 2014-01-13 10:31:30 <TD> warren: regtest mode is undocumented, unfortunately. it runs a variant of the main network params that allows you to mine new blocks instantly
351 2014-01-13 10:31:35 <wumpus> warren: and that was just a matter of the GUI anyway
352 2014-01-13 10:31:36 <shesek> returning specific nodes for dns queries from a specific merchant you're trying to double spend should be very doable
353 2014-01-13 10:31:45 <TD> warren: bitcoinj supports it and i use it all the time, it's much more convenient for testing than the testnet
354 2014-01-13 10:31:45 <warren> oh, there's no regtest in 0.8
355 2014-01-13 10:31:52 <TD> you need master
356 2014-01-13 10:32:08 <wumpus> oh, it wasn't in 0.8, right
357 2014-01-13 10:33:46 <sipa> btw, we seem to have several changes in masternthat warrant a BIP
358 2014-01-13 10:33:52 <sipa> like the reject message
359 2014-01-13 10:34:01 <TD> i think gavinandresen wrote a bip for that already
360 2014-01-13 10:34:22 <TD> what we REALLY need is someone who is going to sit down with saivann and help write a developer center, that can talk about regtest mode and stuff.
361 2014-01-13 10:34:36 <TD> right now these useful tools are just passed down via lore and legend, like a medieval song about dragons
362 2014-01-13 10:34:56 <TD> "men who came from across the ocean whisper of ..... a REGTEST MODE"
363 2014-01-13 10:34:57 <sipa> yup!
364 2014-01-13 10:35:12 <TD> "but nobody knows where exactly it lies. man and boy have perished in the search"
365 2014-01-13 10:35:23 <sipa> "have you not heard about the regtest mode? how dare you call yourself a true knight of the bits!"
366 2014-01-13 10:35:37 <TD> hah
367 2014-01-13 10:35:42 <TD> in fairness
368 2014-01-13 10:35:49 <TD> i'm the one who added that. and i didn't document it anywhere
369 2014-01-13 10:36:01 <TD> so .... my bad.
370 2014-01-13 10:36:09 <sipa> there was another change recently i couldn't find a bip for either
371 2014-01-13 10:36:22 <TD> i think the reject bip might be a gist at the moment
372 2014-01-13 10:36:40 <TD> hmm. jeremy spilman is kind of awesome
373 2014-01-13 10:37:01 <TD> "it should probably work like this" .... 24 hours later, "ok here's a full design doc, screenshots and implementation".
374 2014-01-13 10:37:50 <sipa> ah, the OP_RETURN output isn't documented anywhere either
375 2014-01-13 10:39:56 <TD> lol
376 2014-01-13 10:40:01 <TD> no well the wiki has kinda broke
377 2014-01-13 10:40:16 <TD> the anti-spam fee doesn't float
378 2014-01-13 10:40:25 <TD> so we sort of lost our documentation space (or at least, it's not open to new users)
379 2014-01-13 10:40:36 <TD> you know what? maybe we should ask around to find a volunteer to help with this stuff
380 2014-01-13 10:40:56 <wumpus> agreed TD, the wiki is not useful anymore, requiring payment kind of killed off the flow of new users, which are generally those which contribute most new stuff to a wiki
381 2014-01-13 10:41:09 <gmaxwell> TD: the wiki fee was recently reduced to be reasonable again. Actually magicaltux fixed it a while ago but no one updated the message. 0_o
382 2014-01-13 10:41:23 <wumpus> quite a feat, together with killing spamming they killed contributions
383 2014-01-13 10:41:29 <TD> oh, lol
384 2014-01-13 10:41:55 <TD> that's sort of sums up the documentation problem
385 2014-01-13 10:42:00 <sipa> wumpus: the wiki was already much outdated before that
386 2014-01-13 10:42:01 <gmaxwell> wumpus: thats basically a norm for wiki anti-baddness measures. Most of the things people try scare away _more_ good users than bad ones.
387 2014-01-13 10:42:02 <TD> "we made updating the documentation cheaper, but didn't document it"
388 2014-01-13 10:42:07 <gmaxwell> hahaha
389 2014-01-13 10:42:12 <sipa> TD: LOL
390 2014-01-13 10:42:36 <TD> wumpus: i spent years trying to find the right balance there for google.com account signup. it's a super hard problem, especially for low commitment users.
391 2014-01-13 10:42:46 <gmaxwell> Yea, the wiki was wrong and outdated early in 2011.
392 2014-01-13 10:42:46 <wumpus> I did update some RPC documentation here and there at some time, but it seemed like no one was reading it anyway
393 2014-01-13 10:43:00 <gmaxwell> wumpus: they'll only read it when its wrong and outdated, no doubt.
394 2014-01-13 10:43:09 <TD> wumpus: like, we let users skip the captcha if they want
395 2014-01-13 10:43:27 <TD> (and the captcha is now trivially easy)
396 2014-01-13 10:43:42 <wumpus> TD: keeping wikis spam free is a super hard problem, agreed, especially if you don't have a lot of voluntary moderators
397 2014-01-13 10:43:50 <gmaxwell> I suspect it would be a lot better with just some 'project management' .. I fix things from time to time as I stumble into them, but I'm always amazed at "oh god, it says this? man this is outdated"
398 2014-01-13 10:44:03 <TD> it's a nice thing for someone who wants to get involved but isn't sure how
399 2014-01-13 10:44:08 <TD> ACTION feels inspired and will make a forum post
400 2014-01-13 10:44:26 <wumpus> the wiki also isn't clear on who is involved with what
401 2014-01-13 10:44:44 <gmaxwell> I think the bitcoin payment also did a lot to stop the scam link insertions (e.g. people changing links to services with links to malware loading / password grabbing knockoffs) which isn't quite the spam problem.
402 2014-01-13 10:44:47 <wumpus> like, who you have to ask to get stuff changed around or renamed or deleted etc
403 2014-01-13 10:45:46 <wumpus> gmaxwell: developer documentation doesn't suffer from the malware problem as much as service lists, I guess
404 2014-01-13 10:46:10 <wumpus> maybe having it all on one wiki is not good
405 2014-01-13 10:46:13 <gmaxwell> I was kinda surprised that the fees helped.
406 2014-01-13 10:46:59 <gmaxwell> wumpus: well it certantly would be technically possible to make the fee required thing only apply to semi-protected pages. Probably would just be a config change.
407 2014-01-13 10:47:21 <sipa> somehow i don't feel encouraged to write stuff on the wiki
408 2014-01-13 10:47:30 <gmaxwell> (Mediawiki can flag pages with varrious levels of protected, there is a semi-protected level that is editable by anyone in a configured group, the group could be set to the paid-a-fee level)
409 2014-01-13 10:47:31 <sipa> it doesn't feel like i'm actually helping someone
410 2014-01-13 10:47:51 <TD> one of the reasons PHP was successful is that their API docs all have comment sections
411 2014-01-13 10:47:53 <wumpus> sipa: I have the same feeling
412 2014-01-13 10:47:54 <sipa> i write a lot on the bitcoin stackexchange tgoufh
413 2014-01-13 10:47:58 <TD> so people can discuss each page easily, and you see the comments immediately
414 2014-01-13 10:48:01 <gmaxwell> sipa: it gets read by a lot of people though. I know because I see people show up with crazy configuration files copied out of it⦠:P
415 2014-01-13 10:48:13 <sipa> and i sometimes see people convert my stackexchange answers to wiki pages
416 2014-01-13 10:48:16 <TD> makes it feel more like a community than a cold piece of data
417 2014-01-13 10:50:18 <TD> i spent a couple of years at google developing a javascript obfusaction and browser-proof system
418 2014-01-13 10:50:27 <TD> which proved to be very effective at silently detecting bots
419 2014-01-13 10:50:49 <TD> i wish we could use it on the wiki and then just scrap the fee, but unfortunately it's not a public api
420 2014-01-13 10:51:09 <gmaxwell> TD: still would do nothing for the malware/phishing links.
421 2014-01-13 10:51:23 <TD> no, but presumably those are much lower volume and more amenable to manual review
422 2014-01-13 10:52:22 <gmaxwell> yea, and the fee could just be flagged on high profile pages that get hit with those things perhaps.
423 2014-01-13 10:53:18 <TD> maybe one day i'll try a public reimplementation
424 2014-01-13 10:59:51 <sipa> "bitcoin gambling guide added you on google+"
425 2014-01-13 11:00:33 <TD> yes, well, i don't work on it anymore :)
426 2014-01-13 11:08:43 <warren> wumpus: crap ... master + watchonly left the block index in some state where 0.8 thinks it's corrupted, master can read it
427 2014-01-13 11:09:50 <sipa> watchonly has nothing to do with thr block index
428 2014-01-13 11:10:06 <warren> sipa: yeah, something else in master made it incompatible
429 2014-01-13 11:10:08 <sipa> but i have heard about cases where 0.8 can't read an index that master can
430 2014-01-13 11:10:44 <sipa> maybe leveldb upgrade?
431 2014-01-13 11:10:54 <sipa> that shouldn't happen
432 2014-01-13 11:11:05 <gwb3> QOTD JAN 13 2014: âPeople of accomplishment rarely sit back and let things happen to them. They go out and happen to things.â - Leonardo da Vinci
433 2014-01-13 11:14:12 <warren> dunno the cause
434 2014-01-13 11:19:12 <warren> sipa: whatever it is, it's incompatible now
435 2014-01-13 11:19:50 <sipa> for every wallet?
436 2014-01-13 11:19:58 <sipa> of just some specific wallet?
437 2014-01-13 11:20:00 <warren> sipa: for one testnet wallet I just tried
438 2014-01-13 11:20:11 <sipa> file a bug
439 2014-01-13 11:20:18 <sipa> please :)
440 2014-01-13 11:20:30 <warren> i'll try to get more details tomorrow before I file
441 2014-01-13 11:22:12 <wumpus> the wallet is incompatible too?
442 2014-01-13 11:22:31 <warren> I only know the 0.8 thinks the index is corrupt
443 2014-01-13 11:22:37 <warren> i'm out of time
444 2014-01-13 11:25:03 <sipa> ah, right, the index
445 2014-01-13 11:25:11 <sipa> i was confused
446 2014-01-13 11:31:30 <sipa> ugh, that stealth payment idea relies on op_return data?
447 2014-01-13 11:31:53 <sipa> why can't that metadata be sent as part of the payment?
448 2014-01-13 11:32:55 <TD> in the payment protocol instantiation it probably can
449 2014-01-13 11:33:02 <TD> remember it came out of the idea of a new type of address
450 2014-01-13 11:33:39 <sipa> i think we should just try to get rid of static addresses
451 2014-01-13 11:33:41 <TD> hmmm, there's now a pure java implementation of a tor client. very useful.
452 2014-01-13 11:33:46 <TD> runs on android too
453 2014-01-13 11:34:56 <sipa> making it easier to have static addresses with better privacy properties may be hard already to get adopted, and make it even harder to get rid of using the p2p mechanism as payment transport
454 2014-01-13 11:35:06 <TD> ACTION -> lunch
455 2014-01-13 11:38:51 <gmaxwell> sipa: there are just too many cases where static addresses are so blindingly easy that people will keep using them. I dunno that stealth addresses are the answer... but.
456 2014-01-13 11:39:22 <gmaxwell> (Personally I'm not super keen on schemes which are too dependent on narrowing the kind of scriptpubkey people can use)
457 2014-01-13 11:39:41 <sipa> yeah, if they were easy to deploy, they could easily cover that case
458 2014-01-13 11:40:27 <gmaxwell> e.g. any of the bizallion and one donation addresses out there.
459 2014-01-13 11:40:36 <sipa> but this will already take effort, costs extra data in the blockchain, doesn't solve the reliance on the chain as transport, and is limited (iirc) to simple (not script) payments
460 2014-01-13 11:42:05 <gmaxwell> yes some effortâ in particular things need to know how to send to it, only an extra ecc point, I'm not sure that chain transport is harmful here, and yes its limitedâ which is what I like least about it.
461 2014-01-13 11:42:43 <gmaxwell> the effort thing is mostly "no one will use an address type for donations that can't be paid to via every site and client imaginable"
462 2014-01-13 11:44:15 <sipa> (chain transport = no refund address, no memo, no notification to receiver, requires sender to be online until confirmation, ...)
463 2014-01-13 11:44:29 <michagogo> cloud|13:08:36 <warren> wumpus: crap ... master + watchonly left the block index in some state where 0.8 thinks it's corrupted, master can read it
464 2014-01-13 11:44:38 <michagogo> cloud|13:08:36 <warren> wumpus: crap ... master + watchonly left the block index in some state where 0.8 thinks it's corrupted, master can read it
465 2014-01-13 11:44:42 <michagogo> cloud|I think that's just master
466 2014-01-13 11:44:51 <wumpus> ?
467 2014-01-13 11:44:58 <michagogo> cloud|Not master+watchonly
468 2014-01-13 11:46:09 <gmaxwell> sipa: yes, but â what do you want for usecases which are really one way? ... and I note the payment protocol doesn't guarantee any of that because it lets you make a half duplex payment. :(
469 2014-01-13 11:46:34 <michagogo> cloud|I was seeing that the other day (had master running to update my bootstrap.dat, and 0.8.6 reported corruption when I tried to go back)
470 2014-01-13 11:47:40 <sipa> gmaxwell: half duplex?
471 2014-01-13 11:48:02 <gmaxwell> sipa: you can recieve a payment request and just send the transaction to the public network.
472 2014-01-13 11:48:32 <gmaxwell> michagogo|cloud: did you see where it was reporting corruption?
473 2014-01-13 11:48:54 <sipa> gmaxwell: you should still send the payment to the receiver
474 2014-01-13 11:49:37 <michagogo> cloud|gmaxwell: on launch, "error something or other. Do you want to rebuild the block database?"
475 2014-01-13 11:50:03 <michagogo> cloud|Didn't dig too deeply
476 2014-01-13 11:50:33 <gmaxwell> sipa: nothing makes you and your connection might fail, so you can't actually build your business around the assumption that it'll work. (e.g. expect to always get refunds that way)... as far as I understand it.
477 2014-01-13 11:51:09 <sipa> gmaxwell: that's broken
478 2014-01-13 11:51:44 <sipa> imho, if a payment uri ispresent, it must be the only way of sending the payment
479 2014-01-13 11:51:48 <sipa> bah
480 2014-01-13 11:52:31 <sipa> otherwise you may end up with a transaction that you have no idea what it is for, and cannot refund
481 2014-01-13 11:53:03 <sipa> inthink the payment protocol is pretty useless without being able to rely on that payment message being delivered
482 2014-01-13 11:53:29 <gmaxwell> well maybe I misunderstand it? I was sort of happy to let other people worry about it, esp since it's not useful to anyone who isn't running a secure webserver. (e.g. I can't even use it to give donation addresses out for me because I don't have a webserver that I'd trust to give out addresses to pay to)
483 2014-01-13 11:54:57 <sipa> well, if you can't rely on the payment being delivered, what is the point of having it in the first place?
484 2014-01-13 11:55:19 <sipa> why put a memo and a refund address in it, if you don't even know if the receiver is going to see it?
485 2014-01-13 11:55:47 <gmaxwell> it still has benefits in the forward direction, e.g. more details in the transaction log on the payer.
486 2014-01-13 11:56:28 <sipa> meh
487 2014-01-13 11:56:39 <sipa> it's the receiver that is the problem
488 2014-01-13 11:57:08 <sipa> if the payment message can't be relied upon, i think it's a lot easier to just drop it
489 2014-01-13 11:57:35 <sipa> and make no attempt at all to fix the problems of using the chain as transport
490 2014-01-13 11:57:38 <sipa> bah
491 2014-01-13 11:58:14 <TD> FYI in bitcoinj i am going to only be submitting via the requested URL endpoint (if there is one)
492 2014-01-13 11:58:20 <TD> and not via the p2p network at all in such cases
493 2014-01-13 11:58:28 <TD> at least, that's the plan
494 2014-01-13 11:58:48 <sipa> and use stealth addresses as privacy fix for the broken transport mechanism
495 2014-01-13 11:58:48 <TD> the current code doesn't quite close the loop on that yet, but it will
496 2014-01-13 11:59:11 <TD> no. they're just a way to simplify things in the case that you want to make a payment repeatedly.
497 2014-01-13 11:59:17 <TD> for example, consider a subscription service
498 2014-01-13 11:59:36 <TD> you could have expiring payment requests and ask the user to fetch a new one each time. but it's better to have deterministic or stealth addresses
499 2014-01-13 11:59:43 <TD> anyway, let's see how it goes
500 2014-01-13 12:03:10 <TD> i'm thinking that a simple site that hosts payment request files on a short URL is super easy to whip up, should be cheap to host (cheap enough to fund with some community-specific ads), and a simple REST API can be standardised so wallets can automatically upload there
501 2014-01-13 12:03:59 <TD> then a wallet app would just have a label in the UI that says "Pay to sipa" and you can drag/drop it into any rich text/html editing field. the link would be, "bitcoin:1....az34f?r=https://pay.to/{a}" or something
502 2014-01-13 12:04:02 <TD> which should still fit in a QRcode
503 2014-01-13 12:04:18 <TD> or indeed, is small enough to be steganographically encoded into a social network profile photo
504 2014-01-13 12:04:26 <TD> see? it all hangs together :-)
505 2014-01-13 12:10:36 <gmaxwell> https://bitcointalk.org/index.php?topic=413502.0 < what is it with people and the omg urgent change the protocol now stuff over minutia.
506 2014-01-13 12:14:18 <gmaxwell> "(cheap enough to fund" by getting "hacked" eventually, of course.
507 2014-01-13 12:14:23 <gmaxwell> :P
508 2014-01-13 12:16:07 <sipa> TD: doesn't change the fact that refund/memo (and pretty much the whole payment message) are useless if it can't be relied upon
509 2014-01-13 12:16:31 <sipa> both sender and receiver need to have an alternative fornthem in that case
510 2014-01-13 12:16:38 <sipa> * for them
511 2014-01-13 13:20:56 <jgarzik> sipa, getwalletinfo, getnetinfo
512 2014-01-13 13:20:59 <jgarzik> indeed
513 2014-01-13 13:21:23 <jgarzik> sipa, however, there is the "annoying" problem that getinfo's collection of information is quite useful
514 2014-01-13 13:21:42 <jgarzik> i.e. I use getinfo all the time, in lieu of calling multiple RPCs (inthe future) for the same info
515 2014-01-13 13:22:53 <wumpus> yes, if you use the rpc interactively, getinfo is useful
516 2014-01-13 13:33:45 <wumpus> maybe bitcoin-cli could do client-side emulation of it :p
517 2014-01-13 13:37:15 <sipa> we could also implement createrawtransaction and validateaddress and hdderive in bitcoin-cli :D
518 2014-01-13 13:37:31 <wumpus> hehe
519 2014-01-13 13:37:41 <sipa> i'm only half kidding
520 2014-01-13 13:39:56 <shamoon> how does a coinbase transaction have a fee associated with it? http://testnet.btclook.com/txn/b0a5c097a3301acde48c85d8eda3408014f3472cadf2419eb399734bd70d526e
521 2014-01-13 13:40:02 <shamoon> who pays that fee and where does it come from?
522 2014-01-13 13:40:29 <sipa> shamoon: it's the total fees in that block
523 2014-01-13 13:40:41 <sipa> that get claimed by the miner
524 2014-01-13 13:40:43 <sipa> (i presume)
525 2014-01-13 13:40:50 <shamoon> i thought each transaction carried a fee?
526 2014-01-13 13:40:56 <sipa> yes
527 2014-01-13 13:41:01 <shamoon> well - or COULD carry a fee
528 2014-01-13 13:41:09 <sipa> the coinbase transaction itself doesn't have a fee, as it doesn't have real inputs
529 2014-01-13 13:41:18 <sipa> so fee in the technical sense doesn't mean anything
530 2014-01-13 13:41:31 <sipa> but i presume here they're talking about the fees _claimed by_ the coinbase
531 2014-01-13 13:41:41 <sipa> not _payd by_
532 2014-01-13 13:41:42 <shamoon> so the other transactions in the block won't have fees?
533 2014-01-13 13:41:47 <shamoon> since it's included in the coinbase?
534 2014-01-13 13:41:47 <sipa> ...
535 2014-01-13 13:41:54 <sipa> sigh
536 2014-01-13 13:42:10 <shamoon> sorry for the dumb Q's so early in the AM
537 2014-01-13 13:42:10 <sipa> the output of a coinbase is allowed to be subsidy + fees paid in its block
538 2014-01-13 13:42:28 <sipa> so this is presumably a block with transactions that pay 0.02 BTC in fees, total
539 2014-01-13 13:42:34 <sipa> and the coinbase has an output of 50.02
540 2014-01-13 13:42:40 <sipa> it's how fees work
541 2014-01-13 13:42:52 <sipa> normal transactions pay them, the coinbase claims them
542 2014-01-13 13:43:03 <shamoon> so this transaction
543 2014-01-13 13:43:04 <shamoon> http://testnet.btclook.com/txn/55bc02f486beb830455dda8c3d9b9e56488780cee01f2d338244e0cba41b72c3
544 2014-01-13 13:43:06 <shamoon> for example..
545 2014-01-13 13:43:06 <sipa> 0.002
546 2014-01-13 13:43:12 <shamoon> if the input was larger than the 2 outputs
547 2014-01-13 13:43:33 <shamoon> that would be a fee
548 2014-01-13 13:43:34 <sipa> fee = output value - input value
549 2014-01-13 13:43:36 <shamoon> or part of the fee
550 2014-01-13 13:43:41 <shamoon> err - that's what i meant
551 2014-01-13 13:43:46 <sipa> max coinbase output = subsidy + sum of fees paid by transactions in the same block
552 2014-01-13 13:43:47 <shamoon> if the 2 outputs were larger than the input
553 2014-01-13 13:44:15 <shamoon> so if i want to count the total fees of a block, i can either count the coinbase - subsidy OR add the outputs - inputs of each tx
554 2014-01-13 13:44:18 <shamoon> and it should be the same thing
555 2014-01-13 13:44:27 <CodeShark> you mean inputs > outputs
556 2014-01-13 13:44:28 <sipa> well
557 2014-01-13 13:44:36 <sipa> the coinbase isn't required to claim all fees
558 2014-01-13 13:44:37 <CodeShark> inputs < outputs -> tx is invalid
559 2014-01-13 13:44:43 <sipa> in which case the total money supply is decreased
560 2014-01-13 13:44:47 <CodeShark> except for coinbase
561 2014-01-13 13:45:14 <sipa> so depending on whether you want to count "fees paid by transactions in block" or "fees claimed by coinbase", that may or may not be the right way
562 2014-01-13 13:45:23 <sipa> miners would be silly of course not to claim all fees, but it's allowed
563 2014-01-13 13:45:27 <shamoon> so those 2 numbers can be different
564 2014-01-13 13:45:35 <shamoon> i wonder if they ever are
565 2014-01-13 13:45:57 <CodeShark> too bad I don't have my blockchain database up to date
566 2014-01-13 13:46:06 <CodeShark> would be an interesting query indeed
567 2014-01-13 13:47:09 <sipa> shamoon: see block 124724 in mainnet
568 2014-01-13 13:47:35 <shamoon> negative fees
569 2014-01-13 13:48:01 <shamoon> the subsidy claimed is only49.99999999
570 2014-01-13 13:48:13 <shamoon> but in theory, it could have been 50.01
571 2014-01-13 13:48:16 <shamoon> right?
572 2014-01-13 13:52:27 <sipa> correct
573 2014-01-13 13:53:25 <shamoon> so a total of -0.00999999 are now gone from existence
574 2014-01-13 13:53:41 <sipa> 0.01000001
575 2014-01-13 13:53:51 <shamoon> yup - you right
576 2014-01-13 13:54:01 <shamoon> so nodes spent 0.01000001 in fees
577 2014-01-13 13:54:06 <shamoon> that were never clained
578 2014-01-13 13:54:07 <shamoon> well
579 2014-01-13 13:54:09 <shamoon> they spent .01 in fees
580 2014-01-13 13:54:12 <shamoon> thta were never claimed
581 2014-01-13 13:54:29 <sipa> there's over 10 BTC of such lost fees/subsidy, btw
582 2014-01-13 13:54:31 <shamoon> and the miner only took 49.99999999 instead of the 50 he was allowed
583 2014-01-13 13:54:40 <shamoon> wow
584 2014-01-13 13:54:42 <shamoon> thanks sipa!
585 2014-01-13 13:55:09 <Happzz> if i broadcast a falsely signed tx, would it spread across the network or stopped beforehand?
586 2014-01-13 13:55:35 <sipa> Happzz: every node you send it to will disconnect you immediately, and ignore the transaction
587 2014-01-13 13:55:55 <Happzz> sipa how do scammers broadcast invalid transactions then
588 2014-01-13 13:56:04 <Happzz> other than double spending, that is
589 2014-01-13 13:56:11 <sipa> i have no knowledge of that happening
590 2014-01-13 13:56:36 <Happzz> i recall seeing transactions that were broadcasted but never confirmed before they were invalid that way or another
591 2014-01-13 13:56:43 <sipa> bugs, probably
592 2014-01-13 13:57:00 <sipa> and unlikely to be invalid signatures
593 2014-01-13 13:57:05 <Happzz> and double spending scammers just broadcast it twice, one time with more fees so it confirms faster?
594 2014-01-13 13:57:15 <sipa> there can be other things wrong with a transaction that don't make it immediately obvious they are invalid
595 2014-01-13 13:57:23 <Happzz> like what?
596 2014-01-13 13:57:43 <sipa> referencing a non-existing (or fully spent) input for example
597 2014-01-13 13:58:02 <Happzz> that would be broadcasted even though invalid?
598 2014-01-13 13:58:09 <Happzz> i'd assume the nodes check for that
599 2014-01-13 13:59:00 <sipa> not broadcasted
600 2014-01-13 13:59:05 <sipa> but not obviously invalid either
601 2014-01-13 13:59:17 <sipa> the inputs may be simply not yet known to the receiver
602 2014-01-13 13:59:36 <Happzz> ?
603 2014-01-13 13:59:36 <Happzz> i.e. unconfirmed inputs
604 2014-01-13 13:59:50 <sipa> not just unconfirmed
605 2014-01-13 13:59:54 <sipa> unknown
606 2014-01-13 14:00:40 <Happzz> okay.
607 2014-01-13 14:00:47 <Happzz> on another topic, how secure is an encrypted wallet.dat
608 2014-01-13 14:01:23 <Happzz> say an attacker gains access to it, how long would it take him to crack it
609 2014-01-13 14:02:03 <Happzz> assuming a 13+ chars password
610 2014-01-13 14:02:12 <sipa> depends how guessable it is
611 2014-01-13 14:02:22 <Happzz> it's not guessable. it'll need to be bruteforced
612 2014-01-13 14:02:35 <sipa> those are not mutually exclusive
613 2014-01-13 14:02:49 <Happzz> (just wondering if i should seriously consider cold storage or placing the wallet inside a truecrypt container or something)
614 2014-01-13 14:03:06 <sipa> it will take several milliseconds at least of CPU time per attempt
615 2014-01-13 14:04:12 <Happzz> and lowercase chars + numbers is 34 chars or so
616 2014-01-13 14:04:29 <Happzz> 34^13 ?
617 2014-01-13 14:04:32 <sipa> is it truly uniformly random 13 character password?
618 2014-01-13 14:04:38 <sipa> or did a human invent it?
619 2014-01-13 14:04:58 <Happzz> i did. it's not truely random. but it's random enough, it's not something you could come up with just like that
620 2014-01-13 14:05:32 <gribble> 66.1370169363
621 2014-01-13 14:05:32 <sipa> ;;calc 13*log(34)/log(2)
622 2014-01-13 14:05:56 <sipa> i don't think i can come up with that many bits of randomness
623 2014-01-13 14:06:11 <Happzz> english letters and numbers, there's not much to come up with
624 2014-01-13 14:06:25 <sipa> please don't make the mistake of thinking "it's not trivial, so the only way to crack is to try everything"
625 2014-01-13 14:06:35 <sipa> human are horribly bad at guessing how random something is
626 2014-01-13 14:06:49 <Happzz> how else can you crack it
627 2014-01-13 14:06:52 <scoofy> " it's not truely random. " <- dat
628 2014-01-13 14:07:02 <Happzz> it's either guessable or needs to be bruteforced
629 2014-01-13 14:07:05 <scoofy> the attacker can think with your mind
630 2014-01-13 14:07:06 <sipa> Happzz: by trying more common patterns first
631 2014-01-13 14:07:27 <scoofy> for example he tries password combinations with 5-8 chars and 2-3 numbers in the end first
632 2014-01-13 14:07:36 <scoofy> because that's a common scenario
633 2014-01-13 14:07:48 <Happzz> right, so i'll fall into this, but not nearly as obviously as what you said
634 2014-01-13 14:07:54 <Happzz> it's not THAT random then.
635 2014-01-13 14:08:02 <sipa> yeah, i'm not saying you have a bad password
636 2014-01-13 14:08:23 <sipa> just that immediately saying "so 34^13 attempts" is very unlikely to be even close to the truth
637 2014-01-13 14:08:35 <Happzz> yeah, i understand that now.
638 2014-01-13 14:09:17 <Happzz> i guess i actually do need to take better measures
639 2014-01-13 14:09:31 <scoofy> not unlikely.
640 2014-01-13 14:09:42 <Happzz> somehow i don't trust cold storage. i can easily imagine the piece of paper being lost
641 2014-01-13 14:10:46 <Apocalyptic> Happzz, cold storage does not mean piece of paper...
642 2014-01-13 14:10:57 <Happzz> it means offline
643 2014-01-13 14:11:02 <Apocalyptic> correct
644 2014-01-13 14:11:08 <Happzz> Apocalyptic i actually trust a flashdisk even less than a piece of paper :p
645 2014-01-13 14:11:19 <Happzz> shit tends to stop working by random
646 2014-01-13 14:11:19 <scoofy> disks fail
647 2014-01-13 14:11:25 <Apocalyptic> heh, so do I, use multiple flash disks
648 2014-01-13 14:11:38 <Happzz> Apocalyptic i don't trust them. i just don't.
649 2014-01-13 14:12:04 <CodeShark> the most tried and tested method for preserving information over long periods of time is engraving it into a piece of hard metal or stone
650 2014-01-13 14:12:06 <CodeShark> :)
651 2014-01-13 14:12:27 <Apocalyptic> if I have a wallet.dat on 3 usb keys let's say it's pretty improbable they would all malfunction
652 2014-01-13 14:12:29 <Happzz> qrcode engraved on a metal plate. nice1
653 2014-01-13 14:12:44 <scoofy> Apocalyptic: what if all 3 are stolen?
654 2014-01-13 14:12:47 <Happzz> Apocalyptic i had 4 of them fail just like that, all of the sudden. i don't trust them.
655 2014-01-13 14:12:59 <Apocalyptic> scoofy, each in different location of course
656 2014-01-13 14:13:13 <Apocalyptic> in bank-safe level security
657 2014-01-13 14:16:03 <michagogo> cloud|15:55:27 <sipa> Happzz: every node you send it to will disconnect you immediately, and ignore the transaction
658 2014-01-13 14:16:27 <michagogo> cloud|Is that for any transaction where the scriptSig fails to validate?
659 2014-01-13 14:28:20 <CodeShark> speaking of which, trying to figure out the easiest way to prevent bitcoind from disconnecting localhost
660 2014-01-13 14:28:35 <CodeShark> or to prevent it from disconnecting a particular endpoint (ip address)
661 2014-01-13 14:29:25 <michagogo> cloud|CodeShark: IIRC git master (or maybe a PR) has ban list manipulation
662 2014-01-13 14:29:27 <brisque> CodeShark: this looks promising https://github.com/bitcoin/bitcoin/pull/3403
663 2014-01-13 14:29:30 <michagogo> cloud|Including a whitelist
664 2014-01-13 14:30:30 <CodeShark> this isn't just "cannot be banned" - this is "if I'm running out of resources or am reaching the connection limit, disconnect other peers before disconnecting these"
665 2014-01-13 14:31:12 <michagogo> cloud|CodeShark: ah
666 2014-01-13 14:31:20 <CodeShark> additionally "If I've already reached my connection limit and any of these peers tries to connect, force disconnection of other peers to free up resources"
667 2014-01-13 14:31:21 <michagogo> cloud|Is addnode insufficient?
668 2014-01-13 14:31:32 <CodeShark> no, because we're talking inbound connections
669 2014-01-13 14:31:57 <michagogo> cloud|Ah
670 2014-01-13 14:32:15 <michagogo> cloud|So, "give this peer priority when connecting to me"?
671 2014-01-13 14:32:18 <CodeShark> yes
672 2014-01-13 14:32:26 <michagogo> cloud|Don't think that exists yet
673 2014-01-13 14:32:49 <michagogo> cloud|But as always, Patches Welcome (TM)
674 2014-01-13 16:12:52 <sipa> wumpus: currently, when payment a payment request in Qt, what happens if sending the payment fails?
675 2014-01-13 16:12:57 <sipa> does it get stored and retried?
676 2014-01-13 16:14:58 <dmanderson> anyone around familiar with the windows build process, and can give me pointers on leveldb
677 2014-01-13 16:15:52 <sipa> dmanderson: you can look at the gitian descriptors, to see which commands they use to build everything
678 2014-01-13 16:18:22 <wumpus> sipa: if anything fails, the payment should remain in the send list in the UI
679 2014-01-13 16:18:40 <dmanderson> thanks sipa
680 2014-01-13 16:18:52 <sipa> wumpus: but is it stored in the wallet?
681 2014-01-13 16:19:02 <wumpus> no, payment requests are never stored in the wallet at this point
682 2014-01-13 16:19:06 <sipa> bah
683 2014-01-13 16:19:29 <sipa> ok, thanks
684 2014-01-13 16:20:26 <twizt> what are u working on
685 2014-01-13 16:20:29 <wumpus> there is no way to store arbitrary data in the wallet from the UI (#3281 was a stab at that)
686 2014-01-13 16:20:37 <twizt> sipa*
687 2014-01-13 16:21:30 <sipa> wumpus: sure there is
688 2014-01-13 16:21:42 <sipa> wumpus: CWalletTxt has a map with custom data
689 2014-01-13 16:21:53 <wumpus> sipa: per transaction, sure
690 2014-01-13 16:22:02 <sipa> yes, this is data associated with a transaction
691 2014-01-13 16:22:08 <wumpus> sipa: but if the payment requests fails there is no transaction yet
692 2014-01-13 16:22:19 <sipa> wumpus: i don't care about that case
693 2014-01-13 16:22:33 <sipa> i care about failing to submit the payment, after the transaction is constructed
694 2014-01-13 16:22:46 <wumpus> ok, yes that would be possible already
695 2014-01-13 16:22:58 <wumpus> storing the payment request would also be nice for showing it in the transactions list
696 2014-01-13 16:23:18 <sipa> the BIP says "URL where a payment may be sent"; i consider that broken
697 2014-01-13 16:23:35 <sipa> if it's optional, the receiver can't rely on it, and needs an alternative anyway
698 2014-01-13 16:23:44 <sipa> which voids the need for having the payment in the first place
699 2014-01-13 16:24:29 <wumpus> yes,I agree it seems to make little sense to have it optional
700 2014-01-13 16:25:19 <sipa> imho, if a pyament url is present, a wallet shouldn't even broadcast a transaction on the p2p network, to reduce the risk that the transaction gets received but the payment isn't (though, admittedly, this cannot be relied upon in any case)
701 2014-01-13 16:26:36 <gavinandresen> Howdy everybody. I'm back home, kids are back in school, life is getting normal again. Well, aside from the normal craziness.
702 2014-01-13 16:26:43 <wumpus> welcome back gavinandresen
703 2014-01-13 16:26:50 <sipa> gavinandresen: wb!
704 2014-01-13 16:27:11 <gavinandresen> wumpus: thanks for fixing the OSX build today, works for me now.
705 2014-01-13 16:27:13 <michagogo> cloud|gavinandresen: Welcome back!