1 2013-08-17 04:13:02 <warren> Luke-Jr: where did you commit that?
2 2013-08-17 04:53:39 <warren> Luke-Jr: https://github.com/wtogami/bitcoin/commits/btc09tested here is the subset of 0.9 patches that we've shipped in litecoin-0.8.3.7 and tested for 1-2 months in production. (There were a few more, but I removed the non-bugfix patches from this branch.)
3 2013-08-17 05:01:34 <warren> Luke-Jr: https://github.com/litecoin-project/litecoin/commits/exp-btc09backports entire set of bitcoin-0.9 patches we shipped in litecoin-0.8.3.7 (superset of the previous branch)
4 2013-08-17 07:42:56 <Luke-Jr> warren: https://gitorious.org/bitcoin/bitcoind-stable/
5 2013-08-17 07:43:39 <Luke-Jr> warren: I suppose I care about what you put in litecoin as a FYI, but it is entirely irrelevant for the stable branches. They have a policy to only include fixes that are merged to master.
6 2013-08-17 07:44:58 <warren> Luke-Jr: all of those commits I linked to were merged to master.
7 2013-08-17 07:45:35 <warren> Luke-Jr: Litecoin tested them in production for 2 months+, which should hopefully improve confidence in their correctness.
8 2013-08-17 07:45:52 <Luke-Jr> warren: I guess I was assuming it included clearly-non-fixes like coin control
9 2013-08-17 07:46:03 <warren> Luke-Jr: coin control is not among these patches
10 2013-08-17 07:47:30 <warren> Luke-Jr: please don't assume? I made the first branch explicitly for the purpose of guidance for a potential bitcoin-0.8.4. The second branch is the distilled bitcoin master commits that we actually tested and shipped which is a superset of the first branch.
11 2013-08-17 07:49:07 <warren> Luke-Jr: so your 0.8.4 is unofficial as far as bitcoin.org is concerned?
12 2013-08-17 07:49:29 <Luke-Jr> it's not 0.8.4 until it's tagged
13 2013-08-17 07:49:33 <warren> oh
14 2013-08-17 07:52:21 <warren> Luke-Jr: though this is meant to become bitcoin.org 0.8.4? yesterday folks here said there was no need for 0.8.4
15 2013-08-17 07:53:11 <Luke-Jr> warren: there isn't really a need yet.
16 2013-08-17 07:53:28 <warren> ok
17 2013-08-17 07:53:41 <warren> Luke-Jr: did you pull everything in my suggested branch?
18 2013-08-17 07:53:44 <Luke-Jr> usually I'd tag it when 0.9 is released
19 2013-08-17 07:53:47 <Luke-Jr> warren: no
20 2013-08-17 07:54:05 <warren> the benefit of my branch is that it is vigorously tested
21 2013-08-17 07:54:53 <warren> although I'm aware of one minor regression in one of those patches that remains in master now
22 2013-08-17 07:56:06 <warren> Luke-Jr: https://github.com/wtogami/bitcoin/commits/btc09tested please consider these patches, you have most of them already
23 2013-08-17 07:56:41 <Luke-Jr> listreceivedbyaddress now provides tx ids (issue #1149) <-- not a fix
24 2013-08-17 07:56:56 <warren> don't need all of it
25 2013-08-17 07:57:16 <warren> "Log reason for non-standard transaction rejection" is pretty helpful
26 2013-08-17 07:57:48 <Luke-Jr> in fact, most of this doesn't look like fixes
27 2013-08-17 07:58:49 <Luke-Jr> stable branches aren't for people who want an older version. they're for people who can't upgrade yet.
28 2013-08-17 07:59:33 <Luke-Jr> or when there are strict fix-only policies to deal with (eg, Debian)
29 2013-08-17 08:00:29 <warren> these patches seemed safe and helpful i one way or another so I included it in our testing for months prior to bitcoin shipping them in production. We pulled some because we found bugs (in non-main variant branches).
30 2013-08-17 08:00:36 <warren> s/pulled/removed/
31 2013-08-17 08:01:04 <warren> so yes, our goals were a little different than stable backports
32 2013-08-17 08:01:14 <warren> "Log reason for non-standard transaction rejection" was helpful in debugging
33 2013-08-17 08:01:24 <warren> and certainly not dangerous
34 2013-08-17 08:41:38 <Luke-Jr> User experience attempting (and failing!) to use pulltester builds: http://0bin.net/paste/Y5-4KlHz2Y4AoaXc#4ipfvASglE0JJR70FsoBmPM6j+7trwTim44QWhzWTgY=
35 2013-08-17 08:41:56 <Luke-Jr> no idea what's going wrong there
36 2013-08-17 09:05:07 <Supa> wtf potatoe
37 2013-08-17 09:57:55 <tekkentux> to those who remember (e.g. Luke-Jr ) I think I found the reason, why bitcoind rejects my miners data.
38 2013-08-17 09:58:14 <Luke-Jr> ?
39 2013-08-17 09:58:25 <tekkentux> some debug output showed, that the hash is reversed before comparison to target
40 2013-08-17 09:58:53 <tekkentux> so its like it was a 256 little endian number
41 2013-08-17 09:59:28 <tekkentux> not groups of 4 bytes reversed each, but 1 gropu of 32 bytes reversed
42 2013-08-17 10:00:12 <tekkentux> so my hashes actually have zeros in the end not in the beginning
43 2013-08-17 10:05:22 <tekkentux> so I think I must do "if (reverse(hash) < target) then yay" instead of "if (hash < target) then yay" on my miner
44 2013-08-17 10:05:49 <tekkentux> because thats what bitcoind seems to do
45 2013-08-17 10:06:09 <JWU42> just had both bitcoinds crash again
46 2013-08-17 10:06:21 <JWU42> seems same issue as 2 weeks ago...
47 2013-08-17 10:07:10 <JWU42> https://www.refheap.com/bb5b3f6d1b43efa1bfd2f904f
48 2013-08-17 10:09:02 <JWU42> I think there was a patch but I didn't apply it
49 2013-08-17 10:12:25 <sipa> there's a patch in git head
50 2013-08-17 10:12:41 <JWU42> guess it is time to update
51 2013-08-17 10:12:52 <JWU42> is 0.8.4 coming soon ?
52 2013-08-17 10:13:04 <sipa> probably
53 2013-08-17 10:13:16 <JWU42> thks sipa
54 2013-08-17 10:13:53 <gmaxwell> hurrah, patched node here survived it.
55 2013-08-17 10:14:03 <JWU42> patch works =)
56 2013-08-17 10:14:08 <gmaxwell> (assuming it saw the case)
57 2013-08-17 10:14:15 <tgs3> there is a bug crashing bitcoind ?
58 2013-08-17 10:14:40 <gmaxwell> tgs3: mining ones with debug enabled
59 2013-08-17 10:15:04 <gmaxwell> JWU42: can you tell me the reorg that triggered it so I can see if I observed it?
60 2013-08-17 10:30:40 <Luke-Jr> sipa: is there a reason to release 0.8.4?
61 2013-08-17 10:35:33 <tekkentux> look at this: http://www.privatepaste.com/5bfe486036/laskfj
62 2013-08-17 10:36:14 <gmaxwell> Luke-Jr: we might do a core team 0.8.4 for that and some other assorted bits and bytes.
63 2013-08-17 10:36:33 <Luke-Jr> gmaxwell: might as well make it from the 0.8.x branch
64 2013-08-17 10:37:08 <tekkentux> the output is at the bottom: first line is the hash how its actually in memory, next line how it seems to be interpreted als 256bit little endian number (reversed). same applys to the target
65 2013-08-17 10:37:21 <gmaxwell> One thing is that it looks like 0.9 will end up with a pretty good list of agressive changes, may cause some slow updating, so a fixes release may be good.
66 2013-08-17 10:37:53 <Luke-Jr> changelog http://codepad.org/Su2CnSdB
67 2013-08-17 10:38:44 <tekkentux> but to get a hash that is reversed, one needs to have a totally different block. can't just send the block reversed or whatever. So when searching for a block one has to look for ending zeros, not for leading zeros actually
68 2013-08-17 10:38:57 <tekkentux> does that make sence to anyone?
69 2013-08-17 10:39:06 <Luke-Jr> tekkentux: old news
70 2013-08-17 10:39:12 <tekkentux> omg
71 2013-08-17 10:39:20 <tekkentux> I didn't knew that :(
72 2013-08-17 10:39:34 <Luke-Jr> tekkentux: hope you didn't produce ASICs assuming the reverse <.<
73 2013-08-17 10:39:39 <tekkentux> loool
74 2013-08-17 10:39:39 <tekkentux> no
75 2013-08-17 10:40:17 <tekkentux> maybe there should be a hint to that in the wiki
76 2013-08-17 10:40:36 <sipa> bitcoin interprets all data as little-endian
77 2013-08-17 10:40:39 <Luke-Jr> gmaxwell: v0.8.3..0.8.x diff http://codepad.org/P8I8pm5i
78 2013-08-17 10:40:47 <Luke-Jr> sipa: it's NOT that simple :<
79 2013-08-17 10:40:53 <sipa> except things that are done in crypto libraries
80 2013-08-17 10:41:01 <Luke-Jr> sipa: this is a mixed-endian thing
81 2013-08-17 10:41:06 <sipa> ok
82 2013-08-17 10:41:19 <Luke-Jr> the number is 256-bit little endian, but with each 32-bit chunk in big endian
83 2013-08-17 10:41:28 <sipa> i'll shut up without having implememted a miner myself
84 2013-08-17 10:41:32 <sipa> oh, really?
85 2013-08-17 10:41:33 <sipa> ok
86 2013-08-17 10:41:54 <tekkentux> A hint like "don't forget that leading zeros are actually ending zeros in the produced hash" somewhere would help
87 2013-08-17 10:41:55 <Luke-Jr> IIRC
88 2013-08-17 10:42:18 <Luke-Jr> tekkentux: wikis are editable!
89 2013-08-17 10:42:34 <tekkentux> I'll add that
90 2013-08-17 10:42:40 <sipa> Luke-Jr: that changelog does not include the chainparams refactor, but does include somethijg that depends on it?
91 2013-08-17 10:42:43 <tekkentux> if it's editable by everyone
92 2013-08-17 10:42:47 <sipa> (the 0x thing)
93 2013-08-17 10:43:18 <Luke-Jr> sipa: correct
94 2013-08-17 10:43:29 <sipa> that seems strange?
95 2013-08-17 10:43:36 <Luke-Jr> sipa: that bug was moved from another spot
96 2013-08-17 10:43:41 <sipa> ah ok
97 2013-08-17 10:44:55 <Luke-Jr> guess maybe I should have changed the log comment
98 2013-08-17 11:31:09 <PRab> In the preferences pane, is there a way to see what the url to the various servers is?
99 2013-08-17 11:31:39 <sipa> ?
100 2013-08-17 11:31:48 <PRab> ^sry, wrong channel.
101 2013-08-17 12:40:30 <sipa> ;;genrate 4
102 2013-08-17 12:40:31 <gribble> The expected generation output, at 4.0 Mhps, given difficulty of 50810339.0483, is 3.95908805846e-05 BTC per day and 1.64962002436e-06 BTC per hour.
103 2013-08-17 12:47:38 <sipa> ;;genrate 300
104 2013-08-17 12:47:39 <gribble> The expected generation output, at 300.0 Mhps, given difficulty of 50810339.0483, is 0.00296931604384 BTC per day and 0.000123721501827 BTC per hour.
105 2013-08-17 13:05:52 <Zoop_> http://blockchain.info/charts/n-transactions-excluding-popular
106 2013-08-17 13:06:05 <Zoop_> is the network being ddos'd?
107 2013-08-17 13:06:54 <Zoop_> it's almost surpassing April's value
108 2013-08-17 15:09:28 <JyZyXEL> i wonder why the Analysis of hashrate-based double-speding by Meni Rosenfeld doesn't include the probabilities for 0-confirmations?
109 2013-08-17 15:12:07 <Luke-Jr> JyZyXEL: probably because the probability of a 0-confirm is 100% if someone is trying?
110 2013-08-17 15:14:39 <JyZyXEL> because they had already pre-mined the transaction into the next block prior to broadcasting the other transaction?
111 2013-08-17 15:20:44 <JyZyXEL> it still could be added in the chapter 6. Economics of double-spending
112 2013-08-17 15:29:27 <JyZyXEL> i wonder if anyone has yet made a bitcoin double-spend profitability calculator :p
113 2013-08-17 15:40:22 <JyZyXEL> everyone is using a cup of coffee as an example for 0-conf situations
114 2013-08-17 15:40:42 <JyZyXEL> hell i'd accept a verbal IOU for a coffee :p
115 2013-08-17 18:49:23 <sipa> Luke-Jr: see #2907
116 2013-08-17 19:12:25 <sipa> Luke-Jr: did i miss any reverted commits? #2907 doesn't seem to reinstate the quotation marks around $CC or the TMPDIR check
117 2013-08-17 19:18:46 <sipa> ah, the quotation marks come from the (not yet merged) autotools patch
118 2013-08-17 19:21:35 <Luke-Jr> sipa: why not nuke the ripple-based leveldb stuff and put the clean merge in its place? <.<
119 2013-08-17 19:22:35 <Luke-Jr> not sure what you mean re autotools patch
120 2013-08-17 19:23:08 <sipa> Luke-Jr: i did all nuking i could?
121 2013-08-17 19:23:25 <sipa> i'm not going to rewrite the public bitcoin/bitcoin repo
122 2013-08-17 19:23:34 <sipa> bitcoin/leveldb is clean
123 2013-08-17 19:23:35 <Luke-Jr> no, I mean rewrite bitcoin/leveldb
124 2013-08-17 19:23:38 <sipa> i did
125 2013-08-17 19:24:04 <Luke-Jr> that's not what github shows
126 2013-08-17 19:24:11 <Luke-Jr> or rather, it doesn't show a clean merge
127 2013-08-17 19:24:14 <sipa> ?
128 2013-08-17 19:24:41 <sipa> there are no merge commits whatsoever there
129 2013-08-17 19:24:47 <Luke-Jr> exactly the problem?
130 2013-08-17 19:25:01 <sipa> i don't know what you mean
131 2013-08-17 19:25:09 <sipa> it's just the history of the leveldb branch
132 2013-08-17 19:25:10 <Luke-Jr> there *should* be merge commits, from upstream
133 2013-08-17 19:25:23 <Luke-Jr> http://codepad.org/3WNZMcP5
134 2013-08-17 19:25:38 <Vinnie_win> Hey fellas
135 2013-08-17 19:25:58 <Vinnie_win> http://codepad.org/g8oelDXk Any idea why the bind() confuses my traits classes?
136 2013-08-17 19:26:03 <Vinnie_win> (program output at bottom)
137 2013-08-17 19:26:10 <sipa> Luke-Jr: you mean merge commits from leveldb upstream?
138 2013-08-17 19:26:22 <Luke-Jr> sipa: right
139 2013-08-17 19:26:41 <sipa> interesting
140 2013-08-17 19:26:52 <sipa> let me try that
141 2013-08-17 19:29:55 <Luke-Jr> this way it's trivial to do merges in the future with git, with clear/accurate history/accountability
142 2013-08-17 19:30:05 <sipa> yup, agree
143 2013-08-17 19:31:52 <sipa> any reason not to rebase our leveldb patches on top of current leveldb upstream?
144 2013-08-17 19:31:57 <sipa> and start from there
145 2013-08-17 19:34:36 <sipa> our own commits in that repository will be "artificial" anyway, as their original history is in the bitcoin repo
146 2013-08-17 19:36:37 <sipa> Luke-Jr: and your diff file has a change in Makefile, where "" are put around $(CC) - this seems to be a change that comes from TheUni's autotools branch?
147 2013-08-17 19:39:34 <Luke-Jr> sipa: no, it's upstream
148 2013-08-17 19:40:24 <Luke-Jr> sipa: rebasing destroys the original history, but other than that I guess it'd be fine; might as well set a clean precedent for future merges though IMO
149 2013-08-17 19:41:00 <Luke-Jr> * 28dad91 Release leveldb 1.10 <-- includes the quotes
150 2013-08-17 19:41:06 <sipa> you're right
151 2013-08-17 19:42:11 <sipa> i'm just very unconfortable with merged, i guess :)
152 2013-08-17 19:42:15 <sipa> *merges
153 2013-08-17 19:42:25 <sipa> i understand the purpose, but they look ugly
154 2013-08-17 19:44:41 <Luke-Jr> sipa: presentation is configurable in git ;p
155 2013-08-17 19:45:28 <sipa> can you do a rebase that retains merges?
156 2013-08-17 19:46:01 <sipa> --preserve-merges
157 2013-08-17 19:46:02 <sipa> ha!
158 2013-08-17 19:49:30 <sipa> doesn't seem to work
159 2013-08-17 19:51:34 <sipa> Luke-Jr: how did you generate that tree?
160 2013-08-17 20:02:15 <Luke-Jr> sipa: checked out LevelDB's 1.7 commit, cherry-picked Bitcoin's changes from the master branch on top of it, merged the 2 commits from upstream we added in 3.0.2, cherry-picked more commits from bitcoin's tree, then finally merged upstream's 1.12
161 2013-08-17 20:02:43 <sipa> let me try some more git-subtree magic first
162 2013-08-17 20:02:54 <sipa> if that doesn't work, i'll use your branch
163 2013-08-17 20:03:15 <Luke-Jr> sipa: if you just want to use that as-is, you can git fetch my repo and use: git reset --hard 202a78a
164 2013-08-17 20:03:59 <sipa> i know
165 2013-08-17 20:04:01 <Luke-Jr> I assume you're trying to reproduce it so you can learn how to make it and verify though
166 2013-08-17 20:04:09 <Luke-Jr> k
167 2013-08-17 20:04:17 <sipa> but that results in a rather large sequence of revert + reapplies
168 2013-08-17 20:06:07 <Luke-Jr> ?
169 2013-08-17 20:09:59 <Luke-Jr> due to subtree?
170 2013-08-17 20:10:36 <sipa> yes
171 2013-08-17 20:11:37 <sipa> it's inevitable probably, there's too much rewrite
172 2013-08-17 20:11:52 <Luke-Jr> submodules wouldn't need any rewrite
173 2013-08-17 20:13:00 <sipa> k
174 2013-08-17 20:30:37 <sipa> Luke-Jr: updated the pull request; i just used a rebased version of course leveldb tree for now
175 2013-08-17 20:30:48 <sipa> at least i trust this :)
176 2013-08-17 20:47:10 <gmaxwell> sipa: thanks.
177 2013-08-17 20:50:06 <Luke-Jr> sipa: what's the difference in CondVar::SignalAll ?
178 2013-08-17 20:50:26 <Luke-Jr> something from ripple?
179 2013-08-17 20:50:48 <sipa> it's a patch from the bugtracker
180 2013-08-17 20:51:08 <sipa> it's not merged upstream as upstream doesn't have the windows port
181 2013-08-17 20:51:42 <sipa> it was committed by JoelKatz, but they didn't write it
182 2013-08-17 20:52:26 <sipa> https://github.com/bitcoin/leveldb/commit/728aeb859348783068dc59cb597febe31cc370b4
183 2013-08-17 20:53:08 <Luke-Jr> hmm
184 2013-08-17 20:53:12 <gmaxwell> might want to fix that with correct attribution.
185 2013-08-17 20:53:23 <sipa> good point
186 2013-08-17 20:53:56 <sipa> that's hard, with the full email address not even being visible
187 2013-08-17 20:54:25 <gmaxwell> android wallet didn't support addr import right? so no one should be burned by compromised vanity addresses after the android rng incident?
188 2013-08-17 20:54:52 <sipa> it does support address import, from encrypted wallet backup files
189 2013-08-17 20:54:57 <gmaxwell> solve a captcha.
190 2013-08-17 20:55:06 <Luke-Jr> makhnich@gmail.com
191 2013-08-17 20:55:06 <sipa> ?
192 2013-08-17 20:55:13 <gmaxwell> makhnich@gmail.com
193 2013-08-17 20:55:15 <sipa> ah!
194 2013-08-17 20:55:16 <Luke-Jr> Vladimir Makhnychev
195 2013-08-17 20:56:22 <Luke-Jr> --date='Feb 22 00:00:00 2013 +0000' --author='Vladimir Makhnychev <makhnich@gmail.com>'
196 2013-08-17 20:58:55 <sipa> fixed
197 2013-08-17 21:01:28 <gmaxwell> User factors fun: some person I was talking to lost a couple btc through this sequence of events: Imported a key from a third party, obviously no way to remove it. Later, user flipped to the recv tab and picked an address to send coins to........
198 2013-08-17 21:03:37 <Luke-Jr> gmaxwell: yay combination vulnerabilities :/
199 2013-08-17 21:05:07 <gmaxwell> it's interesting that there are about four ways, design wise, we could have prevented this. E.g. no import (just sweep), not listing imports in the addr list, not setting up the recieve tab in a way that encourages reuse, showing imported keys differently.
200 2013-08-17 21:13:15 <JDuke128> hello , whats the usage of Merkle trees ? are they taking hash of data?
201 2013-08-17 21:18:07 <gmaxwell> JDuke128: you might want to try googling some introductory material to bitcoin. But transactions are hashed using a hash tree, so that they can be validated by someone without all the transactions.
202 2013-08-17 21:47:29 <gmaxwell> why the heck would BFL make their new mining product be a !@#! PCIex16 card?!?!?
203 2013-08-17 21:47:45 <JDuke128> gmaxwell , okay good
204 2013-08-17 21:47:46 <JDuke128> but
205 2013-08-17 21:47:59 <JDuke128> docs doesnt explain about merkle tree deeply
206 2013-08-17 21:48:07 <JDuke128> as i read on google docs
207 2013-08-17 21:48:26 <gmaxwell> JDuke128: google docs?
208 2013-08-17 21:48:26 <JDuke128> merkle tree is a hash tree checking data is true or not in realtime
209 2013-08-17 21:48:53 <JDuke128> google search
210 2013-08-17 21:48:55 <JDuke128> i mean
211 2013-08-17 21:48:56 <Luke-Jr> gmaxwell: isn't it x1?
212 2013-08-17 21:49:49 <gmaxwell> well the _picture_ is an x16 card.
213 2013-08-17 21:49:54 <JDuke128> for example if i ve 5GB data , i can take directly hash of every 1024 byte data with SHA-1. Whats the advantage of merkle tree with other solution with SHA-1 hash every 1024 byte ?
214 2013-08-17 21:50:29 <gmaxwell> Luke-Jr: I guess I should be happy because it won't have an insanely slow bus at least... unless they manage to stick a pci->uart interface on it.
215 2013-08-17 21:50:59 <gmaxwell> JDuke128: this isn't really a bitcoin development question, you should ask in #bitcoin.