1 2012-04-28 00:00:14 <etotheipi_> why? I thought I remember seeing something like that
  2 2012-04-28 00:00:31 <sipa> the best varint format i've heard is one where you encode the number as something in base 128, and add a one bit if another byte follows
  3 2012-04-28 00:01:00 <luke-jr> sipa: I think that's Google protobuf
  4 2012-04-28 00:01:18 <sipa> luke-jr: i certainly heard about it earlier :)
  5 2012-04-28 00:01:22 <luke-jr> occasionally I abuse UTF-8 as a varint <.<
  6 2012-04-28 00:01:34 <etotheipi_> protobuf is pretty smooth
  7 2012-04-28 00:01:40 <etotheipi_> but I don't want to use it for wallets
  8 2012-04-28 00:01:48 <etotheipi_> I want full 100% control over the binary structure
  9 2012-04-28 00:02:18 <sipa> luke-jr: perldoc -f pack
 10 2012-04-28 00:02:21 <sipa> "w"
 11 2012-04-28 00:02:51 <luke-jr> nice
 12 2012-04-28 00:03:04 <sipa> though that's a bit inefficient still
 13 2012-04-28 00:03:16 <luke-jr> not as bad as my UTF-8 abuse :P
 14 2012-04-28 00:03:36 <sipa> it still allows a single number to be encoded in multiple ways
 15 2012-04-28 00:03:46 <luke-jr> no, it doesn't&
 16 2012-04-28 00:03:50 <sipa> sure does
 17 2012-04-28 00:03:57 <luke-jr> it specifies that only the shortest possible is valid
 18 2012-04-28 00:04:07 <sipa> oh, yes, sure
 19 2012-04-28 00:04:10 <luke-jr> "with as few digits as possible"
 20 2012-04-28 00:04:17 <sipa> it may not be valid
 21 2012-04-28 00:04:43 <sipa> but if it isn't, there is still a byte sequence that would decode to the same value (even though not in a valid way) that becomes unused
 22 2012-04-28 00:04:54 <sipa> so there is reducancy
 23 2012-04-28 00:05:02 <sipa> and it's trivial to fix that
 24 2012-04-28 00:06:28 <sipa> i once implemented a non-redundant variant of this in bitcoin's serialize.h, but ended up never using it
 25 2012-04-28 00:11:42 <gmaxwell> sipa: Just be glad that it doesn't use http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1019854&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1019854
 26 2012-04-28 00:14:31 <sipa> gmaxwell: haha
 27 2012-04-28 00:16:25 <sipa> pairs of non-negative integers, that is
 28 2012-04-28 00:19:54 <etotheipi_> how do I know that is a true bijection between (x,y) and the output?
 29 2012-04-28 00:20:49 <copumpkin> you prove it!
 30 2012-04-28 00:30:24 <etotheipi_> I like the idea, and I know such a bijection provably exists... I have just never actually seen one (or pondered what it would look like)
 31 2012-04-28 00:30:40 <etotheipi_> presumably, sipa knows something I don't, though :)
 32 2012-04-28 00:46:07 <sipa> etotheipi_: it actually is a bijection from N^2 to N
 33 2012-04-28 00:46:38 <sipa> a very known one
 34 2012-04-28 00:48:31 <etotheipi_> sipa: I know one exists, I've just never seen it
 35 2012-04-28 00:48:38 <etotheipi_> (I also never went looking)
 36 2012-04-28 00:49:06 <etotheipi_> is the inverse function "easy"?'
 37 2012-04-28 00:51:10 <sipa> if you have integer division, yes
 38 2012-04-28 00:51:48 <etotheipi_> well, I meant... is it computationally efficient?
 39 2012-04-28 00:51:48 <sipa> oh, and square root
 40 2012-04-28 00:52:18 <gmaxwell> compared to the one based on the Goldbach's conjecture? :)
 41 2012-04-28 00:53:04 <gmaxwell> (well I suppose that one was cheap to decode)
 42 2012-04-28 00:53:18 <etotheipi_> so in practical terms, I'm probably assuming x and y are 32 bytes each, so I could just as easily make a 64-bit number and copy x into the first 32 and y into the second 32
 43 2012-04-28 00:53:24 <etotheipi_> *32-BITS
 44 2012-04-28 00:53:49 <sipa> etotheipi_: of course
 45 2012-04-28 00:53:54 <etotheipi_> but say instead I decide to encode x,y like this, which would still require 64-bit output
 46 2012-04-28 00:54:09 <etotheipi_> how much of a hit am I taking compared to the simple solution?
 47 2012-04-28 00:54:34 <etotheipi_> I guess, the difference is I can encode a 12-bit x and 48-bit y into the same 64-bit number
 48 2012-04-28 00:55:12 <sipa> you lose one extra bit
 49 2012-04-28 00:55:27 <sipa> or maybe slightly more
 50 2012-04-28 01:34:34 <GTRsdk> I probably should have asked here... Do you make any money off of Bitcoin?
 51 2012-04-28 01:36:24 <splatster> GTRsdk: It depends on who you ask.
 52 2012-04-28 01:37:05 <GTRsdk> How do you make money off of  it (if you do)?
 53 2012-04-28 01:37:29 <splatster> I personally do make money off of investing.
 54 2012-04-28 01:38:02 <splatster> I run, with the help of smickles, a bitcoin investment fund.
 55 2012-04-28 01:38:25 <splatster> I also do investing with my personal bitcoin assets.
 56 2012-04-28 01:39:01 <splatster> And with that, I do make money through the use of bitcoin.
 57 2012-04-28 01:40:37 <splatster> GTRsdk: There are also people who mine bitcoins in order to make money.
 58 2012-04-28 07:01:01 <Joric> etotheipi_, constructing / editing / sending transactions using pure js http://brainwallet.org/#transactions
 59 2012-04-28 07:01:13 <Joric> just checked it works fine
 60 2012-04-28 07:47:19 <Joric> ThomasV, http://brainwallet.org/#transactions <- transaction constructor / sender (draft)
 61 2012-04-28 07:48:35 <ThomasV> Joric: what is your goal?
 62 2012-04-28 07:49:40 <Joric> having a good time )
 63 2012-04-28 07:50:37 <Joric> just studying the protocol
 64 2012-04-28 07:51:01 <ThomasV> sounds phishy
 65 2012-04-28 07:51:40 <Joric> you got phishy ears
 66 2012-04-28 07:53:55 <ThomasV> heh, why did you first deny being the author of that site?
 67 2012-04-28 07:56:59 <Joric> i'm terrified of how lousy it's written
 68 2012-04-28 08:00:52 <ThomasV> oh but you're not terrified of criticizing other people's code, though
 69 2012-04-28 08:01:00 <ThomasV> honestly I do not trust you
 70 2012-04-28 08:01:18 <ThomasV> I believe this is a shameless fishing attempt
 71 2012-04-28 08:10:15 <Joric> huh i just discovered this thread https://bitcointalk.org/index.php?topic=51252.0
 72 2012-04-28 08:10:25 <paulo_> how do I choose another directory aside from /appdata/roaming ?
 73 2012-04-28 08:10:47 <Joric> from the dark pre-blockchaininfo times
 74 2012-04-28 08:11:01 <paulo_> oh wait not really a dev question.
 75 2012-04-28 08:11:15 <Joric> have to make a backup implementation using bbe in case if bci will be down
 76 2012-04-28 08:20:51 <paulo_> what version was mining removed from gui?
 77 2012-04-28 10:11:36 <luke-jr> sipa: so anyhow, I have a backtrace of addrman crashing bitcoind&
 78 2012-04-28 10:12:09 <sipa> luke-jr: show me
 79 2012-04-28 10:13:29 <luke-jr> is there a bug open for it already?
 80 2012-04-28 10:13:58 <sipa> https://github.com/bitcoin/bitcoin/issues/1065 maybe
 81 2012-04-28 10:14:16 <luke-jr> nope, diff
 82 2012-04-28 10:14:23 <luke-jr> https://github.com/bitcoin/bitcoin/issues/1156
 83 2012-04-28 10:15:34 <luke-jr> I presume the only way to get a segfault here is probably a missing mutex lock?
 84 2012-04-28 10:15:48 <luke-jr> anything to do before I close gdb? ;)
 85 2012-04-28 10:16:53 <sipa> sec
 86 2012-04-28 10:17:41 <sipa> a missing mutex is pretty much impossible
 87 2012-04-28 10:17:50 <sipa> but it would explain things of cource
 88 2012-04-28 10:17:52 <sipa> course
 89 2012-04-28 10:17:55 <sipa> sec
 90 2012-04-28 10:18:12 <luke-jr> should I backtrace other threads?
 91 2012-04-28 10:18:14 <gribble> New news from bitcoinrss: luke-jr opened issue 1156 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1156>
 92 2012-04-28 10:19:59 <luke-jr> hmm, that's the only thread in addrman
 93 2012-04-28 10:21:27 <sipa> yes, certainly
 94 2012-04-28 10:21:40 <sipa> can you go to #6, and print nOldest
 95 2012-04-28 10:22:57 <luke-jr> $1 = <optimized out>
 96 2012-04-28 10:25:00 <sipa> all public methods of CAddrMan lock cs, so two threads in addrman simultaneously should be impossible
 97 2012-04-28 10:26:03 <luke-jr> they're not.
 98 2012-04-28 10:26:10 <sipa> ?
 99 2012-04-28 10:26:13 <luke-jr> I updated the issue with backtraces on all threads
100 2012-04-28 10:26:25 <luke-jr> this is the only one inside addrman
101 2012-04-28 10:27:02 <sipa> could you try compiling your node with -DDEBUG_ADDRMAN, and hope the error appears again?
102 2012-04-28 10:27:09 <luke-jr> sure
103 2012-04-28 10:27:29 <sipa> it will probably take a while
104 2012-04-28 10:27:44 <sipa> given the low frequency of addrman-related error reports
105 2012-04-28 10:27:55 <luke-jr> it's been happening a lot on this node
106 2012-04-28 10:28:20 <luke-jr> this is #bitcoin-watch 's
107 2012-04-28 10:29:08 <luke-jr> also doing -O0 -ggdb
108 2012-04-28 10:30:24 <sipa> eh, and still optimized away?
109 2012-04-28 10:30:25 <luke-jr> sipa: fyi, this crash corrupted addr.dat too
110 2012-04-28 10:30:36 <luke-jr> sipa: no, I mean on the new build :P
111 2012-04-28 10:31:07 <sipa> that makes me assume the actual corruption occurred earlier
112 2012-04-28 10:31:18 <sipa> the corrupted state somehow got serialized
113 2012-04-28 10:31:28 <sipa> and then caused an error a bit later
114 2012-04-28 10:31:34 <luke-jr> hmm
115 2012-04-28 10:33:36 <sipa> DEBUG_ADDRMAN should detect corruptions immediately
116 2012-04-28 10:33:52 <luke-jr> and log them? or assert-fail?
117 2012-04-28 10:36:06 <sipa> assert-fail
118 2012-04-28 10:36:33 <sipa> with an error number
119 2012-04-28 10:45:45 <gribble> The operation succeeded.
120 2012-04-28 10:45:45 <sipa> ;;later tell gavinandresen my gitian builds of 0.6.1rc1 don't match yours at all
121 2012-04-28 10:49:50 <sipa> b9edb45129d44fb78d34986c4e24965f4fa9d4bb56b96390e045d95d113d59a5  bitcoin-deps-0.0.4.zip
122 2012-04-28 10:50:11 <sipa> ah, those are identical for gavin
123 2012-04-28 10:55:12 <luke-jr> sipa: I think this is GitHub's fault.
124 2012-04-28 10:55:32 <luke-jr> v0.6.1rc1 is a different rev on my gitian VM and dev system
125 2012-04-28 10:56:11 <luke-jr> wait no, just had to force a refetch
126 2012-04-28 10:58:29 <Diablo-D3> ;;bc,tslb
127 2012-04-28 10:58:30 <gribble> Time since last block: 1 week, 3 days, 15 hours, 36 minutes, and 4 seconds
128 2012-04-28 10:58:39 <Diablo-D3> whats the real value?
129 2012-04-28 10:59:21 <luke-jr> Diablo-D3: you broke it by abusing power again
130 2012-04-28 11:00:33 <sipa> luke-jr: same problem that gavin had, it seems
131 2012-04-28 11:01:38 <sipa> his build is identified as v0.6.1rc1-2-g0acbe31-dirty-beta
132 2012-04-28 11:01:47 <Diablo-D3> >dirty
133 2012-04-28 11:02:04 <Diablo-D3> needs more .gitignore
134 2012-04-28 11:05:28 <gribble> The operation succeeded.
135 2012-04-28 11:05:28 <sipa> ;;later tell your build is identified as v0.6.1rc1-2-g0acbe31-dirty-beta, so it seems the git directory on your build system didn't have the latest 0.6.1rc1 tag
136 2012-04-28 11:05:36 <gribble> The operation succeeded.
137 2012-04-28 11:05:36 <sipa> ;;later tell gavinandresen  your build is identified as v0.6.1rc1-2-g0acbe31-dirty-beta, so it seems the git directory on your build system didn't have the latest 0.6.1rc1 tag
138 2012-04-28 11:06:30 <luke-jr> sipa: err, why not?
139 2012-04-28 11:06:38 <luke-jr> 0acbe31 (tag: v0.6.1rc1
140 2012-04-28 11:07:04 <sipa> why not what?
141 2012-04-28 11:09:08 <luke-jr> except for the dirty, that looks like the right tag commit
142 2012-04-28 11:09:35 <sipa> luke-jr: it should be v0.6.1rc1 (which is equal to v0.6.1rc1-0-g0acbe31)
143 2012-04-28 11:10:02 <sipa> but his build env still had the old v0.6.1rc1 tag, and git describe used that as base for generating the description
144 2012-04-28 11:10:18 <sipa> the 2 means "two commits since"
145 2012-04-28 11:10:38 <sipa> so the commit is correct, but the tag used to do the description isn't
146 2012-04-28 11:11:55 <sipa> probably caused by not pulling in all tags, only branches
147 2012-04-28 11:12:16 <luke-jr> i c
148 2012-04-28 11:20:28 <gribble> The expected generation output, at 1024 Khps, given current difficulty of 1508589.6720603 , is 0.000682735856406 BTC per day and 2.84473273502e-05 BTC per hour.
149 2012-04-28 11:20:28 <sipa> ;;bc,gen 1024
150 2012-04-28 11:20:45 <gribble> The expected generation output, at 102400 Khps, given current difficulty of 1508589.6720603 , is 0.0682735856406 BTC per day and 0.00284473273502 BTC per hour.
151 2012-04-28 11:20:45 <sipa> ;;bc,gen 102400
152 2012-04-28 11:53:30 <gribble> New news from bitcoinrss: rebroad opened issue 1157 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1157>
153 2012-04-28 11:58:44 <gribble> New news from bitcoinrss: rebroad opened issue 1158 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1158>
154 2012-04-28 12:29:06 <etotheipi_> sipa: for compressed public keys, are you encoding the private keys [0x80 + priv32 + 0x01 + chksum4] ?
155 2012-04-28 12:29:17 <etotheipi_> where the checksum is over the first 34 bytes?
156 2012-04-28 12:30:23 <sipa> etotheipi_: yes (though i consider the checksum part of the base58 encoding)
157 2012-04-28 12:34:45 <etotheipi_> okay... I'm mildly annoyed that I can't decide how to handle this extra byte... it was nice and compact to have just 32-bytes for the priv key
158 2012-04-28 12:35:47 <etotheipi_> if I throw it in... I now need 64 bytes for encryption of 33 bytes, or I leave it out, and manually maintain a flag which is likely to have logic bugs
159 2012-04-28 12:36:08 <etotheipi_> ooh, it's only 48 bytes, actually.... AES256 has a blocksize of 16, right?
160 2012-04-28 12:36:18 <sipa> yes
161 2012-04-28 12:36:54 <sipa> afaik the satoshi client does not encrypt the compressed flag
162 2012-04-28 12:37:07 <sipa> it doesn't even store it, it just looks at the size of the public key
163 2012-04-28 12:37:17 <sipa> gmaxwell:
164 2012-04-28 12:37:18 <sipa> -rwxrwxr-x 1 pw pw 3466848 2012-04-28 16:35 bitcoin-qt-flto
165 2012-04-28 12:37:19 <sipa> -rwxrwxr-x 1 pw pw 2926280 2012-04-28 16:35 bitcoin-qt-flto-stripped
166 2012-04-28 12:38:05 <etotheipi_> okay, good to know...
167 2012-04-28 12:59:55 <etotheipi_> sipa: any preference on naming of HMAC-512(c_par, K_par)[:4]?  I'm just referring to it as an "ID"
168 2012-04-28 13:00:00 <etotheipi_> but it's not meant to be unique
169 2012-04-28 13:00:53 <etotheipi_> another mainly-arbitrary point...
170 2012-04-28 13:08:44 <sipa> fingerprint?
171 2012-04-28 13:09:19 <etotheipi_> I like that
172 2012-04-28 13:09:23 <etotheipi_> besides the fact it's long
173 2012-04-28 13:09:28 <sipa> (id seems to imply that it uniquely identifies a key, although even in gpg a key id is shorter than a fingerprint)
174 2012-04-28 13:10:35 <etotheipi_> agreed... I think ID kind of implies uniqueness, even though it frequently isn't
175 2012-04-28 13:11:52 <etotheipi_> so I think I'll go with "fingerprint"
176 2012-04-28 13:12:21 <etotheipi_> even though getParentFingerprint() doesn't fit well into my 80-width columns
177 2012-04-28 13:23:54 <sipa> etotheipi_: hmm, turning the second argument of CKD into a bytestring is problematic for the serialization format
178 2012-04-28 13:24:06 <etotheipi_> sipa: I was just thinking that
179 2012-04-28 13:24:24 <etotheipi_> I was going to reconcile it in my brain before bringing it up though :)
180 2012-04-28 13:25:06 <sipa> you could say if the 32-bit number there is 0xFFFFFFFF, it is derived using a byte sequence and is non-enumeratable
181 2012-04-28 13:25:21 <sipa> but that also makes it non-verifiable
182 2012-04-28 13:25:42 <etotheipi_> my concern is, I want my address/key serialization to be constant size
183 2012-04-28 13:25:56 <etotheipi_> so I don't want to have arbitrary-sized fields in the format
184 2012-04-28 13:26:10 <sipa> ic
185 2012-04-28 13:26:18 <etotheipi_> It's more of a preference though...
186 2012-04-28 13:26:27 <etotheipi_> I figured out why 32-bytes is special
187 2012-04-28 13:26:34 <sipa> for serialization formats, i care less about constant size
188 2012-04-28 13:26:45 <sipa> but it's not worth it here
189 2012-04-28 13:27:11 <etotheipi_> because 32-bytes is universally accepted as there-will-be-no-collisions-here-ever
190 2012-04-28 13:27:31 <sipa> meh, you get that at 20 bytes even
191 2012-04-28 13:27:38 <sipa> though maybe not anymore in 20 years
192 2012-04-28 13:27:40 <etotheipi_> not necessarily
193 2012-04-28 13:29:33 <sipa> the entire bitcoin network did "only" around 2^68 so far
194 2012-04-28 13:29:39 <sipa> hash operations
195 2012-04-28 13:29:55 <etotheipi_> oh yeah, I actually calculated that at one point
196 2012-04-28 13:30:14 <sipa> no need to calculate it, bitcoind just tells you :0
197 2012-04-28 13:30:29 <sipa> SetBestChain: new best=00000000000002ea9164  height=177607  work=306752139312713168912
198 2012-04-28 13:30:45 <sipa> work is the expected number of hash operations in the chain so far
199 2012-04-28 13:31:11 <etotheipi_> but isn't collision "probability" proportional to sqrt(N) where N is the size of the space?
200 2012-04-28 13:31:22 <sipa> yes
201 2012-04-28 13:31:35 <etotheipi_> so 20-bytes is like 10-bytes in terms of collisions
202 2012-04-28 13:31:43 <etotheipi_> which is still high
203 2012-04-28 13:32:38 <sipa> collision probability is 1-e(-n^2 / (2*d))
204 2012-04-28 13:32:49 <etotheipi_> oh yeah, I had searched the blockchain and found the hardest hash, ever:  it's block 125552
205 2012-04-28 13:33:03 <sipa> with n the number of elements, and d the size of the space
206 2012-04-28 13:33:04 <etotheipi_> it would've been valid even at a difficulty of 35 billion
207 2012-04-28 13:33:58 <sipa> not too surprising.. if you have 1000 blocks at difficulty d, on average 1 will be good enough to beat difficulty 1000*d
208 2012-04-28 13:34:01 <etotheipi_> though that was 8 months ago, I should check again to see if there's a new one
209 2012-04-28 13:34:13 <sipa> well... not exactly sure about the math there
210 2012-04-28 13:36:51 <sipa> this is better: if you have 1000 blocks at difficulty d, there is a 50% chance that at least one would have beaten difficulty 1443*d
211 2012-04-28 13:38:44 <seco> btw blockchain it would be great idea to add datestamp of a tx 1st seen in blockchain to satoshi client: its really irritating to catchup and see transactions coming in with current datestamp, but were inititated ages ago instantly getting a bunch of confirmations while going on the catch-up... @luke-jr dont have to be necesairy a revert, but maybe printing both datestamps?; Printing local timestamp does destroy the "timeline" one would understand the
212 2012-04-28 13:38:45 <seco> catchup-process i think
213 2012-04-28 13:41:32 <seco> By sticking to a date, i think network-date should be always used in bitcoin world: Also if tooltip mentions "catching up 2days ago": I mean what 2 days ago, if "the transaction just came in in this minute"?
214 2012-04-28 13:45:37 <etotheipi_> damn, 50k blocks later, 125552 still has the lowest hash
215 2012-04-28 13:46:21 <etotheipi_> if you do 2^67.1 hashes, 50% chance you'll find a hash more difficult than that one
216 2012-04-28 13:52:34 <etotheipi_> sipa: okay, I just updated the CKD test vectors with "fingerprints"
217 2012-04-28 13:53:58 <sipa> etotheipi_: i think i'd like to keep the CKD parameter a 32-bit number, as there is no practical benefit to allowing more, and it has a nicer serialization
218 2012-04-28 13:54:21 <etotheipi_> sipa: that's fine
219 2012-04-28 13:55:29 <etotheipi_> users can choose 0xFFFFFFFF and then their own supplemental information if they're going to use bytestrings
220 2012-04-28 13:56:38 <etotheipi_> so basically you're saying that only enumeration up to 32-bit numbers is defined
221 2012-04-28 13:57:01 <etotheipi_> but there's nothing stopping devs from doing more with it outside the spec
222 2012-04-28 13:57:47 <sipa> the only question is whether the serialization should support it
223 2012-04-28 13:57:56 <sipa> by calling 0xFFFFFFFF special
224 2012-04-28 13:58:09 <etotheipi_> well if you go back to my original idea of 32-BYTES, you could specify everything is allowed
225 2012-04-28 13:58:20 <etotheipi_> any bytestrings will just be the hash of the bytestring
226 2012-04-28 13:58:31 <sipa> sigh
227 2012-04-28 13:58:34 <etotheipi_> haha
228 2012-04-28 13:58:43 <sipa> there is no technical problem in allowing *ANY* bytestring
229 2012-04-28 13:59:03 <sipa> HMAC already performs an extra hashing step to get it to fit in a hash block
230 2012-04-28 13:59:21 <sipa> the problem is whether this is supported by the serialization
231 2012-04-28 13:59:23 <sipa> and how
232 2012-04-28 13:59:26 <etotheipi_> understood
233 2012-04-28 13:59:42 <etotheipi_> but if the point of the serializing that value is so that the user can verify that the key is truly a child of the parent
234 2012-04-28 13:59:59 <sipa> yes
235 2012-04-28 14:00:13 <etotheipi_> then people using bytestrings need their own, separate serialization
236 2012-04-28 14:00:31 <etotheipi_> if you only put 4 bytes in that serialization, it's semi-unique, but it doesn't help them do that verification
237 2012-04-28 14:00:49 <sipa> unless only 32-bits are allowed :)
238 2012-04-28 14:02:06 <sipa> i'd somehow have liked m/N/"extern"/K
239 2012-04-28 14:02:47 <sipa> one possibility it to limit it to 8-byte strings instead of arbitrary strings, and encode numbers inside those
240 2012-04-28 14:02:59 <etotheipi_> right, but my point is that 32-bits is not sufficient for the full set of usecases
241 2012-04-28 14:03:11 <sipa> would 64 bit suffice?
242 2012-04-28 14:03:53 <sipa> (i think 2^32 subnodes will suffice in almost all cases, and in others you can just recurse one level further)
243 2012-04-28 14:04:59 <etotheipi_> you mean "escaping" the 32-bit restriction by using 0xFFFFFFFF and then appending extra data?
244 2012-04-28 14:05:25 <sipa> no
245 2012-04-28 14:05:54 <sipa> if you need m/(5*2^32 + 7), use m/5/7 instead
246 2012-04-28 14:06:23 <etotheipi_> oh
247 2012-04-28 14:06:47 <etotheipi_> then you have a variable depth depending on your input
248 2012-04-28 14:07:23 <etotheipi_> am I making this harder than it needs to be?
249 2012-04-28 14:07:29 <sipa> if you know you need 64-bits in a particular use case, start with 2x 32-bit in the first place
250 2012-04-28 14:07:48 <etotheipi_> all I want is collision resistance when hashes of arbitrary bytestrings are used
251 2012-04-28 14:08:12 <sipa> in the representation?
252 2012-04-28 14:08:37 <sipa> you can't have collision resistance with only 32 bits of hash info
253 2012-04-28 14:08:46 <etotheipi_> understood, that's why I've been fighting 32-bits
254 2012-04-28 14:09:08 <sipa> but are you fighting the 32-bits fingerprint or the 32-bits child identifier?
255 2012-04-28 14:09:13 <sipa> because it seems you're mixing them up
256 2012-04-28 14:09:32 <etotheipi_> no, I don't mind if the fingerprints are not unique, those have a different purpose
257 2012-04-28 14:09:44 <sipa> then which collision resistance are you talking about?
258 2012-04-28 14:09:54 <etotheipi_> because the fingerprint is different than what goes into CKD(KEY, ???)
259 2012-04-28 14:10:09 <sipa> yes of course, ??? is what i called the child identifier
260 2012-04-28 14:10:31 <sipa> but i don't see which other collision resistance could be a problem
261 2012-04-28 14:10:35 <etotheipi_> so I'm only talking about cild identifiers
262 2012-04-28 14:11:24 <etotheipi_> if I decided to use ac child ID that that is 1000 ASCII chars long, there is no way for me to store that in the serialization in a collisions resistent way
263 2012-04-28 14:11:49 <sipa> so you are talking about the serialization?
264 2012-04-28 14:11:51 <etotheipi_> but if you spec that any byte strings should use the hash of the child ID, and then the serialization has 32-bytes, then you constant
265 2012-04-28 14:11:57 <etotheipi_> yes
266 2012-04-28 14:12:26 <sipa> but the serialization is never collision resistant anyway
267 2012-04-28 14:12:52 <sipa> as it uses the parent's fingerprint, which is too short to provide collision resistance
268 2012-04-28 14:13:07 <etotheipi_> but if all I have is a serialization and a parent node serialization, how am I supposed to verify that the child belongs to the parent?
269 2012-04-28 14:13:35 <sipa> ah, yes, that's something else
270 2012-04-28 14:13:56 <sipa> you can't of course, once the child id is not contained anymore in the serialization
271 2012-04-28 14:14:25 <sipa> which is why i advocate only using 32-bits of child identification in the first place, and using an extra level if you need more
272 2012-04-28 14:15:14 <sipa> you can obviously go outside the spec if you want 1000-char ascii child id's, but those become not representable by the serialization
273 2012-04-28 14:15:55 <etotheipi_> but it is if you spec that bytestrings will be hashed to 32-bytes and use 32-bytes in the serialization
274 2012-04-28 14:15:58 <sipa> one way out is indeed making the special serialized child id 0xFFFFFFFF mean that the child id is unknown/unrepresentable, but that is no good if you still want the ability to link children to their parents
275 2012-04-28 14:16:22 <etotheipi_> but I agree that 32-bytes is excessive for all serializations
276 2012-04-28 14:16:23 <sipa> why waste 28 bytes, for something for which i don't see a use case?
277 2012-04-28 14:16:49 <sipa> i'm not sure how important that linkability is even
278 2012-04-28 14:17:19 <sipa> you need it for leafs and for accounts, because you need to be able to calculate the "next" sibling
279 2012-04-28 14:17:32 <sipa> but those have enumerable identifiers anyway
280 2012-04-28 14:19:45 <etotheipi_> sipa, I agree about the necessity of linkability
281 2012-04-28 14:19:58 <sipa> and the most flexible solution is probably just make the serialization format variable
282 2012-04-28 14:20:15 <sipa> since you don't often serialize non-enumerable child keys anyway
283 2012-04-28 14:20:21 <sipa> they are non-enumerable for a reason
284 2012-04-28 14:20:24 <etotheipi_> my point was if you make them all 32-bytes than you can never worry about it again...
285 2012-04-28 14:20:46 <sipa> or 20 bytes
286 2012-04-28 14:20:48 <sipa> or 64 bytes
287 2012-04-28 14:20:50 <sipa> or 128 bytes
288 2012-04-28 14:21:02 <etotheipi_> but you're right it seems like a waste of space for less-common use-cases
289 2012-04-28 14:21:41 <etotheipi_> but you don't need more than 32 to guarantee collision resistance
290 2012-04-28 14:22:37 <sipa> i can argue that 20 suffices as well :)
291 2012-04-28 14:23:06 <sipa> or 8, if you limit the scope of possible collisions
292 2012-04-28 14:23:45 <etotheipi_> I disagree
293 2012-04-28 14:24:42 <etotheipi_> let's go back to 32-bits, anyone that wants to do something than enumeration can do something else... I actually do like your idea of recursing...
294 2012-04-28 14:25:07 <etotheipi_> though I haven't thought about the consequences of arbitrary-depth chains
295 2012-04-28 14:31:38 <gribble> New news from bitcoinrss: sipa opened pull request 1159 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1159>
296 2012-04-28 14:33:05 <sipa> seco: ^
297 2012-04-28 14:33:43 <seco> ah
298 2012-04-28 14:34:19 <seco> ohh, thanks sipa: great to see my argumentation seems coherent :)
299 2012-04-28 14:40:18 <seco> maybe im not alone, but i think at the end nobody cares about the rescan-time: Could be redone anytime in future after dataloss and date of a static transactions would change to date of "restoration of backup", showing restored transactions coming in minute by minute, which is not what a user would like to see when they talk about a tx "last week" with their counterparty :)
300 2012-04-28 14:41:04 <seco> "oh wait i just restored backup: i guess you mean the tx 2hours ago" :P
301 2012-04-28 14:41:25 <sipa> well, the block chain is not a wallet backup
302 2012-04-28 14:42:40 <seco> i know, im just argueing as ordinary users would do :)
303 2012-04-28 15:09:03 <seco> another thing which should be fixed is the annoying time needed for shutdown-process of satoshi client (for example https://github.com/bitcoin/bitcoin/issues/1012): If the Speed up block downloading dbenv.set_cachesize generates 50% longer time for cleaning up on exit, then why not only calling this method if client finds out he needs more then (example:)50block to catchup? *hackish-smile*
304 2012-04-28 15:10:50 <splatster> seco: Why not do the cleanup after downloading the blocks needed to catch up?
305 2012-04-28 15:11:05 <sipa> seco: 0.6.1 shuts down in seconds ;)
306 2012-04-28 15:11:25 <sipa> or less
307 2012-04-28 15:11:36 <splatster> sipa: Even after being run for days?
308 2012-04-28 15:11:45 <sipa> should be, yes
309 2012-04-28 15:11:59 <splatster> It seems the longer I have 0.6.0 open, the exponentially longer it takes to shut down.
310 2012-04-28 15:12:16 <sipa> it depends mostly on the size of the block chain index
311 2012-04-28 15:12:25 <seco> splatster: client node needs to constantly evaluate new blocks: there is always need to NOT place chunks of data on slow disk, but its some kind of politics to decide how many redownloadable data can be destroyed on a cleanexit not to take half minute for a shutdown process
312 2012-04-28 15:12:59 <splatster> And I have a hybrid SSD and I am 100% certain that the block index is stored on the SSD portion of my drive, yet it still takes forever to shut down.
313 2012-04-28 15:13:00 <sipa> seco: the slow part was calling lsn_reset (which prepares a file for being moved to another database environment)
314 2012-04-28 15:13:06 <seco> sipa: cool, i highly await relase then :))
315 2012-04-28 15:13:29 <sipa> 0.6.0 called this function at shutdown for all database, including the block chain database
316 2012-04-28 15:13:38 <sipa> and that function takes time proportional to the size of the file
317 2012-04-28 15:14:30 <seco> ic, not a good idea for a blockchain in a year in future :D
318 2012-04-28 15:17:42 <seco> hopefully i can remove again notification wrappers around bitcoin-qt on 0.6.1 :)
319 2012-04-28 15:19:05 <gmaxwell> seco: notifaction wrappers?
320 2012-04-28 15:20:48 <seco> yeh, they tell my guys that now its allowed to shutdown the system or restart bitcoin-qt :p  ...they just dont know when disk-cleanup is finished (pointing a finger to the suggestion of closing UI as last element on exit of client)
321 2012-04-28 15:20:57 <seco> simple bash script...
322 2012-04-28 15:28:27 <BTCTrader> i have a question on using curl and the json format to send bitcoins
323 2012-04-28 15:28:42 <BTCTrader> i am trying to use curl --user snip:snip --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendtoaddress", "params": [snip] [.0001] }' -H 'content-type: text/plain;' https://snip:10006 -k
324 2012-04-28 15:28:58 <BTCTrader> but everything i am trying is generating a parse error, any suggestions?
325 2012-04-28 15:30:56 <sipa> what's snip?
326 2012-04-28 15:31:22 <BTCTrader> i removed those d??removed entries for privacy
327 2012-04-28 15:32:08 <sipa> well, whatever snip is, twhat you said above can't be valid
328 2012-04-28 15:32:15 <BTCTrader> when i use  "method": "getinfo", "params": [] it works
329 2012-04-28 15:33:18 <sipa> it would be "params":["par1","par2"]
330 2012-04-28 15:33:22 <sipa> should
331 2012-04-28 15:34:59 <BTCTrader> ah ok
332 2012-04-28 15:37:00 <BTCTrader> that resulted in {"result":null,"error":{"code":-1,"message":"value is type str, expected real"},"id":"curltest"}
333 2012-04-28 15:37:45 <BTCTrader> oh will change curltest to real
334 2012-04-28 15:38:12 <luke-jr> seco: I think having both timestamps in listtransactions is a good thing, and a "smart" algorithm for Bitcoin-Qt
335 2012-04-28 15:38:18 <BTCTrader> nope {"result":null,"error":{"code":-1,"message":"value is type str, expected real"},"id":"real"}
336 2012-04-28 15:41:03 <BTCTrader> i am unsure what value to replace it with, obviously not a string but what
337 2012-04-28 15:41:40 <seco> luke-jr: thats ok; personally im just interested in 1st seen on network :)
338 2012-04-28 15:41:58 <luke-jr> seco: 1st seen is what it is now..
339 2012-04-28 15:43:12 <seco> sipa opened some pull-request an hour ago (https://github.com/bitcoin/bitcoin/pull/1159); now its 1st seen on local client which i would consider irritating if it shows you on the same moment that some catchup is in progress with 1 week old data, seeing a tx coming in "just right now"
340 2012-04-28 15:46:14 <luke-jr> seco: looks like it's onyl for -rescan ?
341 2012-04-28 15:46:48 <seco> BTCTrader: are you sure there is a bitcoind listening at https://snip:10006 ? probably its some other https-daemon listening there?
342 2012-04-28 15:47:21 <BTCTrader> yes i am sure, the getinfo test works
343 2012-04-28 15:47:23 <BTCTrader> curl --trace-time --trace-ascii - \n3429369
344 2012-04-28 15:47:49 <BTCTrader> i am looking around the wiki and and web but i don't see any other values to replace curltest with
345 2012-04-28 15:47:55 <BTCTrader> null also does not work
346 2012-04-28 15:48:52 <BTCTrader> sorry, the one liner looks like   curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }'
347 2012-04-28 15:48:53 <BTCTrader> -H 'content-type: text/plain;' http://127.0.0.1:8332/
348 2012-04-28 15:49:51 <seco> luke-jr: what i meant is date showing on UI when a "new" transaction pops in while catching up on old blocks, but if its just -rescan thats also better then nothing: On my eyes its just irritating to go out of "intern Bitcoin date in blockchains which could be linked to first realdate seen" to local dates on client machines
349 2012-04-28 15:50:22 <sipa> ah, not only during rescan no
350 2012-04-28 15:50:34 <seco> luke-jr: everybody would talk about different timestamps if talked about the same transaction...
351 2012-04-28 15:50:53 <luke-jr> sipa: it's troublesome to get block times in live environments :/
352 2012-04-28 15:51:05 <paulo__> i don't fully understand how hash trees help lamport signatures
353 2012-04-28 15:52:36 <luke-jr> IMO, it should be "if received in a block, max(last txn time, min(blocktime, currenttime)); otherwise, received time"
354 2012-04-28 15:52:59 <luke-jr> that way you don't have history changing order or future transactions
355 2012-04-28 15:54:10 <helo> what's the easiest way to inject a transaction that has been generated in an offline machine?
356 2012-04-28 15:54:18 <seco> we need bitcoin utc timeserver to blockchain webservice :P
357 2012-04-28 15:54:35 <etotheipi_> helo: http://bitsend.rowit.co.uk/
358 2012-04-28 15:54:44 <etotheipi_> or use Armory :)
359 2012-04-28 15:55:35 <seco> advertisement for own client hehe ;)
360 2012-04-28 15:56:02 <etotheipi_> (well Armory won't broadcast arbitrary transactions, but it works great if you generate the offline tx with offline-Armory)
361 2012-04-28 15:56:11 <helo> nice, thanks
362 2012-04-28 15:56:35 <etotheipi_> that reminds me, I will add a "developer tool" which lets you broadcast arbitrary tx
363 2012-04-28 15:57:30 <helo> yes yes... would be a great rpc method for the satoshi client too
364 2012-04-28 15:58:02 <etotheipi_> I think I could write a really short script that would do it from the command line if Satoshi client is open already
365 2012-04-28 15:58:26 <seco> etotheipi_: its always a good idea to think about offline usage in case of access barred bitcoin nodes :) - importing private keys is one aspect, injecting signed transactions another way!
366 2012-04-28 15:58:56 <etotheipi_> seco: I don't know what you mean "in case of access barred bitcoin nodes"
367 2012-04-28 15:59:54 <seco> not every person running bitcoin client has internet, or fully available internet (in terms of censorship)
368 2012-04-28 16:00:14 <seco> or *who wants to use* bitcoin
369 2012-04-28 16:00:49 <etotheipi_> so what modifications would I make to my process to accommodate that better?
370 2012-04-28 16:00:55 <helo> /join #bitcoin-injector
371 2012-04-28 16:01:55 <seco> sadly i only have those 2 ideas i mentioned above right now; passing private/printable/readable keys or transactions somehow to person who has access to bitcoin-network
372 2012-04-28 16:03:00 <seco> means both sides need support for this: receiver as well as sender; in regards of private key import/export i think Armory already does a cool job! :)
373 2012-04-28 16:03:28 <etotheipi_> seco: the offline wallet already does this as long as there's a watching-only wallet somewhere that can collect information needed to create the transaction
374 2012-04-28 16:03:50 <etotheipi_> or, if you can periodically update the blockchain on the offline computer, it will work
375 2012-04-28 16:04:20 <etotheipi_> I chose to represent signed/unsigned transactions in a pseudo-ASCII-armored format that is printable, or easily sent through email
376 2012-04-28 16:05:02 <etotheipi_> so it would be easy to create the offline tx, then copy the signed "packet" to the party that does have access to the network to broadcast it
377 2012-04-28 16:05:37 <seco> yeah thats cool :))
378 2012-04-28 16:06:34 <helo> i use pywallet to generate the transaction
379 2012-04-28 16:06:45 <helo> err, to extract the transaction after generating with offline satoshi
380 2012-04-28 16:29:02 <etotheipi_> sipa, we use 0x80 to prefix main-net private keys, is it a different byte for testnet?
381 2012-04-28 16:29:21 <graingert> yep
382 2012-04-28 16:29:27 <graingert> urm private keys?
383 2012-04-28 16:29:38 <graingert> oh wait I missunderstood the question
384 2012-04-28 16:29:44 <graingert> I thought you were talking about addresses
385 2012-04-28 16:31:10 <graingert> it looks like it's 0x35 to me
386 2012-04-28 16:31:20 <graingert> 128
387 2012-04-28 16:31:25 <graingert> https://en.bitcoin.it/wiki/List_of_address_prefixes
388 2012-04-28 16:32:49 <graingert> etotheipi_: eg 5JiFu4TBrNyaWmBnhMQ5VsedZrrDx9h6Mqvr9NSjpg5GHfhASSH
389 2012-04-28 16:33:44 <etotheipi_> ahh, 239
390 2012-04-28 16:33:52 <etotheipi_> it's at the bottom of that first table on the page you linked me
391 2012-04-28 16:34:03 <etotheipi_> 0xef
392 2012-04-28 16:34:11 <graingert> well it looks like I can't read
393 2012-04-28 16:34:30 <etotheipi_> I had to ctrl-f to find it
394 2012-04-28 16:35:02 <graingert> https://en.bitcoin.it/wiki/List_of_address_prefixes
395 2012-04-28 16:35:05 <graingert> much better now
396 2012-04-28 16:35:12 <graingert> says Bitcoin Private Key
397 2012-04-28 16:35:15 <graingert> rather than Private key
398 2012-04-28 16:35:45 <graingert> that file probably needs splitting out into pubkey hash, priveky and p2sh
399 2012-04-28 16:35:48 <graingert> tables
400 2012-04-28 16:35:56 <etotheipi_> wtf are all these other chains... do any of them have more than 4 users besides BTC, NMC?
401 2012-04-28 16:37:52 <Blitzboom> etotheipi_: no
402 2012-04-28 16:38:02 <Blitzboom> and NMC doesnt have 4 users either
403 2012-04-28 16:39:45 <graingert> NMC has a few users
404 2012-04-28 16:43:50 <graingert> really it should be based on hash power
405 2012-04-28 16:44:17 <graingert> perhaps we could have a blockchain like NMC to allocate prefixes on a first come first served basis
406 2012-04-28 16:54:57 <egecko> interesting.. so for those who said that theres no one using windows phone, its interesting to see there have been 20 downloads of bitdozer so far
407 2012-04-28 16:55:24 <egecko> http://www.windowsphone.com/en-US/apps/1ef1acf5-ae97-4862-801c-04f519d41c51
408 2012-04-28 16:57:06 <luke-jr> etotheipi_: it may be worth noting at least some of the (testnet?) prefixes have changed, but nobody has updated the code yet
409 2012-04-28 16:57:29 <gmaxwell> egecko: 20 downloads ... automated web spiders? :)
410 2012-04-28 16:57:53 <egecko> from the microsoft marketplace? doubtful
411 2012-04-28 16:58:29 <graingert> egecko: that is one terrible log
412 2012-04-28 16:58:33 <graingert> o
413 2012-04-28 16:58:50 <egecko> anyway, it just goes to show there is interest in WP7 for those whove already sold out to android or the jobsian nightmare known as ios
414 2012-04-28 16:59:33 <egecko> im a programmer not a digital graphic artist, jim.
415 2012-04-28 16:59:45 <graingert> jim?
416 2012-04-28 17:00:05 <graingert> egecko: well I do know someone who logo's for bitcoin
417 2012-04-28 17:00:09 <egecko> jim. james t. kirk, its a star trek allusion :)
418 2012-04-28 17:01:08 <seco> egecko: its great you try to get the windows mobile volks in bitcoin, but luckily most of us seem happy not to worry about windows mobile world :x
419 2012-04-28 17:01:32 <graingert> meh just use webappz
420 2012-04-28 17:01:49 <graingert> I'd like to see the w3c webapp spec get pushed through and supported
421 2012-04-28 17:02:02 <graingert> it would be super nice for android to support that
422 2012-04-28 17:02:05 <graingert> as well as BTG
423 2012-04-28 17:02:18 <graingert> B2G*
424 2012-04-28 17:02:22 <egecko> i want everyone to use bitcoin regardless of their device or OS :)
425 2012-04-28 17:02:54 <egecko> bitdozer could actually be ported to android or ios very easily since its just c#
426 2012-04-28 17:04:54 <seco> sadly you are going the right direction with windows egecko ...i would think some nokia store app would also get some mangers into bitcoin as well :)
427 2012-04-28 18:39:33 <gribble> New news from bitcoinrss: retep opened pull request 1160 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1160>
428 2012-04-28 18:57:36 <sipa> luke-jr: the behaviour with that patch would be: transactions first seen in a "tx" message or self-generated get clock time, transactions first seen in a block or found by rescanning: block time
429 2012-04-28 19:25:58 <luke-jr> sipa: what was your build's sha256?
430 2012-04-28 19:26:13 <sipa> luke-jr: see gitian
431 2012-04-28 19:26:15 <sipa> .sigs
432 2012-04-28 19:26:22 <luke-jr> sipa: it's not in there&
433 2012-04-28 19:27:25 <sipa> oh, forgot to commit
434 2012-04-28 19:27:56 <seco> im not in the code, but isnt it possible to derive some kind of time from the Timestamp on each new block compared with the local time, and past transactions where local client already has datestamp on? - Like taking direct transactions more serious and using 1st seen time on those as reference values?
435 2012-04-28 19:30:56 <luke-jr> sipa: you have different qt and boost inputs O.o
436 2012-04-28 19:31:25 <luke-jr> outputs all match mine tho
437 2012-04-28 19:31:36 <sipa> good
438 2012-04-28 19:32:05 <luke-jr> we should lart gavin for uploading without 3 signers :P
439 2012-04-28 19:32:21 <sipa> meh, it's just a test release
440 2012-04-28 19:33:07 <luke-jr> but we have these policies for a reason ;)
441 2012-04-28 19:33:30 <luke-jr> and if they don't apply to test releases, I should be have stable RCs uploaded more..
442 2012-04-28 19:39:00 <luke-jr> *: ping
443 2012-04-28 19:39:10 <luke-jr> 0.6.1rc1 may have a serious blockchain fork issue
444 2012-04-28 19:39:41 <MtRedMining> hey guys
445 2012-04-28 19:40:03 <luke-jr> MtRedMining is using a very recent git clone, downloading the blockchain from scratch
446 2012-04-28 19:40:11 <luke-jr> he's apparently getting stuck on BIP 17 transaction http://blockchain.info/tx-index/2695263/0157f2eec7bf856d66714856182a146998910dc6fa576bec200a9fa8039459e7
447 2012-04-28 19:41:06 <gribble> New news from bitcoinrss: rebroad opened issue 1161 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1161>
448 2012-04-28 19:41:11 <MtRedMining> http://vps.mtred.com/dbg.log20k.txt
449 2012-04-28 19:41:15 <MtRedMining> for my debug log
450 2012-04-28 19:41:27 <MtRedMining> again this is the latest master from github
451 2012-04-28 19:41:59 <MtRedMining> my tree (the one in production) gets stuck at 170059, i dont have a log for that right now
452 2012-04-28 19:42:45 <MtRedMining> this one is getting stuck at 168215
453 2012-04-28 19:42:48 <sipa> are you connected to multiple nodes?
454 2012-04-28 19:43:39 <MtRedMining> yes, i've tried rescan and complete datadir wipes
455 2012-04-28 19:44:09 <MtRedMining> 4 times now, 2 times with the master it gets stuck at 168215
456 2012-04-28 19:44:25 <MtRedMining> 2 times with my tree wich is a month or so behind get stuck at 170059
457 2012-04-28 19:44:36 <MtRedMining> this is on a ubuntu 11 box i setup yesterday
458 2012-04-28 19:45:27 <sipa> if you do a complete datadir wipe, how can your tree be a month old?
459 2012-04-28 19:45:38 <MtRedMining> no.. my tree as in the src tree
460 2012-04-28 19:46:34 <MtRedMining> its not even a month old, i move to master about on april 4th or sometime
461 2012-04-28 19:46:47 <sipa> if it's a 0.6.0rc1, it will get stuck at 170059
462 2012-04-28 19:47:10 <MtRedMining> well my production is probably rc1
463 2012-04-28 19:47:27 <MtRedMining> and seems to be fine
464 2012-04-28 19:47:50 <MtRedMining> im trying to setup another box and been trying to figure this out
465 2012-04-28 19:47:56 <kinlo> so one well designed transaction and your production goes down?
466 2012-04-28 19:47:57 <sipa> i'll do a full reload of the blockchain with current master
467 2012-04-28 19:48:08 <luke-jr> sipa: master fails BIP17 test suite in the wrong case
468 2012-04-28 19:48:18 <luke-jr> bisecting
469 2012-04-28 19:48:21 <MtRedMining> kinlo, i will update when i see that the master is any better
470 2012-04-28 19:48:41 <luke-jr> MtRedMining: I recommend using 0.5.x releases for now ;)
471 2012-04-28 19:48:42 <sipa> MtRedMining: 0.6.0 final is definitely better
472 2012-04-28 19:48:46 <luke-jr> or 0.6.0.7
473 2012-04-28 19:49:07 <luke-jr> hmm, 0.6.0 is failing these tests
474 2012-04-28 19:49:08 <sipa> all 0.6.0rc1-5 have known issues
475 2012-04-28 19:50:02 <luke-jr> oh, I see why
476 2012-04-28 19:50:39 <sipa> BIP17 test case...?
477 2012-04-28 19:51:24 <luke-jr> sipa: yes, I'm ripping the tests from the BIP 17 branch, to try to reproduce this issue
478 2012-04-28 19:51:29 <luke-jr> since he's stuck on a BIP 17 txn
479 2012-04-28 19:51:50 <sipa> if the code has no BIP17 verification, how does this matter?
480 2012-04-28 19:52:05 <luke-jr> sipa: somehow, the BIP 17 txn in the mainnet blockchain is failing now
481 2012-04-28 19:52:09 <luke-jr> 0157f2eec7bf856d66714856182a146998910dc6fa576bec200a9fa8039459e7
482 2012-04-28 19:53:46 <graingert> wat
483 2012-04-28 19:54:07 <sipa> luke-jr: let's see
484 2012-04-28 19:54:15 <luke-jr> OK, BIP17 test passes after being fixed :/
485 2012-04-28 19:55:08 <luke-jr> hmm
486 2012-04-28 19:55:11 <luke-jr> these are also multisig
487 2012-04-28 19:56:16 <gribble> New news from bitcoinrss: rebroad opened issue 1162 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1162>
488 2012-04-28 20:31:26 <sipa> my git master node just finished downloading the entire chain
489 2012-04-28 20:37:32 <MtRedMining> hm. im doing a fresh clone of the master, and try again
490 2012-04-28 20:39:41 <sipa> MtRedMining: it doesn't happen to have gotten stuck with code from a few days ago?
491 2012-04-28 20:40:01 <MtRedMining> the latest the tree might be is from thursday
492 2012-04-28 20:40:13 <MtRedMining> i left it over night and firday is when i first saw this
493 2012-04-28 20:40:32 <MtRedMining> tried with my 6rc1 fork, goot the 170059 stuck
494 2012-04-28 20:40:36 <MtRedMining> tried with master
495 2012-04-28 20:40:39 <MtRedMining> and got this
496 2012-04-28 20:41:54 <sipa> there was a bug in the code that was present for a few days only, but it may have been there thursday
497 2012-04-28 20:42:14 <sipa> and 0.6.0rc1 is known to be buggy as well
498 2012-04-28 20:42:31 <MtRedMining> yea, im gonna look into that in a min
499 2012-04-28 20:42:49 <MtRedMining> might have to find a 5 branch as luke suggests
500 2012-04-28 20:42:50 <sipa> so you're just unlucky to have chosen the wrong versions (though i would not have advised to run git master or rc code on production services in any case...)
501 2012-04-28 20:43:00 <sipa> just use 0.6.0 final
502 2012-04-28 20:43:46 <MtRedMining> well, im testing a new hosting provider, didnt want to deal with it and just clone github.com/bitcoin/bitcoin.git for ease
503 2012-04-28 20:44:02 <sipa> ok, clone, "git checkout v0.6.0", compile, run
504 2012-04-28 20:46:23 <MtRedMining> ill test 6 in a min. trying with the latest to make sure it was just bad timing on a push
505 2012-04-28 20:47:19 <sipa> latest should be fine as well, but there may be other bugs of course
506 2012-04-28 21:23:30 <Samuel> I haven't checked in here in a while. How is everybody?
507 2012-04-28 21:28:48 <Joric> brainwallet.org uses 2 sources of the transaction history now - reliability matters :D
508 2012-04-28 21:33:38 <Joric> looks like http://blockexplorer.com/q/mytransactions/<address> doesn't include coinbase though
509 2012-04-28 22:22:11 <mcorlett> sipa: https://bitcointalk.org/index.php?topic=74917.msg830230#msg830230
510 2012-04-28 22:23:15 <Joric> signature -- 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa ;)
511 2012-04-28 22:24:40 <Joric> i remember it took a while day to generate 1JoricCBkW8C5m7QUZMwoRz9rBCM6ZSy96 now it's a matter of a few seconds
512 2012-04-28 22:24:56 <sipa> mcorlett: privacy is complex, and there is no magic bullet that will give it to you, but static addresses are an example of a mindset that does not help, and firstbits encourages that
513 2012-04-28 22:25:30 <sipa> and yes Joric, i know i'm doing the same thing, but I intend to change that as soon as a practical way exists for unlinkable donation addresses
514 2012-04-28 22:25:31 <gmaxwell> mcorlett: Also, I don't get what you're saying wrt coin control. In fact, if you don't reuse addresses the reference client's behavior wrt anonymity is _much_ better.
515 2012-04-28 22:26:01 <luke-jr> sipa: you forgot to mention that the Firstbits creator spammed the blockchain to register most short prefixes
516 2012-04-28 22:26:05 <gmaxwell> Coincontrol's crosslinkage avoidance actually doesn't do anything when all your addresses are only-used-once.
517 2012-04-28 22:26:43 <sipa> luke-jr: that is another argument against it (and even mentioned in the post), but not relevant here
518 2012-04-28 22:26:57 <gmaxwell> ('cause the single tranaction that links address X to Y will be the only transaction ever involving X and Y)
519 2012-04-28 22:27:40 <gmaxwell> (er, ever involving X or Y)
520 2012-04-28 22:31:20 <mcorlett> gmaxwell: What I'm saying is that it is practically impossible to be completely anonymous without coin control.
521 2012-04-28 22:31:59 <pigeons> but why does that mean we should encourage behavior that can reduce anonymity?
522 2012-04-28 22:32:19 <gmaxwell> And what I'm saying is that if you simply don't reuse addresses ever that you basically get the coin control behavior for almost free.
523 2012-04-28 22:33:33 <gmaxwell> Coincontrol is largely, though not entirely, needed because of the fact that people frequently keep reusing addresses.  Without the repeated reuse you don't have the cancerous leakage of non-privacy that eventually links all your addresses.
524 2012-04-28 22:34:17 <gmaxwell> (and sure, I support merging coin control but it's a bandaid. It's much better privacywise to avoid reuse)
525 2012-04-28 22:41:11 <mcorlett> gmaxwell: I'm sorry, I don't see how using a new address for every transaction makes you anonymous. Quite to the contrary, it /implies/ anonymity. I can see that it may make the process more tedious for the attacker, but that doesn't mean much. Re-usage is perfectly fine, but we need a) smarter automatic output selection, or b) manual output selection.
526 2012-04-28 22:42:11 <mcorlett> (a.k.a. coin control)
527 2012-04-28 22:43:07 <gmaxwell> mcorlett: Because if you use a seperate address for every transaction you never have any transitive linkages. The loss of anonymity never spreads any wider than the span of a single spend.
528 2012-04-28 22:43:39 <gmaxwell> For example if you spend all the funds you have in a transaction you'll obviously link all your addresses.  Coin control can't do anything about that.
529 2012-04-28 22:43:59 <gmaxwell> The best you can do with coin control is make sure you don't link any _more_ than what is implied by the inputs you're using.
530 2012-04-28 22:45:16 <gmaxwell> Single use addresses give you that all the time.  The only thing coin control adds on top of that (when you're already using single shot addresses) is a choice of which 'equally anonymous' (from the perspective of total number of address linkages) selections you can make.
531 2012-04-28 22:45:51 <gmaxwell> Of course not all addresses are equally anonymous so thats still useful.  But the basic problem of all your addresses becoming linked even when you don't spend all your funds at once just doesn't exist with single useage addresses.
532 2012-04-28 22:50:48 <gmaxwell> (Or saying it another way Coincontrol does two things: It tracks which addresses-that-have-balances are linked through chains of common inputs  and it lets you manually select inputs (mostly useful to avoid expanding those sets).  The first function is pointless in a world where all address use is single shot as no addresses would be linked by its metric.)
533 2012-04-28 23:01:09 <mcorlett> Right, I get all of this. What I don't understand is why practically the entire development team opposes a method of shortening addresses that are going to be used several times anyway (donations, crowdfunding, etc.); this is pretty much the only way people use Firstbits. It is and will continue to be common practice to create a new address for every new /transaction/.
534 2012-04-28 23:01:29 <mcorlett> Also, sipa mentions that "consuming the outputs of the first transaction that used a particular address, may change the firstbits mapping." I don't believe this to be true.
535 2012-04-28 23:02:05 <gmaxwell> mcorlett: It is unless you break the bitcoin pruning model.
536 2012-04-28 23:02:45 <gmaxwell> Firstbits also encourages spammy anti-social behavior... and adopting it would reward parties who have added megabytes of usebloat to the bitcoin shared transaction database.
537 2012-04-28 23:02:57 <gmaxwell> s/usebloat/useless bloat/
538 2012-04-28 23:03:58 <gmaxwell> Firstbits addresses are also particularly vulnerable to mistakes. If there were a popular crowdfunding address I would find it quite popular to register all likely typos/misremberings around that common address.
539 2012-04-28 23:04:27 <gmaxwell> And of course if you have a communication channel reliable enough to prevent the typos/misrememberings you can easily transmit a full address.
540 2012-04-28 23:04:43 <gmaxwell> s/popular/profitable/  (darn multitasking)
541 2012-04-28 23:06:34 <gmaxwell> We're prefer that people instead develop useful mechinisims for convenient address distribution for things like crowfunding that don't preclude the single use addresses which are so important to the bitcoin privacy model.
542 2012-04-28 23:07:38 <gmaxwell> For example a crowdfunding site could simply maintain a https://mycause.org/pay  URL (perhaps with /pay becoming a common standard) that could be trivially dropped into bitcoin client software. ... and the URL could easily dispense single use addresses to each requester.
543 2012-04-28 23:08:39 <Diablo-D3> gmaxwell: hey, whats the flag to make bitcoind make more than 100 future addresses
544 2012-04-28 23:08:52 <sipa> Diablo-D3: -keypool=n
545 2012-04-28 23:09:07 <sipa> (sorry, I'm not gmaxwell)
546 2012-04-28 23:09:09 <mcorlett> gmaxwell: ...and then they reach their targeted amount of money and consolidate the funds when depositing to their exchange of choice.
547 2012-04-28 23:09:36 <sipa> mcorlett: maybe, but not necessarily
548 2012-04-28 23:09:53 <sipa> and if they favor privacy, they shouldn't (and shouldn't need to)
549 2012-04-28 23:10:31 <gmaxwell> And?  The address reuse forces linkage, making it instant and mandatory. Where as bulk spend at once makes it happen sometimes.
550 2012-04-28 23:11:16 <gmaxwell> The actual observed behavior on real static donation addresses shows incremental payouts over time... which would be more private if single use addresses were uesd.
551 2012-04-28 23:11:19 <gmaxwell> er used.
552 2012-04-28 23:11:39 <mcorlett> gmaxwell: Wikileaks uses both.
553 2012-04-28 23:12:02 <mcorlett> (Am I allowed to mention them in this channel?)
554 2012-04-28 23:12:16 <gmaxwell> (E.g. https://blockexplorer.com/address/1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN http://blockexplorer.com/address/1F4Ka3nHH3Ef1P2f66AwLEqwHo6J9wFHKC )
555 2012-04-28 23:12:32 <gmaxwell> (The FSF and Wikimedia NYC respectively)
556 2012-04-28 23:13:21 <gmaxwell> (or, for example the EFF old bitcoin donation address: http://blockexplorer.com/address/1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt )
557 2012-04-28 23:15:38 <mcorlett> Here you can see Wikileaks consolidating funds from their public donation address (1HB5...), and what are assumably private ones. http://blockchain.info/tx-index/4274979/c2a8f051547c23e8d666747553dd329e295bdc330d23831f399e9b09941250df
558 2012-04-28 23:16:57 <gmaxwell> mcorlett: I don't think you're correct there, actually.
559 2012-04-28 23:17:04 <sipa> mcorlett: your argument basically is "currently, funds get linked anyway in some cases, so why not encourage linking altogether?"
560 2012-04-28 23:17:13 <gmaxwell> The other inputs there are small. I expect that they're change from previous spends of the public address.
561 2012-04-28 23:18:18 <gmaxwell> The first is clearly 1HB5 change.
562 2012-04-28 23:18:51 <gmaxwell> So is the last.
563 2012-04-28 23:21:22 <mcorlett> You are correct. I think I'll donate to a private one to see how they handle those.
564 2012-04-28 23:21:33 <sipa> Don't.
565 2012-04-28 23:22:38 <sipa> Well, unless you don't mind your funds potentially ending up in limbo.
566 2012-04-28 23:23:08 <gmaxwell> In any case, it's not really relevant.  Using oneshot addresses is still strictly superior from a privacy perspective.
567 2012-04-28 23:23:48 <gmaxwell> Even if the user's RX sides behavior is somewhat unfortunate.  It's rather difficult to manage to link _all_ your addresses when single shot addresses are being used...
568 2012-04-28 23:24:08 <gmaxwell> but fairly easy to link ~all when they aren't used.
569 2012-04-28 23:25:04 <sipa> when a deterministic chain is used as a static address, you could even do payments that spend each of your inputs separately to separate destinations
570 2012-04-28 23:25:05 <Joric> i want a service that will allow building those pictures for an arbitrary address http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html
571 2012-04-28 23:26:19 <gmaxwell> Joric: I wrote some code to dump data needed to create that kind of graph and posted dumps hoping someone would do the obvious next step. But no one did. Alas. :)
572 2012-04-28 23:28:07 <Joric> btclook.com has an interesting svg-based visualisation but only for transactions
573 2012-04-28 23:28:35 <Joric> eg http://www.btclook.com/#/txn/497e5e59111238b953e26e8b8587c2433efba8f9359920d3696efc59c30ac98c
574 2012-04-28 23:28:38 <BTC_Bear> serajewelKS could probably throw something together, if you asked really nicely.
575 2012-04-28 23:31:40 <mcorlett> Joric: Awesome visualizations.
576 2012-04-28 23:32:51 <mcorlett> Joric: See also: http://anonymity-in-bitcoin.blogspot.com/2011/09/code-datasets-and-spsn11.html
577 2012-04-28 23:33:28 <Joric> yeah i've read/downloaded all that
578 2012-04-28 23:35:08 <Joric> looks like they've used a popular plotting software that visualizes graphs but it's name is not mentioned
579 2012-04-28 23:36:02 <gmaxwell> Joric: email them?
580 2012-04-28 23:37:25 <seco> if you are curious, the one on the top is created using Gephi, and the ones on the bottom are a combination of Graphviz, for layout, and a set of visualization generating code we wrote. We used the excellent Python library Networkx, with graphviz, for the custom visualizations. Also used were the bitcointools, and R.
581 2012-04-28 23:37:26 <seco> ?
582 2012-04-28 23:39:31 <seco> (copy/pasted from one of the comments from FergalJul 25, 2011 07:44 PM)
583 2012-04-28 23:40:43 <jgarzik> pfew, that was ugly.  Got a brand new HTTP server running, using boost.asio.  Started from a boost example HTTP server that was bloody awful, spent way too much time learning boost and fixing bugs, and just now got it to the point where a JSON-RPC input is properly grok'd and replied-to.
584 2012-04-28 23:40:48 <Joric_> seco, thanks
585 2012-04-28 23:41:03 <jgarzik> C++ continues to suck, in terms of (a) debuggability and (b) compiled code size
586 2012-04-28 23:41:41 <jgarzik> thanks to templates, json_spirit_reader (copied from bitcoin) compiled to a 48MB .o file
587 2012-04-28 23:42:16 <sipa> anyone want to try my onioncat branch? it has ipv6 support, socks5 support, and tor hidden service support
588 2012-04-28 23:42:37 <seco> np, i have to thank for this great link lol; thats one of the reasons i love Bitcoin: there is always a surprise in the bush: i knew analysis of anonymity is just a question of time, but i didnt search in the past :D
589 2012-04-28 23:43:03 <sipa> ./bitcoind -proxy=127.0.0.1:9050 -connect=a57qr3ydpnyntf5k.onion:8333
590 2012-04-28 23:43:08 <da2ce7> sipa: wow that onioncat branch sounds really cool.
591 2012-04-28 23:43:17 <sipa> ^ works
592 2012-04-28 23:45:45 <sipa> phantomcircuit: ^
593 2012-04-28 23:46:11 <gmaxwell> sipa: how do you tell it is own onion address?
594 2012-04-28 23:46:21 <sipa> gmaxwell: -externalip=
595 2012-04-28 23:47:19 <sipa> but it won't recognize connections coming from the proxy as being from the tor network, so i suspect it will hand out an ipv4 address in the version message
596 2012-04-28 23:47:30 <sipa> which is actually a tremendous privacy leak
597 2012-04-28 23:47:36 <sipa> but not too hard to fix
598 2012-04-28 23:59:19 <gmaxwell> sipa: Happy? :)
599 2012-04-28 23:59:50 <gmaxwell> this is kinda odd:
600 2012-04-28 23:59:51 <gmaxwell> trying connection dnsseed.bitcoin.dashjr.org lastseen=0.0hrs