1 2014-08-28 00:01:10 <wumpus> Luke-Jr: we weaponized it! at least if we can believe the schizofrenic paranoid brigade on reddit: http://www.reddit.com/r/Bitcoin/comments/2eq8gi/getutxos_a_convenient_way_to_crash_bitcoind/ck26brz
2 2014-08-28 00:02:21 <Luke-Jr> wat
3 2014-08-28 00:02:24 <Luke-Jr> "technical debt"
4 2014-08-28 00:02:26 <Luke-Jr> O.o
5 2014-08-28 00:04:35 <brooss> Testing watch-only. It's really cool.
6 2014-08-28 00:04:40 <brooss> But once I add a watch-only address to a wallet there is no (easy) way to remove it?
7 2014-08-28 00:04:52 <sipa> there has never been a way to remove an address from a wallet
8 2014-08-28 00:04:54 <wumpus> Luke-Jr: we hoard undocumented behavior and put it into our technical debt gun!
9 2014-08-28 00:05:03 <jcorgan> gmaxwell: why do you waste time on r/bitcoin? it's like boiling the ocean
10 2014-08-28 00:05:16 <sipa> counting to 2^128 is probably more useful\
11 2014-08-28 00:06:29 <gmaxwell> jcorgan: I pretty much only go there if directly linked to things, probably not spent a total of 15 minutes there in the last month.
12 2014-08-28 00:08:59 <cfields> wumpus: when you were messing with the qt4 defines (the nasty list in the qt-linux gitian descriptor), was there anything in particular you found to be incompatible ?
13 2014-08-28 00:09:36 <cfields> i'm trying to decipher which build-time qt settings will actually affect the end-user's runtime, since we won't actually package qt
14 2014-08-28 00:09:57 <wumpus> cfields: I really don't remember, I think wisest would be to find out what settings debian is building with
15 2014-08-28 00:10:25 <cfields> good idea
16 2014-08-28 00:15:48 <wumpus> cfields: it's really cool how easy depends makes cross compiling
17 2014-08-28 00:16:01 <wumpus> talking of that, did jcorgan succeed in building for windows?
18 2014-08-28 00:17:31 <brooss> sipa, sure, but things are a bit different with watch-only addresses. Is a removeadress command of some sort a possibility in the future?
19 2014-08-28 00:17:34 <cfields> yea, only a single snag. there's a compile error in bdb with newer mingw (4.8ish), presumably because no one's bothered building the old bdb with it
20 2014-08-28 00:17:53 <sipa> brooss: i honestly don't feel like spending time thinking about that
21 2014-08-28 00:17:56 <cfields> i'll add a quick patch for that (it's a legitimate problem)
22 2014-08-28 00:18:02 <cfields> after that, it built fine for him
23 2014-08-28 00:20:20 <wumpus> great
24 2014-08-28 00:23:24 <dgenr8> since core is a very important wallet, who does care about it?
25 2014-08-28 00:24:38 <dgenr8> maybe should have phrased that differently...
26 2014-08-28 00:26:26 <wumpus> you do?
27 2014-08-28 00:26:33 <cfields> wumpus: aha, got a working build if you're still up for trying
28 2014-08-28 00:26:43 <dgenr8> god help us
29 2014-08-28 00:27:01 <wumpus> cfields: yes
30 2014-08-28 00:27:22 <cfields> sec, uploading
31 2014-08-28 00:28:32 <wumpus> I mean we all care about it in that it should not be horribly broken, leaking, or stealing coins, if that's what you mean...
32 2014-08-28 00:29:46 <dgenr8> it kinda leads the way
33 2014-08-28 00:30:43 <wumpus> in what?
34 2014-08-28 00:31:18 <sipa> you mean like every wallet out there uses deterministic generation, except core? :p
35 2014-08-28 00:32:27 <dgenr8> that's a frustrating example .. but i would say generally, it shows how to do things properly
36 2014-08-28 00:32:49 <sipa> fair enough
37 2014-08-28 00:33:54 <dgenr8> same with p2p behavior, much of the leading is just by example
38 2014-08-28 00:34:09 <wumpus> or in how they all store their keys in either a sane file, or in OS-specific secure key storage, except bitcoin core? :-)
39 2014-08-28 00:34:13 <cfields> wumpus: ugh, browser being stupid, sorry..
40 2014-08-28 00:36:28 <cfields> wumpus: see pm for link
41 2014-08-28 00:36:29 <wumpus> well indeed it should be very stable, hardly any changes also means that hardly anything can break
42 2014-08-28 00:39:43 <cfields> wumpus: that's 4.8 because it's where i started. moving to 4.6 next.
43 2014-08-28 00:40:02 <wumpus> cfields: works perfectly
44 2014-08-28 00:40:26 <dgenr8> armory for example requires it and i can't even name another non-SPV non-web wallet
45 2014-08-28 00:41:02 <wumpus> dgenr8: armory does not use bitcoin core's wallet
46 2014-08-28 00:41:16 <wumpus> it only uses it as node and runs its own wallet on top
47 2014-08-28 00:41:21 <dgenr8> right
48 2014-08-28 00:41:24 <dgenr8> sorry
49 2014-08-28 00:47:34 <cfields> wumpus: great, thanks for testing
50 2014-08-28 00:47:48 <sipa> ACTION zZzZ
51 2014-08-28 00:49:01 <cfields> sipa: nnite
52 2014-08-28 00:49:04 <wumpus> sipa: goodnight
53 2014-08-28 00:49:08 <sipa> you too!
54 2014-08-28 00:49:28 <cfields> wumpus: so we decided on 4.6 (whatever's in gitian) for now?
55 2014-08-28 00:50:27 <dgenr8> somebody should buy 2000 BTC, and pay a dev 400 BTC to work for wumpus for 1 year. good investment.
56 2014-08-28 00:51:18 <wumpus> cfields: well if everyone else thinks 4.8 is a better lower bound as even debian stable has that now, I'm fine with that too
57 2014-08-28 00:52:24 <cfields> wumpus: ok. 4.8 was easy enough. I'll see about 4.6. Maybe it'll be as easy as switching out the version strings and we can change as needed
58 2014-08-28 00:52:32 <cfields> wishful thinking, i suppose
59 2014-08-28 00:52:50 <wumpus> dgenr8: sure it would certainly help to have more devs working on bitcoin core
60 2014-08-28 00:55:46 <wumpus> we're always short-handed, people can scream what they want 'we need more testing' or 'we want this or that feature', but there's only so much people can do in a day
61 2014-08-28 00:56:22 <dgenr8> a unique property is the built-in vehicle for getting a return on your investment
62 2014-08-28 00:57:49 <dgenr8> Bitcoin Core Fellowship
63 2014-08-28 00:59:18 <wumpus> cfields: it's never that easy :)
64 2014-08-28 02:00:19 <Arnavion> https://github.com/bitcoin/bitcoin/commit/3da58b2 I think this merge broke master
65 2014-08-28 02:00:29 <Arnavion> Specifically this commit https://github.com/bitcoin/bitcoin/commit/6e5fd00
66 2014-08-28 02:00:39 <Arnavion> qt/splashscreen.cpp: In constructor 'SplashScreen::SplashScreen(const QPixmap&, Qt::WindowFlags, bool)':
67 2014-08-28 02:00:40 <Arnavion> QString versionText = QString("Version %1").arg(QString::fromStdString(FormatFullVersion()));
68 2014-08-28 02:00:40 <Arnavion> qt/splashscreen.cpp:33:98: error: 'FormatFullVersion' was not declared in this scope
69 2014-08-28 02:01:34 <Arnavion> ... but I presume the pull tester would've caught this so I guess I'm doing something wrong...
70 2014-08-28 02:08:59 <jgarzik> WFM
71 2014-08-28 02:09:01 <jgarzik> PASS: qt/test/test_bitcoin-qt
72 2014-08-28 02:09:01 <jgarzik> PASS: test/bitcoin-util-test.py
73 2014-08-28 02:09:01 <jgarzik> PASS: test/test_bitcoin
74 2014-08-28 02:09:02 <jgarzik> ============================================================================
75 2014-08-28 02:09:02 <jgarzik> Testsuite summary for Bitcoin Core 0.9.99
76 2014-08-28 02:09:04 <jgarzik> # TOTAL: 3
77 2014-08-28 02:09:08 <jgarzik> # PASS: 3
78 2014-08-28 02:09:11 <jgarzik> Arnavion, what platform+version?
79 2014-08-28 02:09:37 <Arnavion> openSUSE Factory x86_64
80 2014-08-28 02:09:56 <Arnavion> I really don't think that file is including version.h in any way...
81 2014-08-28 02:10:23 <Arnavion> I'm building with...
82 2014-08-28 02:10:25 <Arnavion> ./configure --with-gui=qt5 --disable-dependency-tracking --disable-maintainer-mode --disable-tests --disable-wallet --without-utils --without-daemon --without-miniupnpc --without-qrencode
83 2014-08-28 02:11:23 <BlueMatt> you shouldnt be able to build gui w/o wallet
84 2014-08-28 02:11:36 <Arnavion> Of course you can
85 2014-08-28 02:11:50 <Arnavion> It just shows a console and overview tab then
86 2014-08-28 02:12:40 <BlueMatt> oh, you didnt use to be able to
87 2014-08-28 02:14:36 <Arnavion> g++ -M | grep version.h only shows clientversion.h, not version.h
88 2014-08-28 02:14:40 <Arnavion> for that file
89 2014-08-28 02:15:30 <jgarzik> Arnavion, indeed, qt/splashscreen.cpp is missing #include "version.h"
90 2014-08-28 02:15:37 <Arnavion> Yes
91 2014-08-28 02:15:42 <Arnavion> So how did pull tester pass it?
92 2014-08-28 02:15:45 <jgarzik> Arnavion, does that fix things for you?
93 2014-08-28 02:15:53 <Arnavion> Let me try
94 2014-08-28 02:16:14 <jgarzik> make -sj19 && make -s check
95 2014-08-28 02:16:33 <Arnavion> make continues past that file now
96 2014-08-28 02:18:25 <Arnavion> Yes jgarzik, after adding that the build succeeds
97 2014-08-28 02:29:08 <jgarzik> Arnavion, want to do a pull request for it? I'm happy to handle it, if not.
98 2014-08-28 02:29:29 <Arnavion> No, go ahead
99 2014-08-28 02:29:35 <Arnavion> Thanks
100 2014-08-28 02:29:52 <jgarzik> Arnavion, Credit-to: ________________ ?
101 2014-08-28 02:30:04 <Arnavion> Uhh, "Arnavion" ?
102 2014-08-28 02:30:37 <Arnavion> I'm more concerned about why pull tester didn't catch it in laanwj's original PR
103 2014-08-28 02:31:17 <BlueMatt> it doesnt try all possible configurations
104 2014-08-28 02:31:28 <jgarzik> Arnavion, presumably for the same reason it builds successfully for me locally. Some $magic conditionally pulls in version.h on your platform.
105 2014-08-28 02:31:36 <Arnavion> This is normal qt though
106 2014-08-28 02:31:39 <Arnavion> Hmm
107 2014-08-28 02:31:50 <Arnavion> You could do a g++ -H to see what's pulling it in on yours
108 2014-08-28 02:32:16 <jgarzik> checking whether to build Bitcoin Core GUI... yes (Qt4)
109 2014-08-28 02:32:26 <jgarzik> Arnavion, ^^ what does your configure say? qt 4 or 5?
110 2014-08-28 02:32:35 <Arnavion> <Arnavion> ./configure --with-gui=qt5
111 2014-08-28 02:32:42 <Arnavion> But that shouldn't matter
112 2014-08-28 02:35:54 <Arnavion> In fact, seeing as version.h pulls in clientversion.h, you should probably just change the include of clientversion.h to version.h
113 2014-08-28 02:37:27 <jgarzik> Arnavion, no, it needs both.
114 2014-08-28 02:37:44 <Arnavion> https://github.com/bitcoin/bitcoin/blob/master/src/version.h#L7 ?
115 2014-08-28 02:38:13 <jgarzik> Arnavion, qt/splashscreen.cpp directly uses FormatFullVersion from version.h and COPYRIGHT_STR from clientversion.h. That they might or might not include each other is unrelated.
116 2014-08-28 02:38:29 <Arnavion> Oh, sure, from a quality perspective
117 2014-08-28 02:47:10 <Arnavion> Oh, got it
118 2014-08-28 02:47:25 <Arnavion> wallet.h pulls in version.h, so since I had --disable-wallet it didn't
119 2014-08-28 02:54:29 <jgarzik> Arnavion, ah
120 2014-08-28 02:54:46 <jgarzik> Arnavion, Nobody expects the Spanish Inquisition... or a --disable-wallet GUI
121 2014-08-28 02:54:49 <jgarzik> ;p
122 2014-08-28 02:54:51 <Arnavion> Heh
123 2014-08-28 02:55:05 <Arnavion> I just run a node on an aging laptop for kicks, so I have no use for the wallet
124 2014-08-28 03:45:16 <BlueMatt> someone wanna close https://github.com/bitcoin/bitcoin/issues/4146 ?
125 2014-08-28 03:46:10 <gmaxwell> BlueMatt: seems reasonsable, done
126 2014-08-28 03:59:00 <cfields> Arnavion: fyi, the new pull-tester would've caught that (i think). So hopefully it won't be a problem in the future
127 2014-08-28 04:01:02 <Luke-Jr> sigh, why is there still a 0.6.3 node running?
128 2014-08-28 04:34:56 <nullbyte> because software never dies
129 2014-08-28 04:54:18 <BlueMatt> cdecker1: cdecker_ your site having problem? http://bitcoinstats.com/network/dns-servers/
130 2014-08-28 05:01:05 <Gigastroop> heya, anyone in here play with block.io yet? thoughts?
131 2014-08-28 05:27:00 <BlueMatt> Gigastroop: I dont think anyone here would tuch such a thing
132 2014-08-28 05:27:11 <BlueMatt> touch*
133 2014-08-28 05:28:40 <Gigastroop> What's up BlueMatt we met the other night at the Geekdom meetup in San Francisco
134 2014-08-28 05:29:09 <Gigastroop> also BlueMatt we're adding multisig in a couple of weeks, so hopefully that will change any of that sentiment
135 2014-08-28 06:51:46 <djackallstar> Hello guys, my Bitcoin-Core crashes every time when I click this button:
136 2014-08-28 06:51:49 <djackallstar> http://i.imgur.com/f85mbNy.png
137 2014-08-28 06:52:09 <djackallstar> can anyone help me solve this issue?
138 2014-08-28 06:52:51 <djackallstar> please tell me what kind of info you need to know, thank you!
139 2014-08-28 06:53:37 <djackallstar> (If this is not where I should report this, just tell me too)
140 2014-08-28 06:54:09 <gmaxwell> djackallstar: please open an issue at https://github.com/bitcoin/bitcoin/issues/
141 2014-08-28 06:54:35 <gmaxwell> looks like a translation string missing a format specifier, I'm surprised the tools don't prevent that (or handle it gracefully!)
142 2014-08-28 06:55:32 <djackallstar> ok, I will try to do it now. Thank you gmaxwell!
143 2014-08-28 06:57:54 <wumpus> Arnavion: I don't understand why you get that breakage, it's not like I haven't tried that the GUI still works
144 2014-08-28 06:58:19 <Arnavion> wumpus: It only broke with --disable-wallet
145 2014-08-28 06:58:31 <wumpus> oh I see now, because of disable-wallet
146 2014-08-28 06:58:33 <Arnavion> Otherwise wallet.h would pull in version.h
147 2014-08-28 06:59:03 <wumpus> I builid with disable-wallet all the time, but not with GUI :/
148 2014-08-28 06:59:14 <Arnavion> Heh
149 2014-08-28 06:59:18 <wumpus> well the other buid is with gui with wallet
150 2014-08-28 07:00:49 <Arnavion> http://i.imgur.com/UGIO5ED.png It looks pretty cool too so I'm glad it exists
151 2014-08-28 07:00:52 <wumpus> anyhow thanks for reporting it
152 2014-08-28 07:01:11 <Arnavion> Sure, np
153 2014-08-28 07:01:54 <wumpus> djackallstar: the short term fix would be to change your language, or not click the button
154 2014-08-28 07:05:15 <djackallstar> wumpus: oh ok, I'm re-opening the client now to test if chaning language works.
155 2014-08-28 07:05:23 <wumpus> sometimes I think this localization is more trouble than it's worth
156 2014-08-28 07:05:46 <djackallstar> It takes so long to open on my crappy laptop
157 2014-08-28 07:06:06 <Arnavion> That looks like a format string with an outdated translation that has the wrong number of parameters
158 2014-08-28 07:06:36 <wumpus> Arnavion: yes, it is
159 2014-08-28 07:07:25 <wumpus> what is the "å½ä»¤åé¸é
" button?
160 2014-08-28 07:08:09 <djackallstar> "Commandline option", I guess, the client is still opening
161 2014-08-28 07:09:56 <Arnavion> <source>&Command-line options</source>
162 2014-08-28 07:09:59 <wumpus> seems like a need to write a script to parse XML and verify argument counts, wow that sounds like fun
163 2014-08-28 07:10:13 <Arnavion> Whoops, too slow
164 2014-08-28 07:11:23 <djackallstar> "Verifying Blocks"
165 2014-08-28 07:11:42 <djackallstar> It took me 3~4 days to sync the blockchain
166 2014-08-28 07:12:41 <wumpus> verifying it not syncing, this is a start-up integrity check
167 2014-08-28 07:13:32 <djackallstar> I see
168 2014-08-28 07:13:51 <djackallstar> Changing the lang to English works!
169 2014-08-28 07:14:21 <djackallstar> no crashes anymore YAY, thanks guys
170 2014-08-28 07:14:24 <wumpus> you can shorten the time by passing -checklevel=2 or even less
171 2014-08-28 07:14:59 <djackallstar> cool
172 2014-08-28 07:15:04 <wumpus> but that only make sense if you do a lot of restarts for development or such, normally you'd just keep the checks
173 2014-08-28 07:15:37 <djackallstar> gotcha
174 2014-08-28 07:15:51 <djackallstar> I will look into those command-line options for sure
175 2014-08-28 07:16:11 <wumpus> jgarzik: please be a little less terse when you open issue https://github.com/bitcoin/bitcoin/issues/4773
176 2014-08-28 07:16:19 <djackallstar> but now I will just let the client stay open all day :D
177 2014-08-28 07:17:23 <sipa> wumpus: when do you sleep...? :o
178 2014-08-28 07:17:47 <gmaxwell> wumpus: it's just a don't forget tracker. :P
179 2014-08-28 07:17:49 <BlueMatt> sipa: we talked about this, all the core devs are on meth 24/7 so they dont have to sleep...
180 2014-08-28 07:18:03 <gmaxwell> wumpus: I misread your comment as "be a little less tense" and was very confused.
181 2014-08-28 07:18:51 <wumpus> gmaxwell: it certainly is, but at least explain the problem
182 2014-08-28 07:18:57 <wumpus> gmaxwell: hah
183 2014-08-28 07:19:18 <wumpus> sipa: I didn't get much
184 2014-08-28 09:10:46 <rfreeman_w> what do you think about urandom versus random as entropy for getnewaddress ?
185 2014-08-28 09:12:49 <wumpus> in what context?
186 2014-08-28 09:16:38 <rfreeman_w> wumpus, well some people think urandom should not be used for important cryptographic seeding, other says it is not a concern. In context of seeding random numbers for generating private key for your address
187 2014-08-28 09:38:15 <gmaxwell> rfreeman_w: None of those things are used as entopy for getnewaddress.
188 2014-08-28 09:38:37 <gmaxwell> They use the internal random pool.
189 2014-08-28 09:38:58 <gmaxwell> Which is initilized from the system at start (and subsiquently updated with timing information, though not that it matters).
190 2014-08-28 11:26:46 <wumpus> djackallstar: looks like there are quite some messages with mismatched formatting characters, although just two in your language (see the pastebin link in https://github.com/bitcoin/bitcoin/pull/4776)
191 2014-08-28 11:37:40 <wumpus> submitted an announcement on transifex
192 2014-08-28 11:49:13 <wumpus> I like my bitcoin-qt in zh_TW, think I'm going to keep it this way :-)
193 2014-08-28 11:58:23 <wumpus> whoa, and I thought the bitcoin community was hostile http://gigaom.com/2014/08/27/chef-engineer-leaves-the-company-after-receiving-death-threats-from-its-open-source-community/
194 2014-08-28 13:33:49 <btcdrak> wow. not even r/bitcoin goes that far!
195 2014-08-28 13:34:27 <Luke-Jr> bitcointroll probably does, but I'm not sure we see it
196 2014-08-28 13:35:26 <btcdrak> http://crypto-comics.com/comic28.html
197 2014-08-28 13:35:57 <btcdrak> or an image for the paranoid: http://crypto-comics.com/comic28.png
198 2014-08-28 13:50:02 <jgarzik> RE threats, I had one threat of home invasion I considered serious enough to report to authorities
199 2014-08-28 13:50:21 <jgarzik> coming from the kernel, you had to had a tough skin
200 2014-08-28 13:50:58 <jgarzik> wumpus has not yet had to deal with (a) convicted murderers or (b) people threatening to commit suicide if you fail to accept their pull request
201 2014-08-28 13:51:24 <jgarzik> *had to have
202 2014-08-28 13:52:23 <wumpus> I hope that never happens either
203 2014-08-28 13:52:39 <jrick> hrm did I wake up too early or does GetBlocksToMaturity have an off by one?
204 2014-08-28 13:53:04 <jrick> doesn't seem to match what CheckInputs is checking
205 2014-08-28 13:54:29 <Luke-Jr> (b) people threatening to commit suicide if you fail to accept their pull request <-- someone taking code too seriously O.o
206 2014-08-28 13:59:52 <Luke-Jr> it's funny how once my seed node had 10 nodes queried, the security graph hasn't really changed its proportions as the number of nodes queried grows
207 2014-08-28 14:00:19 <Luke-Jr> still ~50% up-to-date, ~35% outdated, and ~2% testing
208 2014-08-28 14:18:42 <jgarzik> ACTION wrote this after one actual suicide: https://lkml.org/lkml/2012/7/27/321
209 2014-08-28 14:24:15 <jgarzik> jrick, git blame answers the question
210 2014-08-28 14:24:33 <jrick> ACTION looks
211 2014-08-28 14:26:27 <jrick> hmm
212 2014-08-28 14:27:36 <jrick> can't say I understand the rationale
213 2014-08-28 14:28:52 <jrick> also, if wallet wants to have its own rules then fine, but shoving that in main.cpp doesn't seem right
214 2014-08-28 14:30:07 <wumpus> jgarzik: painful, but well-written
215 2014-08-28 14:30:32 <jgarzik> jrick, main.cpp is where CMerkleTx class implementation lives
216 2014-08-28 14:30:58 <jgarzik> jrick, as grepping indicates, GetBlocksToMaturity is really a wallet concept, nothing at all to do with consensus
217 2014-08-28 14:31:11 <jgarzik> wumpus, thanks
218 2014-08-28 14:31:11 <wumpus> ACK on moving it to wallet
219 2014-08-28 14:31:13 <sipa> jrick: note that CWallet used to live in main.cpp too :)
220 2014-08-28 14:31:36 <wumpus> good catch
221 2014-08-28 14:31:37 <jrick> hah doesn't at all surprise me
222 2014-08-28 14:32:13 <jgarzik> commit bf3a20a6e8cafdf723ef101af078df303ea06fec outlines the rationale, as git blame indicates
223 2014-08-28 14:32:15 <sipa> pow/miner/coins/core/wallet/keystore/checkpoints/chainparams/... were all in main
224 2014-08-28 14:32:35 <sipa> or their predecessors at least
225 2014-08-28 14:33:18 <sipa> and yes, ack on moving wallet-only stuff to wallet obviously
226 2014-08-28 14:35:12 <jrick> jgarzik: why do you need to wait for the block to propagate? if a node didn't have it it would just be an orphan
227 2014-08-28 14:37:02 <sipa> jrick: a reorg of a few blocks deep could otherwise invalidate transactiins
228 2014-08-28 14:37:23 <sipa> the assumption is that under normal (no attack) situations a transaction can never go from valid to invalif
229 2014-08-28 14:37:29 <jrick> yes just like any other tx
230 2014-08-28 14:38:00 <sipa> no, spending a coinbase below maturity is invalid
231 2014-08-28 14:38:22 <sipa> normal spends do not have such a constraint
232 2014-08-28 14:38:46 <sipa> otherwise things could disappear from the mempool for example by just reorging
233 2014-08-28 14:39:17 <sipa> as the mempool is guaranteed to be a valid set of transactions on top of the current blockchain
234 2014-08-28 14:40:18 <sipa> for a normal transaction, in case of a reorg you move the disconnect parent tx back to the mempool and it remains valid
235 2014-08-28 14:40:31 <jrick> if there's a reorg then you're switching to a better chain tip, you shouldn't have issues with the coinbase you spent suddenly not being mature
236 2014-08-28 14:40:34 <sipa> for a coinbase spend, you can't move the coinbase to the mempool
237 2014-08-28 14:40:49 <sipa> the mempool would be invalid
238 2014-08-28 14:41:25 <jrick> during the switch yes, but after?
239 2014-08-28 14:41:47 <sipa> you'd have a mempool tx that spends a coinbase tx too early
240 2014-08-28 14:42:15 <sipa> and a wallet with nonexisting coins
241 2014-08-28 14:42:25 <jgarzik> yes that's the worse case
242 2014-08-28 14:42:44 <sipa> and in all likelyhood, after the next block they are valid again
243 2014-08-28 14:42:54 <jrick> if the bitcoind mempool must always be valid even in the middle of a reorg I understand, but I don't think access to it should be allowed during the reorg
244 2014-08-28 14:43:03 <jrick> and when the reorg if finished, it would be valid again
245 2014-08-28 14:43:08 <jgarzik> coins don't just become 0conf, they become invalid. absolute worst case, they are permanently invalid (if a different chain creates a different coinbase).
246 2014-08-28 14:43:13 <sipa> jrick: no
247 2014-08-28 14:43:24 <sipa> if you go from a longer to a shorter branch
248 2014-08-28 14:43:50 <sipa> it's always longer in terms of amount of work
249 2014-08-28 14:43:57 <sipa> but nit necessarily in terms of height
250 2014-08-28 14:44:00 <sipa> *not
251 2014-08-28 14:44:09 <jgarzik> chainA and chainB are not guaranteed to contain the same set of transactions
252 2014-08-28 14:44:20 <sipa> that's not actually relevant, jgarzik
253 2014-08-28 14:44:48 <jgarzik> not to coinbase maturity no.
254 2014-08-28 14:44:53 <sipa> because we're talking about a transaction output already 100 blocks deep
255 2014-08-28 14:45:27 <sipa> anyway, there used to be a way too large safety period of 20 blocks, so it was changed to 1
256 2014-08-28 14:50:48 <wumpus> it looks like CMerkleTx is only used by the wallet *except* a usage in blockToJSON in rpcblockchain :/
257 2014-08-28 14:51:02 <phedny> if I do a getrawtransaction, which results in the hex of a transaction; and I submit that transaction with sendrawtransaction, I expect to see code -27 "transaction already in block chain", however, for some transactions I get code -26, "18: bad-txns-inputs-spent"
258 2014-08-28 14:51:58 <phedny> in particular this happens with tx 223b0a5dbbdc274fb8e84b64da7bd91a3b0132f766c0ef67558f41a5780e8786 on testnet
259 2014-08-28 14:52:13 <Jouke> phedny: couldn't it be that some of the inputs of that transaction are allready spent?
260 2014-08-28 14:52:23 <jrick> sipa: thanks for the explanation, I'm looking at the chain switching code now
261 2014-08-28 14:52:32 <phedny> Jouke: if that were the case, I wouldn't expect the tx to be in the block chain
262 2014-08-28 14:53:18 <Jouke> Ah, no indeed :)
263 2014-08-28 14:53:19 <jgarzik> wumpus, wow, that rpcblockchain CMerkleTx use is completely cheesy
264 2014-08-28 14:53:30 <jgarzik> wumpus, just to get a block's depth in main chain???
265 2014-08-28 14:54:07 <wumpus> jgarzik: ...yep, that's all
266 2014-08-28 14:54:52 <jgarzik> wumpus, it has the flippin' CBlockIndex
267 2014-08-28 14:54:54 <jgarzik> // height of the entry in the chain. The genesis block has height 0
268 2014-08-28 14:54:54 <jgarzik> int nHeight;
269 2014-08-28 14:55:58 <wumpus> that does make it extremely silly
270 2014-08-28 14:56:46 <wumpus> chainActive.Height() - blockindex->nHeight + 1 would work just as well
271 2014-08-28 14:58:16 <wumpus> heh, there was guy here a while ago that had problem with # confirmations on some blocks returning -1 on the JSON, that turned out to be due to corruption of a block on disk
272 2014-08-28 15:01:25 <wumpus> ...but I can't think of any reason why it would be done this way
273 2014-08-28 15:10:18 <jgarzik> IMO just include changing blockToJSON as a preparatory commit in the CMerkleTx cleanup PR
274 2014-08-28 15:16:14 <phedny> sendrawtransaction finds a transaction to see whether a transaction is already in the block chain using CCoinsViewCache.GetCoins() at
275 2014-08-28 15:16:17 <phedny> https://github.com/bitcoin/bitcoin/blob/49f954f154e3576a6a8270e00ab95f52dd02c667/src/rpcrawtransaction.cpp#L737
276 2014-08-28 15:16:22 <phedny> now, the comments for CCoinsView.GetCoins() tells me it returns unspent transaction outputs: https://github.com/bitcoin/bitcoin/blob/790911ff0a659becd983afd5309b2c16401ba28d/src/coins.h#L278
277 2014-08-28 15:16:36 <phedny> does this mean that as soon as all outputs of a transaction are spent, issuing a sendrawtransaction of that transaction will return -26 instead of -27?
278 2014-08-28 15:24:12 <jgarzik> phedny, well, to be clear if "any" of the transaction's outputs are spent, the status will change
279 2014-08-28 15:24:36 <wumpus> there must be a better way to find out if a block is on the main chain
280 2014-08-28 15:25:06 <jrick> sipa: I see the total work being calculated, but as a function of the block's difficulty target. I suppose a miner could choose a harder difficulty before the required difficulty increases, but are there any other ways a reorg could result in a lower height?
281 2014-08-28 15:25:40 <jgarzik> wumpus, for the purposes of the RPC, it is asking confirmation count, which is a more narrow query.
282 2014-08-28 15:26:16 <jgarzik> phedny, if the transaction is confirmed, -27 is returned
283 2014-08-28 15:26:17 <wumpus> maybe chainActive.GetAncestor(blockindex->nHeight) == blockindex
284 2014-08-28 15:26:30 <phedny> jgarzik: that's what I expect, but that's not what happens
285 2014-08-28 15:26:32 <wumpus> if that's not true, the number of confirmations is -1
286 2014-08-28 15:26:53 <phedny> mark@cosmos:~/mip$ bitcoin/src/bitcoind -testnet sendrawtransaction `bitcoin/src/bitcoind -testnet getrawtransaction 223b0a5dbbdc274fb8e84b64da7bd91a3b0132f766c0ef67558f41a5780e8786`
287 2014-08-28 15:26:57 <phedny> error: {"code":-26,"message":"18: bad-txns-inputs-spent"}
288 2014-08-28 15:27:45 <wumpus> but there's probably a more direct way of asking...
289 2014-08-28 15:28:43 <jgarzik> wumpus, FindFork() is what "getblocks" uses
290 2014-08-28 15:29:54 <jgarzik> phedny, ah yes, -26 is returned if -some- but not all inputs are spent
291 2014-08-28 15:30:18 <jgarzik> phedny, i.e that transaction hash is not in the mempool, but another transaction spending some of its inputs is
292 2014-08-28 15:32:43 <wumpus> jgarzik: chainActive.FindFork(blockindex) == blockindex ?
293 2014-08-28 15:33:45 <wumpus> seems to work
294 2014-08-28 15:34:31 <jgarzik> wumpus, yep
295 2014-08-28 15:34:42 <jgarzik> wumpus, perhaps with a nice IsInMainChain wrapper or similar...
296 2014-08-28 15:34:43 <phedny> jgarzik: hmm, okay... given the scarce documentation (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list linking to the code for error codes), I assumed -27 to be returned in any case when a transaction is in the block chain
297 2014-08-28 15:35:03 <jgarzik> phedny, apparently not
298 2014-08-28 15:35:10 <phedny> indeed :)
299 2014-08-28 15:35:27 <phedny> so the question: should documentation be improved or is the current behavior undesired?
300 2014-08-28 15:36:36 <jgarzik> phedny, I wouldn't want to close off the ability for someone to distinguish between those cases. And usefully, that reaches the conclusion "update the docs, don't break compat"
301 2014-08-28 15:37:34 <wumpus> this is desired behavior, please don't change it around again
302 2014-08-28 15:37:48 <wumpus> improving documentation is always welcome of course
303 2014-08-28 15:40:51 <wumpus> in general, if all txouts is spent we can't even know anymore whether the transaction is in the chain
304 2014-08-28 15:41:41 <wumpus> (unless txindex is enabled, but using that would be mixing concerns in a bad way)
305 2014-08-28 15:43:42 <phedny> I see
306 2014-08-28 15:53:43 <Elcuim> anyone have tried to make a own ATM here?
307 2014-08-28 15:55:30 <Eliel> Elcuim: while that is an interesting project in itself, it's off topic on this channel. This channel is for development disussion of Bitcoin Core.
308 2014-08-28 16:02:15 <Elcuim> Eliel, sorry and thanks for the clarification. yow know another room for bitcoin related projects ?
309 2014-08-28 16:03:57 <Eliel> unfortunately, I don't know of a general channel like that. You could perhaps ask in #bitcoin.
310 2014-08-28 16:05:36 <Elcuim> Eliel, thanks!
311 2014-08-28 16:08:59 <wumpus> this channel is not only about bitcoin core, in general discussing technical details of the bitcoin system is on topic here... I agree that building ATMs doesn't really fit into the topic though
312 2014-08-28 16:14:51 <nsh> is the previous block header hashed twice -- sha356(sha356(prevBlockHeader)) -- in mining or once?
313 2014-08-28 16:15:02 <nsh> *256
314 2014-08-28 16:15:33 <nsh> twice.
315 2014-08-28 16:15:38 <Luke-Jr> sha256d(header) = sha256(sha256(header))
316 2014-08-28 16:15:47 <nsh> ty
317 2014-08-28 17:01:54 <nsh> Luke-Jr, further question (relaying for someone) "everybody says that the output from SHA-256 is big-endian, but the value is used "as is" as the prevBlockHash, which everybody says is little-endian data. and people even reverse it on the web, thinking that it should be presented big-endian!"
318 2014-08-28 17:02:36 <Luke-Jr> ⦠why relay? tell them to ask themselves
319 2014-08-28 17:03:05 <Luke-Jr> in any case, trial and error is the easiest way to get that right
320 2014-08-28 17:03:15 <jgarzik> nsh, the hash is an opaque value
321 2014-08-28 17:03:17 <Luke-Jr> trying to explain it or be explained to, is just asking for disaster
322 2014-08-28 17:03:23 <jrick> shas don't have endianness
323 2014-08-28 17:03:35 <jgarzik> nsh, when displayed as a hex string, bitcoin does some idiotic byte and word swapping
324 2014-08-28 17:03:39 <Luke-Jr> jrick: sure they do
325 2014-08-28 17:04:43 <Luke-Jr> jrick: it's just always big endian because that's required ;)
326 2014-08-28 17:04:45 <jrick> Luke-Jr: you can interpret an integer from it, with the bytes in big or little endian order, but the sha itself doesn't have an endianness
327 2014-08-28 17:05:13 <Luke-Jr> jrick: SHA256 works in 32-bit integers, and requires translating it from/to character data in big endian
328 2014-08-28 17:06:19 <jrick> right
329 2014-08-28 17:07:11 <Luke-Jr> nsh: also keep in mind getwork's data is not the same as the block header itself
330 2014-08-28 17:08:09 <nsh> ACTION nods
331 2014-08-28 17:15:04 <jgarzik> Luke-Jr, huh? no.
332 2014-08-28 17:15:15 <jgarzik> Luke-Jr, sha256 produces opaque bytestream
333 2014-08-28 17:15:29 <jrick> ^
334 2014-08-28 17:15:37 <jgarzik> Luke-Jr, if you want to squash it into a data type, that is a notion added atop the algo
335 2014-08-28 17:15:42 <Luke-Jr> jgarzik: sure, it's opaque, but that's how it works
336 2014-08-28 17:16:07 <jgarzik> Luke-Jr, the implementation is irrelevant. it's a black box. the same output is achieved from the same input, no matter the platform.
337 2014-08-28 17:16:24 <Luke-Jr> it's still silly to interpret it as little endian later
338 2014-08-28 17:16:52 <jgarzik> Luke-Jr, you may cast opaque data to whatever endian you wish
339 2014-08-28 17:17:09 <jgarzik> Luke-Jr, to enable 256 integers, it -had- to be cast to little endian
340 2014-08-28 17:17:18 <jgarzik> we are an LE platform
341 2014-08-28 17:17:19 <Luke-Jr> O.o
342 2014-08-28 17:17:28 <Luke-Jr> x86 is a LE platform. not everything is x86.
343 2014-08-28 17:17:42 <jgarzik> irrelevant
344 2014-08-28 17:17:51 <jgarzik> bitcoin is an LE codebase
345 2014-08-28 17:17:58 <Luke-Jr> that's one of its flaws, yes
346 2014-08-28 17:18:23 <jgarzik> therefore... it's not silly to interpret opaque 256 bits as little endian later
347 2014-08-28 17:18:39 <jgarzik> we use it for numeric comparison
348 2014-08-28 17:19:59 <jgarzik> That said, there are plenty of gratuitous uses of opaque hash as uint256 where an opaque type would be more appropriate.
349 2014-08-28 17:27:46 <cfields> yikes. Agreed with Luke-Jr big-time on that one.
350 2014-08-28 17:27:52 <cfields> that's weird to say :)
351 2014-08-28 17:30:12 <cfields> gavinandresen: i guess you got the code-signing worked out? I forgot to send you a mail last night :\
352 2014-08-28 17:31:53 <gavinandresen> cfields: I think so. The rc1 .dmg was codesigned on OSX 10.8 instead of 10.9, but Iâll sign final release on 10.9 so weâre compatible with 10.10.
353 2014-08-28 17:33:03 <cfields> gavinandresen: ok. Would it help to push in the split-signing stuff I worked on a while back? I'm not exactly sure what your procedure is now, so I dunno how painful it is for you in its current form
354 2014-08-28 17:34:00 <gavinandresen> cfields: remind me what âthe split-signing stuffâ is all about?
355 2014-08-28 17:34:37 <gavinandresen> cfields: ⦠starting with: âeverbody agrees on a gitian-built thing-a-ma-bobberâ
356 2014-08-28 17:35:04 <cfields> gavinandresen: gitian spits out a tarball with generated scripts, you run it on your macbook and it outputs a split signature. back into a separate gitian descriptor that recombobulates
357 2014-08-28 17:35:18 <gavinandresen> what is a split signature?
358 2014-08-28 17:36:07 <cfields> er.. detached signature. Basically a binary diff of unsigned->signed files
359 2014-08-28 17:36:20 <gavinandresen> I didnât think gatekeeper allowed detached signatures.
360 2014-08-28 17:36:27 <gavinandresen> Happy to be wrong....
361 2014-08-28 17:37:15 <cfields> it doesn't. the final step in the chain above is for gitian to re-combine them
362 2014-08-28 17:37:33 <cfields> gavinandresen: ok, let's back up. What would be your ideal signing procedure?
363 2014-08-28 17:38:56 <gavinandresen> cfields: well, IDEALLY weâd be able to sign the package, and leave the .app alone. But gatekeeper doesnât allow that. We have to sign the binaries inside the .app
364 2014-08-28 17:39:05 <gavinandresen> ⦠sign the .dmg package....
365 2014-08-28 17:39:28 <cfields> wait, the dmg has to be signed now as well?
366 2014-08-28 17:39:35 <gavinandresen> cfields: no, dmg canât be signed at all
367 2014-08-28 17:40:09 <gavinandresen> The goal would be: you download a .dmg. Install the .app. Then can easily check to make sure the .app matches the gitian-compiled .app
368 2014-08-28 17:40:30 <gavinandresen> Since code-signing mucks with the .app, we canât have that....
369 2014-08-28 17:41:12 <cfields> gavinandresen: we can get close though. The code-signing mucks with the app in a way that we can predict exactly (except for the actual signature content obviously, but we know its size)
370 2014-08-28 17:41:52 <gavinandresen> cfields: but I donât see how detached signatures help much with that. Either we strip the code-signing segments from the executables, or we strip separate signatures from the .app bundle. Same difference, pretty much
371 2014-08-28 17:42:05 <cfields> so we can either: detach the signature and let users re-create the final binary from the detached sig + the untampered binary, or give them a script to remove the sig to prove that it matches the original
372 2014-08-28 17:43:22 <gavinandresen> right, both are painful. Does OSX ship with tools to delete segments from binaries?
373 2014-08-28 17:43:39 <cfields> i've written a set of scripts to handle both of those cases
374 2014-08-28 17:44:02 <cfields> but no, not natively
375 2014-08-28 17:44:33 <gavinandresen> bah. If you have to trust an executable tool that you download from us then thatâs no good
376 2014-08-28 17:45:06 <gavinandresen> what does the script that strips signatures need? XCode tools?
377 2014-08-28 17:45:16 <cfields> nope, just dd
378 2014-08-28 17:45:30 <cfields> gavinandresen: the codesigning boils down to nothing more than replacing a zero'd section of the binary with a signature
379 2014-08-28 17:45:55 <gavinandresen> right, but it seems simpler to me to ship the codesigned binaries and let people strip
380 2014-08-28 17:46:14 <gavinandresen> rather than shipping codesigned binaries plus detached signatures and asking people to re-create....
381 2014-08-28 17:46:57 <cfields> no... i was suggesting that we let gitian do the re-creating. so that there's really no need to users to audit
382 2014-08-28 17:47:17 <gavinandresen> Then Iâm confused, I donât understand how detached signatures buy us anything.
383 2014-08-28 17:47:42 <cfields> we build the binary, copy it, and codesign it. diff em. You now have a detached sig...
384 2014-08-28 17:48:10 <cfields> feed them both into gitian. Let it combine em. It's now dead-simple to see exactly how the binary was altered in order to create the final product.
385 2014-08-28 17:49:29 <gavinandresen> So: everybody builds a .app. I (or somebody) codesigns, and packages into a .dmg.
386 2014-08-28 17:51:01 <gavinandresen> Everybody can diff their gitian-built .app and the .app in the .dmg, and it is dead-simple to see that the only code segments that changed are the code-signing segmentsâ¦. I donât see how feeding something into gitian helps
387 2014-08-28 17:51:18 <cfields> Correct. You code-sign, and end up with a tiny signature that can be added as a gitian input. You share it. Everyone rebuilds with the new input to build a final deterministic dmg.
388 2014-08-28 17:52:15 <cfields> gavinandresen: because your way, the dmg isn't deterministic. gitian output is.
389 2014-08-28 17:52:35 <cfields> this way nobody has to manually inspect anything, as long as the process itself is trusted
390 2014-08-28 17:53:17 <gavinandresen> so everybody builds, waits for me (or somebody), then builds againâ¦. ok, I see. Sounds fragile, but maybe it is the best we can do.
391 2014-08-28 17:54:06 <cfields> Fragile indeed. I'm really not sold on it at all, just wanted to make sure we were on the same page
392 2014-08-28 17:54:07 <gavinandresen> I suppose if the signer is always the first builder the process would be pretty smooth
393 2014-08-28 17:54:21 <cfields> So now that we are, if you think it's unnecessary, that's fine by me
394 2014-08-28 17:55:45 <cfields> gavinandresen: ideally we could check the signature into git, so it's 100% visibile (it's very small). But that would break things since git revisions alter the final binary. Circular problem there.
395 2014-08-28 17:56:21 <gavinandresen> cfields: right. signatures could go into gitian.sigs, though
396 2014-08-28 17:56:38 <cfields> gavinandresen: aha, that'd be perfect.
397 2014-08-28 17:57:50 <gavinandresen> ok, lets try it for the 0.10 release.
398 2014-08-28 17:58:18 <jtimon_> #4555 #4694 and #4695 can be labelled "TX scripts"
399 2014-08-28 17:58:42 <Luke-Jr> it would be nice if the signer was irrelevant; can we have the gitian signatures be both pre-signed and signed versions easily?
400 2014-08-28 17:59:07 <cfields> gavinandresen: ok. So does what we have now work for .9.3?
401 2014-08-28 18:00:10 <cfields> Luke-Jr: not sure what you're asking
402 2014-08-28 18:00:25 <cfields> gavinandresen: to clarify, i mean for signing on 10.9
403 2014-08-28 18:01:49 <Luke-Jr> cfields: ideally, binaries could be signed by N different parties, and all verifiable with the gitian signatures. I get the problem with that in general is then we trust the signature-stripping tool - but it would be nice to still have the shasums needed to verify a signature-stripped binary in addition to the shasums for the signed binary
404 2014-08-28 18:02:26 <Luke-Jr> so if the binary is signed by someone other than <central main signer>, the signature can be stripped and the other shasum used to verify it
405 2014-08-28 18:02:42 <cfields> Luke-Jr: oh sure, we can just output both versions
406 2014-08-28 18:03:34 <gavinandresen> cfields: I think so, but Iâm busy with something higher priority so havenât had a chance to make 100% sure today
407 2014-08-28 18:04:04 <cfields> gavinandresen: no problem, just let me know if you need something else
408 2014-08-28 18:05:15 <cfields> Luke-Jr: the signature stripping is really just something like 'dd if=signed of=detatched skip=x count=y'
409 2014-08-28 18:06:43 <Luke-Jr> cfields: right, I'd be fine with a verification of stripped bins only - I'm just saying let's not give that option up, if we want to verify signed ones too
410 2014-08-28 18:06:52 <cfields> i suppose it could be overwriting with a malicious payload (and corrected checksums) though
411 2014-08-28 18:06:54 <cfields> sure
412 2014-08-28 18:23:20 <ebfull> sipa and anyone else curious:
413 2014-08-28 18:23:26 <ebfull> here is how i replicate my watchonly wallet bug
414 2014-08-28 18:23:36 <ebfull> ./bitcoin-cli importaddress 1EhCfqVEckVmhrdQ9rczfTrvj3WgRwUrxs test
415 2014-08-28 18:23:43 <ebfull> (random address i plucked off of blockchain)
416 2014-08-28 18:24:28 <ebfull> after rescan if you try to do listtransactions, all of the transactions are receives even though value is being sent as well
417 2014-08-28 18:25:00 <ebfull> though... maybe this is just a weird thing to account for, but if you try to do gettransaction on any of the transactions you don't get the information you need to disambiguate it
418 2014-08-28 18:25:48 <ebfull> also, if you do `./bitcoin-cli getbalance test 1 true` the balance it shows is 30.33727009 (for me)
419 2014-08-28 18:26:10 <ebfull> that's definitely not right, blockchain.info shows the final balance to be 1.70971328
420 2014-08-28 18:27:26 <ebfull> i think it's all part of a related problem
421 2014-08-28 18:28:12 <Luke-Jr> ebfull: "I told you so"?
422 2014-08-28 18:28:32 <gavinandresen> ebfull: youâre confusing accounts with addresses; âtestâ account gets credited with transactions to 1EhCfq⦠But it will only get debited if you use sendfrom to send funds.
423 2014-08-28 18:29:16 <gavinandresen> Perhaps the documentation for watchonly needs to make it clear that it is only good for watching for incoming transactions.
424 2014-08-28 18:30:08 <ebfull> watchonly isn't that useful if it's only for incoming transactions. it's trivial to get bitcoind to report not only the correct balance but also to list out the sends and receives
425 2014-08-28 18:30:25 <gavinandresen> ebfull: okey dokey
426 2014-08-28 18:31:26 <Luke-Jr> ebfull: addresses don't send, ever. therefore they also don't have balances. you're confusing an address with a wallet, thanks to blockchain.info's misinformation.
427 2014-08-28 18:32:52 <ebfull> so what exactly is getbalance supposed to do for watchonly wallets?
428 2014-08-28 18:33:26 <Luke-Jr> ebfull: watchonly wallets require importing an address for every single key in the wallet
429 2014-08-28 18:33:44 <ebfull> yeah i have one key, checkmate?
430 2014-08-28 18:33:46 <Luke-Jr> ebfull: and seems fundamentally incompatible with bitcoind's accounting feature
431 2014-08-28 18:33:57 <Luke-Jr> ebfull: so don't use "test"
432 2014-08-28 18:34:33 <Luke-Jr> ebfull: a wallet with one key is kinda broken-by-design though
433 2014-08-28 18:34:41 <ebfull> that's a separate concern though
434 2014-08-28 18:34:47 <Luke-Jr> yes, separate, I agree
435 2014-08-28 18:35:14 <Luke-Jr> ebfull: if you use '*' instead of 'test' in listtransactions, I think you will get what you want
436 2014-08-28 18:35:53 <Luke-Jr> (and note that bitcoind still only supports one wallet, so you can't mix multiple watchonly wallets in itâ¦)
437 2014-08-28 18:36:00 <Luke-Jr> (or watchonly + real)
438 2014-08-28 18:36:24 <ebfull> yeah actually that does print out what i want..
439 2014-08-28 18:38:23 <ebfull> cool thanks
440 2014-08-28 19:03:44 <nsh> there's not a getblock equivalent in binary, is there?
441 2014-08-28 20:06:38 <jgarzik> http://www.vox.com/2014/8/28/6079661/the-second-man-to-use-bitcoin-is-legally-dead-and-his-body-is-being
442 2014-08-28 20:07:41 <BlueMatt> :(
443 2014-08-28 20:16:46 <skinnkavaj> RIP Hal finney
444 2014-08-28 20:16:59 <sturles> :-(
445 2014-08-28 20:19:16 <sipa> :(
446 2014-08-28 20:22:05 <Dr-G> rip
447 2014-08-28 20:23:38 <sipa> jrick: work is defined as how hard a block was to find, which is only determined by the target (=the difficulty); the chain with the most work wins
448 2014-08-28 20:23:54 <sipa> jrick: in almost every case, that is also the longer chain, but not necessarily
449 2014-08-28 20:24:01 <jrick> sipa: yep
450 2014-08-28 20:24:17 <sipa> in particular when a reorg crosses a retarget, it is possible for a shorter chain to win
451 2014-08-28 20:24:40 <jrick> masochist miners :p
452 2014-08-28 20:25:07 <sipa> which could lead to a matured coin to become immature, and thus illegal to spend
453 2014-08-28 20:25:13 <jrick> right
454 2014-08-28 20:25:38 <sipa> it's all pretty unlikely, and the 1 extra confirmation is probably still overkill
455 2014-08-28 20:25:52 <sipa> still, waiting an extra 10 minutes after a day shouldn't mattet
456 2014-08-28 20:33:32 <jrick> A comment explaining that in the source (rather than needing to find the relevant commit with git blame) would be nice
457 2014-08-28 20:33:47 <jrick> but moving it out of main.cpp helps
458 2014-08-28 20:34:26 <sipa> agree
459 2014-08-28 20:50:25 <BlueMatt> all of our headers are wrong, we use MIT/Expat, not MIT/X11 (which has an extra clause)......
460 2014-08-28 20:50:38 <sipa> heh
461 2014-08-28 20:50:58 <sipa> what defines which license we use, if not those notices?
462 2014-08-28 20:51:18 <BlueMatt> the LICENSE file is MIT/Expat, all our headers are MIT/X11
463 2014-08-28 20:51:23 <BlueMatt> so...I dunno, guess its not clear
464 2014-08-28 20:51:35 <BlueMatt> we could change the license to MIT/X11, which has extra restrictions if we want to be safe
465 2014-08-28 20:52:29 <sipa> does that involve asking permission from all former (major) contributors...?
466 2014-08-28 20:52:34 <sipa> ... including satoshi?
467 2014-08-28 20:53:14 <BlueMatt> its not clear...my guess is that we are free to relicense new releases under more restrictive licenses and old releases are still under whatever they were put out with
468 2014-08-28 20:53:35 <BlueMatt> (the X11 license has the extra clause "Except as contained in this notice, the name(s) of the above copyright holders shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization.")
469 2014-08-28 21:01:50 <BlueMatt> gmaxwell: do you (or does anyone) have stats on orphans by pool?
470 2014-08-28 21:03:08 <BlueMatt> does anyone have a poc for f2pool?
471 2014-08-28 21:03:22 <BlueMatt> gavinandresen: ^ ?
472 2014-08-28 22:23:18 <dgenr8> ;;seen hearn
473 2014-08-28 22:23:18 <gribble> hearn was last seen in #bitcoin-dev 1 day, 5 hours, 4 minutes, and 53 seconds ago: <hearn> i guess you must have been waiting for the commit before deciding to implement it
474 2014-08-28 23:17:24 <BlueMatt> petertodd: any reason why CTransaction().stream_deserialize(io.BytesIO(transaction_data)) wouldnt work?
475 2014-08-28 23:17:31 <BlueMatt> (bitcoin.core.serialize.SerializationTruncationError: Asked to read 25 bytes, but only got 11)
476 2014-08-28 23:21:58 <petertodd> BlueMatt: what's transaction_data?
477 2014-08-28 23:22:43 <petertodd> BlueMatt: oh, and it should be CTransaction.stream_deserialize - stream_deserialize() is a classmethod, not an instancemethod
478 2014-08-28 23:25:19 <petertodd> BlueMatt: also, you can just use CTransaction.deserialize() if you have a bytes array - the underlying Serializable() class provides (de)serialize() for use with bytes(arrays)
479 2014-08-28 23:28:27 <BlueMatt> hmm, yea, its reading bytes off the network and then still gets that with CTransaction.deserialize(bytes)
480 2014-08-28 23:29:24 <petertodd> BlueMatt: SerializationTruncationError indicates what you'd expect
481 2014-08-28 23:29:59 <BlueMatt> indeed, though I dont see how I could get that :(
482 2014-08-28 23:30:48 <petertodd> BlueMatt: does bitcoind decdoe the transaction correctly? got a dumb of it that I can look at?
483 2014-08-28 23:30:51 <petertodd> *dump
484 2014-08-28 23:30:57 <BlueMatt> working on it
485 2014-08-28 23:33:59 <BlueMatt> petertodd: my bad, called the socket wrong :(
486 2014-08-28 23:34:05 <petertodd> ah
487 2014-08-28 23:34:08 <petertodd> what are you doing anyway?
488 2014-08-28 23:35:16 <BlueMatt> relay node client in python
489 2014-08-28 23:35:50 <petertodd> oh cool! with the p2p protocol?
490 2014-08-28 23:36:54 <BlueMatt> hmm? its the same thing as the java client, ie it just translates p2p protocol into relay node protocol and sits between relay network and bitcoind
491 2014-08-28 23:37:47 <petertodd> right, so you are talking the p2p protocol to bitcoind - I haven't done much work on the bitcoin.net and bitcoin.message modules myself
492 2014-08-28 23:38:58 <petertodd> FWIW if you didn't see it, I've released v0.2.0 w/ immutable-by-default objects - you probably want to be using that
493 2014-08-28 23:41:38 <BlueMatt> petertodd: well, I havent touched p2p yet, just getting blocks first
494 2014-08-28 23:42:00 <BlueMatt> no idea how I'm gonna do that part yet...
495 2014-08-28 23:42:33 <petertodd> BlueMatt: cool, yeah, you'll find there isn't much code for that yet, just the data structures.
496 2014-08-28 23:44:05 <BlueMatt> petertodd: hmm, well the only thing I need to be able to do is dump data on the socket...I may even remove the python-bitcoinlib dep and make it optional to allow printing things like hash of recv'd messages
497 2014-08-28 23:45:11 <petertodd> BlueMatt: if you can get away with that, all the better
498 2014-08-28 23:46:47 <roasbeef> BlueMatt: if you're writing this for compatibility with p2pool you might want to consider using Twisted for the networking portion, that way you can hook right into the main event loop
499 2014-08-28 23:47:22 <BlueMatt> roasbeef: forrestv said (and I agree), that it should be able to be called with a simple function call and let it spin up its own threads
500 2014-08-28 23:47:27 <BlueMatt> roasbeef: in that model, doesnt really matter
501 2014-08-28 23:47:36 <BlueMatt> that way its also easy to pull into its own program
502 2014-08-28 23:50:49 <gmaxwell> BlueMatt: hm. what code is p2pool using to speak the bitcoin p2p protocol?
503 2014-08-28 23:51:07 <petertodd> gmaxwell: p2pool uses their own custom bitcoin library basically
504 2014-08-28 23:52:29 <petertodd> gmaxwell: it's fair to say one of the failings of python-bitcoinlib to date is no-one has added it to an existing project, save for ngcccbase, which uses two python bitcoin libraries simultaneously :/
505 2014-08-28 23:54:07 <sipa> ACTION would consider it to write a scenario-replaying-network-interaction-tester-tool to replace the bitcoin comparison tool
506 2014-08-28 23:54:22 <petertodd> sipa: +1
507 2014-08-28 23:54:34 <sipa> but if BlueMatt can fix the comparison tool to support headersfirst, that would clearly get priority