1 2012-04-27 00:34:03 <freewil> anyone here familiar with listsinceblock?
  2 2012-04-27 02:21:58 <gribble> New news from bitcoinrss: freewil opened issue 1153 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1153>
  3 2012-04-27 07:25:59 <fiddur> Why hasn't my testnet transaction gotten any confirmation?  It's done with bitcoin-qt 0.6.0.6-beta on debian 2012-03-16 09:55.  It's connected, the recipient received the notice but also sees it with 0 confirmations.  Latest block received a few seconds ago.... Any clues?
  4 2012-04-27 07:26:22 <sipa> how long has it been?
  5 2012-04-27 07:26:42 <fiddur> 11 days.
  6 2012-04-27 07:26:56 <sipa> oh, testnet
  7 2012-04-27 07:27:02 <sipa> testnet is broken
  8 2012-04-27 07:27:12 <fiddur> I thought it was only forked?
  9 2012-04-27 07:27:30 <sipa> yes, a few times
 10 2012-04-27 07:28:18 <fiddur> So, how would I go about to place my testnet clients on the same fork as e.g. blockexplorer?
 11 2012-04-27 07:28:27 <sipa> but combine that with few nodes, little mining, and the fact that old nodes keep running
 12 2012-04-27 07:28:49 <sipa> it depends on which version of the code you run
 13 2012-04-27 07:28:58 <fiddur> 0.6.0.6-beta
 14 2012-04-27 07:29:04 <fiddur> bitcoin-qt
 15 2012-04-27 07:30:28 <fiddur> Or is it simpler just to create a new wallet and start cpu-mining after each transaction?
 16 2012-04-27 07:30:36 <sipa> 0.6.1 or 0.7.0 will probably do a full reset of testnet to clean up
 17 2012-04-27 07:31:02 <sipa> yes, you should be able to find a block every 20 minutes with a cpu
 18 2012-04-27 07:31:11 <sipa> if no one else is mining
 19 2012-04-27 07:32:12 <fiddur> ok.  thank's for the input.
 20 2012-04-27 12:18:18 <Diapolo> BlueMatt: Are you on :)?
 21 2012-04-27 12:25:20 <gribble> New news from bitcoinrss: Diapolo opened issue 1154 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1154>
 22 2012-04-27 12:30:20 <gavinandresen> I just pushed v0.6.rc1 tag
 23 2012-04-27 12:36:41 <sipa> gavinandresen: it seems you didn't use an annotated tag?
 24 2012-04-27 12:37:12 <gavinandresen> yeah, I didn't bother signing it
 25 2012-04-27 12:37:26 <sipa> it seems git-describe only uses annotated ones
 26 2012-04-27 12:37:44 <gavinandresen> sigh.  Ok, I'll delete and re-upload a signed one
 27 2012-04-27 12:37:53 <sipa> sorry :)
 28 2012-04-27 12:38:10 <sipa> v0.6.0-207-g2c31cfc might be a confusing name for 0.6.1rc1
 29 2012-04-27 12:39:44 <gavinandresen> Actually, before I do... should we link against the latest OpenSSL?  I know the consensus was that the recent bug doesn't affect bitcoin....
 30 2012-04-27 12:39:51 <gavinandresen> ... but it wouldn't hurt
 31 2012-04-27 12:44:02 <sipa> i'm not exactly sure whether we link staticially or dynamically to openssl on windows?
 32 2012-04-27 12:44:26 <Diapolo> Would it be possible to create an updated qtgui_deps_1.zip for Windows if using newer SSS libs please :)?
 33 2012-04-27 12:45:04 <Diapolo> sipa: dynamically sounds wrong, as Windows has no OpenSSL libs included, right?
 34 2012-04-27 12:45:28 <gavinandresen> yeah, pretty sure we're linking statically: deps-win32.yml builds openssl
 35 2012-04-27 12:46:19 <sipa> in that case i guess we should update (though i agree the bug doesn't affect us)
 36 2012-04-27 12:47:16 <Diapolo> Who did that qtgui_deps_1.zip initially and should I open an issue for it?
 37 2012-04-27 12:47:20 <gavinandresen> I'll update and then re-tag 0.6.1rc1
 38 2012-04-27 12:55:02 <gavinandresen> ok, SIGNED v0.6.1rc1 tag pushed, with windows linking against latest openssl
 39 2012-04-27 12:57:03 <gribble> New news from bitcoinrss: Diapolo opened issue 1155 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1155>
 40 2012-04-27 12:58:15 <paulo_> in what part of the source code does it check if the block is valid?
 41 2012-04-27 12:58:44 <paulo_> i'm looking at protocol.cpp to see where it receives the block, but from there I'm lost
 42 2012-04-27 12:58:53 <sipa> paulo_: main.cpp, CheckBlock, AcceptBlock, ConnectBlock
 43 2012-04-27 13:00:59 <paulo_> is it just me, or is too much of the code in main.cpp?
 44 2012-04-27 13:01:17 <Diapolo> sipa: did you mind reading what dbenv.set_flags(DB_REGION_INIT, 1); does or if it could speedup DB code a little?
 45 2012-04-27 13:02:13 <Diapolo> paulo_: think so too, I have some problems in understanding which global belongs to which part in ;)
 46 2012-04-27 13:02:54 <sipa> paulo_: that's certainly not just you :)
 47 2012-04-27 13:03:19 <sipa> Diapolo: hmm, i doubt it will help much
 48 2012-04-27 13:20:55 <Diapolo> sipa: it doesn't need to help much, but perhaps you can bench it, it's a one-liner ;)
 49 2012-04-27 13:45:28 <paulo_> where does it check if an address has enough balance for a transaction in a block?
 50 2012-04-27 13:49:27 <paulo_> it doesn't seem to be in CheckTransaction()
 51 2012-04-27 13:49:57 <gavinandresen> tx.ConnectInputs()
 52 2012-04-27 13:51:29 <Diablo-D3> everyone, remember to vote: https://bitcointalk.org/index.php?topic=78052.0
 53 2012-04-27 13:52:51 <Diapolo> Diablo-D3: donw
 54 2012-04-27 13:52:52 <Diapolo> done
 55 2012-04-27 13:53:52 <gavinandresen> sipa: I'm re-tagging rc1, I'm bumping the name of the win32 deps file
 56 2012-04-27 13:55:54 <Diapolo> gavinandresen: Is there any place to dl the deps.zip ;)? I could imediately close one issue ^^.
 57 2012-04-27 13:56:36 <gavinandresen> I'll be rebuilding the deps.zip in just a minute, I'll upload when done
 58 2012-04-27 13:58:49 <Diapolo> great stuff!
 59 2012-04-27 14:07:39 <Diapolo> gavinandresen: can you link it here: https://github.com/bitcoin/bitcoin/issues/1155 I'm off now
 60 2012-04-27 14:51:49 <paulo_> i don't understand the purpose of double SHA256
 61 2012-04-27 14:52:36 <jeremias> it's just for fun!
 62 2012-04-27 14:53:01 <jeremias> I don't either, but as I've understood, the hashing function could be anything
 63 2012-04-27 14:57:20 <gavinandresen> jeremias: see http://crypto.stackexchange.com/questions/779/hashing-or-encrypting-twice-to-increase-security
 64 2012-04-27 15:09:37 <luke-jr> devrandom: gitian seems to still need python-vm-builder for LXC
 65 2012-04-27 15:09:49 <luke-jr> needs KVM too :/
 66 2012-04-27 15:14:47 <devrandom> luke-jr: KVM??
 67 2012-04-27 15:15:08 <luke-jr> devrandom: for make-vm-base
 68 2012-04-27 15:15:13 <luke-jr> make-base-vm*
 69 2012-04-27 15:15:29 <devrandom> not if you supply --lxc
 70 2012-04-27 15:15:39 <luke-jr> devrandom: even if you do
 71 2012-04-27 15:16:19 <devrandom> oh, I see
 72 2012-04-27 15:16:19 <luke-jr> devrandom: make-base-vm still uses kvm/vmbuilder to make it
 73 2012-04-27 15:16:47 <devrandom> you can bypass all that and make your base vm with debootstrap
 74 2012-04-27 15:16:52 <gavinandresen> wtf:  I'm getting -I"/home/ubuntu/build/openssl-1.0.0e/include"  compiling win32 bitcoind, but can't see any 1.0.0e in the latest tagged 0.6.1rc1 source tree....
 75 2012-04-27 15:16:57 <devrandom> see commented out line in make-base-vm
 76 2012-04-27 15:17:59 <devrandom> luke-jr: but you'll have to make it into an image manually
 77 2012-04-27 15:18:30 <devrandom> luke-jr: I'll try to clean that up, or if you get around to it, patch is welcome
 78 2012-04-27 15:18:51 <luke-jr> devrandom: also, libexec/on-target doesn't seem to work with normal BASH :|
 79 2012-04-27 15:19:09 <luke-jr> the "." alias for "source" is a BASHism, so won't work if you use #!/bin/sh
 80 2012-04-27 15:19:38 <davout> does anyone know how hard it would be to patch the client so that fees are taken off the sent amount, and not in addition to it ?
 81 2012-04-27 15:19:49 <devrandom> luke-jr: ok, will fix that
 82 2012-04-27 15:20:15 <drizztbsd> luke-jr: dash! :D
 83 2012-04-27 15:21:36 <devrandom> luke-jr: done
 84 2012-04-27 15:21:41 <luke-jr> hmm odd, the qemu it spawns is using a different port than gitian wants
 85 2012-04-27 15:22:00 <luke-jr> oh no
 86 2012-04-27 15:22:17 <luke-jr> for some reason, qemu is only binding 127.0.0.1
 87 2012-04-27 15:24:28 <luke-jr> devrandom: also, "source gconfig" looks for gconfig in $PWD, not script dir ;)
 88 2012-04-27 15:24:37 <drizztbsd> luke-jr: how are you using kvm to launch miner?
 89 2012-04-27 15:25:01 <luke-jr> drizztbsd: http://paste.pocoo.org/show/588052/
 90 2012-04-27 15:25:46 <drizztbsd> without X on the server?
 91 2012-04-27 15:28:06 <luke-jr> drizztbsd: this is all on my desktop, but you could certainly build KVM without X support
 92 2012-04-27 15:29:46 <devrandom> luke-jr: hmm... I should be testing before committing :-P
 93 2012-04-27 15:29:51 <devrandom> I'll work on it later
 94 2012-04-27 15:30:04 <devrandom> luke-jr: there should be no qemu with lxc
 95 2012-04-27 15:30:26 <drizztbsd> lxc is only a chroot-on-steroids
 96 2012-04-27 15:31:16 <luke-jr> drizztbsd: "only"
 97 2012-04-27 15:32:18 <luke-jr> I guess dash has a bunch of non-standard behaviour itself :/
 98 2012-04-27 15:33:05 <drizztbsd> dash should be quite POSIX
 99 2012-04-27 15:36:02 <luke-jr> drizztbsd: it seems that it sources from the script directory instead of $PWD
100 2012-04-27 15:36:20 <drizztbsd> . wants absolute path
101 2012-04-27 15:36:23 <drizztbsd> or
102 2012-04-27 15:36:26 <drizztbsd> . ./script.sh
103 2012-04-27 15:36:33 <drizztbsd> you can't use . script.sh
104 2012-04-27 15:37:05 <luke-jr> gitian does, and dash tolerates it
105 2012-04-27 15:37:26 <drizztbsd> no, dash does NOT tollerate it
106 2012-04-27 15:37:41 <drizztbsd> $ touch prova.sh ; . prova.sh
107 2012-04-27 15:37:42 <drizztbsd> dash: 1: .: prova.sh: not found
108 2012-04-27 15:37:54 <paulo_> i'm bored.
109 2012-04-27 15:37:55 <drizztbsd> $ . ./prova.sh
110 2012-04-27 15:37:56 <drizztbsd> $
111 2012-04-27 15:39:51 <luke-jr> drizztbsd: then explain gitian
112 2012-04-27 15:41:16 <drizztbsd> maybe gitian have scripts on the PATH
113 2012-04-27 15:41:34 <drizztbsd> by the way just change it :P
114 2012-04-27 15:41:37 <drizztbsd> I need to go, bye
115 2012-04-27 15:47:08 <luke-jr> amazing. looks like KVM isn't the reason gitian is slow :|
116 2012-04-27 15:58:56 <luke-jr> gavinandresen: did you bump the version on the deps input?
117 2012-04-27 15:59:38 <luke-jr> zip -r $OUTDIR/bitcoin-deps-0.0.3.zip \n3423825
118 2012-04-27 15:59:57 <luke-jr> - "bitcoin-deps-0.0.3.zip"
119 2012-04-27 16:01:11 <luke-jr> ah, you did later
120 2012-04-27 16:01:36 <luke-jr> $ grep '1.0.0' $(git ls-files)
121 2012-04-27 16:01:37 <luke-jr> src/makefile.mingw: -I"C:openssl-1.0.0d-mgwinclude"
122 2012-04-27 16:01:39 <luke-jr> src/makefile.mingw: -L"C:openssl-1.0.0d-mgw"
123 2012-04-27 16:01:40 <luke-jr> gavinandresen: ^
124 2012-04-27 16:31:45 <paulo_> do we trust timestamps on blocks and just put limits on how far it deviates from the current time?
125 2012-04-27 16:32:12 <gmaxwell> paulo_: Trust?
126 2012-04-27 16:32:19 <Diablo-D3> lol paulo_ said trust
127 2012-04-27 16:33:01 <paulo_> i mean, do we always believe them to be legitimate timestamps?
128 2012-04-27 16:33:20 <Diablo-D3> no, we believe they might exist.
129 2012-04-27 16:33:34 <gmaxwell> paulo_: the times really aren't used for much nothing other than setting the difficulty. They're restricted to the allowed range and that it.  (>median of last 11 and less then 2 hours from the current time)
130 2012-04-27 16:36:16 <paulo_> are there any implications of the fact that information lags across the network?
131 2012-04-27 16:38:53 <gmaxwell> Thanks, I was struggling with that.
132 2012-04-27 16:39:04 <paulo_> lol, had to try that
133 2012-04-27 16:39:14 <gmaxwell> "Yes, Miners on Uranus would have to set their clocks in the future to get accepted on earth at all"
134 2012-04-27 16:39:31 <Diablo-D3> man
135 2012-04-27 16:39:34 <Diablo-D3> wouldnt that be hilarious
136 2012-04-27 16:39:36 <Diablo-D3> a pool on amrs
137 2012-04-27 16:39:38 <Diablo-D3> thats so vast
138 2012-04-27 16:39:43 <Diablo-D3> it can 51% attack the earth chain and win
139 2012-04-27 16:40:10 <gmaxwell> Diablo-D3: It would have to. At 13 minutes away it would be always stale unless it was the majority.
140 2012-04-27 16:40:26 <gmaxwell> (well, not always, but mostly)
141 2012-04-27 16:40:39 <Diablo-D3> I was going to say 16
142 2012-04-27 16:40:44 <Diablo-D3> lets ask wa
143 2012-04-27 16:41:09 <gmaxwell> Depends on the orbital positions.
144 2012-04-27 16:41:22 <paulo_> "Bitcoin uses the block chain algorithm to achieve distributed consensus on who owns what coins." - very well said.
145 2012-04-27 16:41:33 <Diablo-D3> huh
146 2012-04-27 16:41:38 <gmaxwell> I think we can get as far 22 minutes apart.
147 2012-04-27 16:41:43 <Diablo-D3> 7.6 minutes
148 2012-04-27 16:41:44 <paulo_> which means i can use block chains on anything that needs distributed consensus.
149 2012-04-27 16:41:48 <Diablo-D3> which I assume is current
150 2012-04-27 16:41:48 <Lyspooner> if miners on uranus could get cheaper hash/watt then that's where all mining would occur
151 2012-04-27 16:42:05 <Diablo-D3> Lyspooner: well, they'd be better off near jupiter if they can stave off the magnetic fields
152 2012-04-27 16:42:14 <gmaxwell> paulo_: you can, but without the right incentives they may not be attack resistant.
153 2012-04-27 16:42:37 <gmaxwell> paulo_: and if you don't care about attack resistance you can achieve consensus much easier: just appoint some node to make the decisions.
154 2012-04-27 16:42:58 <Diablo-D3> THE MAN, man
155 2012-04-27 16:43:05 <gmaxwell> Lyspooner: actually, no.. without tweaks nodes on earth won't accept any of their blocks.
156 2012-04-27 16:43:12 <gmaxwell> Lyspooner: mars yes, uranus no.
157 2012-04-27 16:43:23 <Diablo-D3> yeah, uranus is quite far away
158 2012-04-27 16:43:57 <Diablo-D3> lets ask wa!
159 2012-04-27 16:44:08 <Lyspooner> gmaxwell: then tweak
160 2012-04-27 16:44:11 <Diablo-D3> 174 light minutes.
161 2012-04-27 16:54:47 <paulo_> i'm reading the bitcoin paper
162 2012-04-27 16:54:57 <paulo_> are we pruning old transactions or no?
163 2012-04-27 16:55:03 <Diablo-D3> no
164 2012-04-27 16:57:35 <paulo_> "The network is robust in its unstructured simplicity.  Nodes work all at once with little coordination.  They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis.  Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. "
165 2012-04-27 16:57:42 <paulo_> very nice.
166 2012-04-27 17:14:53 <davout> hey, could someone give me a hand for a minute ?
167 2012-04-27 17:15:14 <davout> just need someone to grep their debug.log for TXes 7dae7272a356d1340d02a81690951e7323823b9f534da1c8b120acb08b106f4c
168 2012-04-27 17:15:20 <davout> and f0dd9c4847eb6dc0f7ddb021ab8a315fb2653b8d04ff2f39f3e62bce59951177
169 2012-04-27 17:15:41 <davout> see why they appear as invalid for the network but still got sent from my bitcoind
170 2012-04-27 17:19:39 <luke-jr> AcceptToMemoryPool(): accepted f0dd9c4847
171 2012-04-27 17:19:51 <luke-jr> no sign of the other one&
172 2012-04-27 17:20:14 <davout> luke-jr: thank you very much
173 2012-04-27 17:20:24 <davout> they're originating from instawallet
174 2012-04-27 17:21:12 <davout> two users reported that they were flagged as double-spends by blockchain.info, but i was unable to verify that, since none of them appear anymore at blockchain.info or blockexplorer
175 2012-04-27 17:21:32 <davout> and now they're happily hanging in instawallet's wallet, unconfirmed
176 2012-04-27 17:21:46 <davout> any idea about how to make these go away ?
177 2012-04-27 17:22:03 <davout> i assume a rescan won't help much
178 2012-04-27 17:22:35 <Diablo-D3> remember: vote: https://bitcointalk.org/index.php?topic=78052.0
179 2012-04-27 17:22:53 <sturles> Same here.  Got f0dd9c4847 not 7dae7272a3.
180 2012-04-27 17:25:08 <davout> oh wait, yes f0dd9c4847 *is* actually valid and confirmed
181 2012-04-27 17:25:50 <davout> still have no idea how to make the other one go away :/
182 2012-04-27 17:38:23 <davout> can any of you find 62e3744257bcc04bc02a3397a441656f7578240be5182591982ebc6fd46030b7 ?
183 2012-04-27 17:38:40 <davout> i think that's the other one that's actually invalid
184 2012-04-27 17:52:33 <devrandom> luke-jr: . uses PATH, and gitian prepends libexec to PATH :-P
185 2012-04-27 17:52:58 <devrandom> gitian is slower than just compiling?
186 2012-04-27 17:53:03 <luke-jr> devrandom: much
187 2012-04-27 17:53:12 <luke-jr> devrandom: it takes like an hour to go through the "install packages" step
188 2012-04-27 17:53:14 <devrandom> why would that be?
189 2012-04-27 17:53:30 <devrandom> hm... takes a few minutes here
190 2012-04-27 17:53:42 <devrandom> oh, are you referring to make-base-vm?
191 2012-04-27 17:53:45 <luke-jr> no
192 2012-04-27 17:53:47 <luke-jr> gbuild
193 2012-04-27 17:53:58 <devrandom> then we are seeing different behavior
194 2012-04-27 17:54:01 <devrandom> I have to run
195 2012-04-27 17:54:04 <devrandom> will be on later
196 2012-04-27 17:54:14 <Diablo-D3> lol someone sent me .1337 in donations to dm
197 2012-04-27 17:54:47 <luke-jr> I should have suspected something when I confirmed I can play PS2 games in an emulator inside KVM&
198 2012-04-27 17:56:02 <Diablo-D3> ?
199 2012-04-27 19:20:33 <etotheipi_> sipa: I just implemented your HDW spec:  https://gist.github.com/2513316
200 2012-04-27 19:37:27 <etotheipi_> sipa: I just realized the labeling of the output vectors is confusing... "depth" refers to the number of recursive CKD calls, but doesn't identify which branch it's on
201 2012-04-27 19:37:46 <etotheipi_> let me see if I can regenerate it them in m/i/j/k form
202 2012-04-27 19:37:59 <etotheipi_> or maybe you can figure it out yourself... :)
203 2012-04-27 20:09:16 <devrandom> luke-jr: BTW, you can use gbuild -i to skip reverting to the base image when you build
204 2012-04-27 20:11:16 <gavinandresen> rc1 built and uploaded, gitian sigs pushed:  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.1/test/
205 2012-04-27 20:19:42 <etotheipi_> sipa: Updated the test vector output to make it easier to match key-tree coords:  included the key  M/1/1/18446744073709551615  :)
206 2012-04-27 20:19:45 <etotheipi_> https://gist.github.com/2513316
207 2012-04-27 20:31:42 <luke-jr> b9edb45129d44fb78d34986c4e24965f4fa9d4bb56b96390e045d95d113d59a5  bitcoin-deps-0.0.4.zip
208 2012-04-27 21:06:46 <sipa> etotheipi_: you use 64-bit child identifiers?
209 2012-04-27 21:44:33 <etotheipi_> sipa: oh crap...
210 2012-04-27 21:44:48 <etotheipi_> I did because I thought uint32_t was unnecessarily restrictive
211 2012-04-27 21:44:56 <etotheipi_> but I forgot the spec said to expand it to 32-bytes
212 2012-04-27 21:46:06 <etotheipi_> err... wait, that still works
213 2012-04-27 21:46:30 <etotheipi_> right... there's room for up to 256-bit child indices
214 2012-04-27 21:47:57 <etotheipi_> sipa: so is there a problem with that?
215 2012-04-27 21:49:12 <sipa> etotheipi_: well, it just needs to be enumeratable
216 2012-04-27 21:49:14 <etotheipi_> I figured if the spec allows for 32-BYTE indices, then might was let users leverage it... there may be uses I haven't thought of yet, taking advantage of random access
217 2012-04-27 21:49:29 <etotheipi_> sipa: how so?
218 2012-04-27 21:49:53 <sipa> to be able to automatically detect mew keys and chains that are being used
219 2012-04-27 21:50:07 <etotheipi_> under normal operations, yet
220 2012-04-27 21:50:23 <etotheipi_> but users may have other reasons
221 2012-04-27 21:50:32 <etotheipi_> and other uses that don't require them to be enumerable
222 2012-04-27 21:50:43 <sipa> but there is no technical reason why you couldn't use even arbitrary bytestrings as child identifiers
223 2012-04-27 21:50:52 <etotheipi_> plus, 4 billion is kinda small in that respect... some users may generate billions of keys for one reason or another
224 2012-04-27 21:51:39 <etotheipi_> I can't give you explanations of why... I just don't see why it should be restricted to 32-BIT numbers... especially when you made room for 256-bits :)
225 2012-04-27 21:52:02 <sipa> hmac-sha512 takes 1024-bit blocks as input
226 2012-04-27 21:52:59 <luke-jr> https://bitcointalk.org/index.php?topic=78301.0
227 2012-04-27 21:53:43 <sipa> etotheipi_: it might even be meaningful to exploit that
228 2012-04-27 21:54:11 <etotheipi_> sipa: how so?
229 2012-04-27 21:54:20 <sipa> restrict enumerable key ids to 32-bit numbers (or 64, but if it's not enough, you can cascade anyway.b
230 2012-04-27 21:54:31 <sipa> but let others be arbitrary bytestrings
231 2012-04-27 21:54:34 <etotheipi_> ahh
232 2012-04-27 21:54:42 <Diablo-D3> remember to vote: https://bitcointalk.org/index.php?topic=78052.0
233 2012-04-27 21:54:59 <sipa> so e.g. m/0/"extern"/k
234 2012-04-27 21:55:28 <etotheipi_> sipa: sounds good
235 2012-04-27 21:56:26 <sipa> restricted to 128 bytes
236 2012-04-27 21:56:42 <etotheipi_> if you don't mind the 1-in-2^24 chance of a hash result with 24- zero bytes up front, you can just use sha256 of the string
237 2012-04-27 21:57:08 <etotheipi_> err... 2^8^24
238 2012-04-27 21:57:23 <etotheipi_> ... you know what I mean
239 2012-04-27 21:57:32 <sipa> hmac already apecifies an extra hashing step if the key is longer than the block size
240 2012-04-27 21:57:59 <sipa> so you could really say any bytestring
241 2012-04-27 21:58:18 <etotheipi_> I meant: you can use 32-bits for enumeration, and use some hash function for bytestrings
242 2012-04-27 21:58:26 <etotheipi_> there would be no collisions
243 2012-04-27 21:58:35 <sipa> h, i see
244 2012-04-27 21:58:36 <etotheipi_> unless the hash somehow ended up with 24 zero-bytes up front
245 2012-04-27 21:59:03 <sipa> the hash would be longer than 32 bits anyway
246 2012-04-27 21:59:07 <sipa> and length matters
247 2012-04-27 21:59:27 <etotheipi_> in which case, it's really all arbitrary.... use all 32-bytes for "enumeration" or for hashes of bytestrings
248 2012-04-27 21:59:48 <sipa> overkill, i think
249 2012-04-27 21:59:59 <etotheipi_> well I mean, I don't think it needs to be specified....
250 2012-04-27 22:00:12 <sipa> unless you have a 4-byte bytestring
251 2012-04-27 22:00:48 <etotheipi_> if someone wants to treat those 32-bytes as enumerable... they can, or they can use it for byte-strings, or for ASCII text, etc...
252 2012-04-27 22:01:01 <etotheipi_> it's really up to them, there's no reason to restrict what they can do with that 32-bytes in the spec
253 2012-04-27 22:01:14 <sipa> yes, just make key ids arbitrary binary data, but the actual wallet structure defines that the account and key nodes are identfied using a 32-bit integer
254 2012-04-27 22:01:32 <etotheipi_> sipa: right
255 2012-04-27 22:02:00 <etotheipi_> but I don't see a reason to "restrict" the user to 32-bit integers
256 2012-04-27 22:02:18 <sipa> there are several layers
257 2012-04-27 22:02:29 <etotheipi_> just say any integer that fits in 32-BYTES, encoded in LE
258 2012-04-27 22:02:30 <etotheipi_> err. BE
259 2012-04-27 22:02:43 <sipa> why?
260 2012-04-27 22:03:05 <sipa> you can't possibly enumerate those anyway
261 2012-04-27 22:03:26 <sipa> and as they are enumeratable, they are numbers
262 2012-04-27 22:03:27 <etotheipi_> if I tell someone, I'm going to use key[0][10][2^48]... for any reason
263 2012-04-27 22:03:50 <etotheipi_> there's no reason they should have to say "well wait... the spec doesn't say we can use numbers bigger than that... should I still use BE?"
264 2012-04-27 22:04:27 <sipa> well, you need some encoding for the numbers
265 2012-04-27 22:04:29 <etotheipi_> it's just saying that if you're going to use a NUMBER, it should be BE encoded
266 2012-04-27 22:04:35 <etotheipi_> that's all
267 2012-04-27 22:04:42 <etotheipi_> to enforce consistency
268 2012-04-27 22:04:46 <sipa> it needs a length as wel
269 2012-04-27 22:04:48 <sipa> well
270 2012-04-27 22:04:55 <etotheipi_> why?
271 2012-04-27 22:04:55 <sipa> unless it is LE
272 2012-04-27 22:05:15 <sipa> 00000001 or 0001 is different binary
273 2012-04-27 22:05:16 <etotheipi_> did I miss something?  it's all zero padding on the high end anyway
274 2012-04-27 22:05:30 <sipa> but both are BE encodings of 1
275 2012-04-27 22:05:41 <etotheipi_> I thought the spec said that you're expanding it to 32-bytes
276 2012-04-27 22:05:52 <etotheipi_> I must've misread it, which is why we're having this disagreement
277 2012-04-27 22:05:56 <sipa> no, 32 bits
278 2012-04-27 22:06:06 <sipa> 4 bytes
279 2012-04-27 22:06:27 <sipa> i have no problem changing that, if there is a good reason
280 2012-04-27 22:06:47 <etotheipi_> oh, I implemented it as 32-bytes everytime
281 2012-04-27 22:06:56 <etotheipi_> so it would just be zero-padded out to 32-bytes regardless... because I misread that
282 2012-04-27 22:07:02 <etotheipi_> I'm really getting my bits and bytes mixed up today
283 2012-04-27 22:07:37 <sipa> :)
284 2012-04-27 22:08:18 <etotheipi_> I think the constant padding to 32-bytes is 0.01% better
285 2012-04-27 22:08:33 <etotheipi_> because it guarantees agreement on how numbers are encoded
286 2012-04-27 22:08:34 <sipa> why not 64 or 128 bytes
287 2012-04-27 22:08:45 <etotheipi_> because hashes fit nicely into 32-bytes
288 2012-04-27 22:08:51 <etotheipi_> which satisfies nearly all use cases
289 2012-04-27 22:09:03 <sipa> SHA512 has 64-byte hashes
290 2012-04-27 22:09:09 <sipa> and 128-byte blocks
291 2012-04-27 22:09:11 <etotheipi_> s/all/many/g
292 2012-04-27 22:09:39 <sipa> i see your point, but 256-bit is not "special"
293 2012-04-27 22:10:06 <sipa> and i see no reason to allow 256-bit integers as identifiers
294 2012-04-27 22:10:14 <etotheipi_> fair enough...
295 2012-04-27 22:10:21 <sipa> i prefer to say that identifiers are just binaru strings
296 2012-04-27 22:10:36 <sipa> what those strings are is up to the higher layer
297 2012-04-27 22:11:07 <etotheipi_> but I think it's worth saying that if numbers are used (such as for enumeration) that they will be BE encoded
298 2012-04-27 22:11:55 <etotheipi_> but yes, you can leave it up to the client devs to decide what to do: they can cram shakespeare in there if they want
299 2012-04-27 22:12:17 <sipa> and the wallet structure will define that account and key nodes have 32-bit or 64-bit integers encoded as 4 or 8 bytes
300 2012-04-27 22:12:19 <etotheipi_> but all clients will be using enumeration in some form... but then I have to ask why 32-bit is special
301 2012-04-27 22:12:37 <sipa> it's not, but there must be a common encoding
302 2012-04-27 22:12:56 <sipa> hell, lets just encode them as decimal ascii-encoded strings
303 2012-04-27 22:13:01 <sipa> to piss off luke
304 2012-04-27 22:13:03 <etotheipi_> lol
305 2012-04-27 22:14:27 <etotheipi_> well you have 65-byte uncompressed key, how about constant-padding up to 63 bytes to so it fits nicely into an HMAC-SHA512 block
306 2012-04-27 22:14:37 <etotheipi_> 63 is ugly, but it is special
307 2012-04-27 22:14:52 <sipa> HMAC will pad it anyway
308 2012-04-27 22:15:44 <etotheipi_> ehh... this is a pretty minor, mostly-arbitrary decision... I'll just leave it to you and follow :)
309 2012-04-27 22:15:51 <sipa> i
310 2012-04-27 22:16:04 <sipa> sorry, typo
311 2012-04-27 22:16:28 <sipa> i did not intend to suggest using imagimary numbers
312 2012-04-27 22:16:34 <etotheipi_> so the way the spec is now, the integer will be padded to 32-BITs
313 2012-04-27 22:16:55 <sipa> yes, but i like changing CKD to take a bytestring
314 2012-04-27 22:17:07 <etotheipi_> agreed
315 2012-04-27 22:17:11 <sipa> and move the 32-bit thing to the wallet structure
316 2012-04-27 22:17:42 <sipa> i also like doing key derivation always using the uncompressed key
317 2012-04-27 22:18:31 <etotheipi_> great, mainly because I already implemented it that way :)
318 2012-04-27 22:19:37 <sipa> it's slightly less clean in a way, since it makes the derivation aware of compressedness
319 2012-04-27 22:20:32 <etotheipi_> I think removing 100% of ambiguity/uncertainty in the process if worth it
320 2012-04-27 22:20:38 <etotheipi_> *is worth it
321 2012-04-27 22:20:54 <sipa> agree
322 2012-04-27 22:21:09 <etotheipi_> and implementation-wise, it's pretty clean:  my uncompress func returns the input if it's already uncompressed
323 2012-04-27 22:21:19 <etotheipi_> so it's one extra line of code
324 2012-04-27 22:22:47 <sipa> etotheipi_: btw, i really like having two implementations at the same time :)
325 2012-04-27 22:23:33 <etotheipi_> sipa: great.  I just reached a super-stable dev milestone in Armory... so I thought it was a good time to upgrade my wallet spec and break it all :)
326 2012-04-27 22:56:19 <etotheipi_> alright sipa:  here's the update output:  https://gist.github.com/2513316
327 2012-04-27 22:58:14 <sipa> etotheipi_: i'll implement a similar test in a few days
328 2012-04-27 23:24:19 <luke-jr> sipa: y troll?
329 2012-04-27 23:39:22 <etotheipi_> what happened to roconner?  I haven't heard from him in months
330 2012-04-27 23:45:38 <sipa> he's often in #haskell
331 2012-04-27 23:50:18 <etotheipi_> anyone have moral objections to using VAR_INTs in new data formats?  (such as wallet files)
332 2012-04-27 23:52:35 <etotheipi_> (or did other devs vow to never touch them more than they have to?)
333 2012-04-27 23:54:48 <luke-jr> etotheipi_: I think it would be better to use some varint standard, but I'll admit to using bitcoin varints in new stuff myself&
334 2012-04-27 23:55:12 <luke-jr> etotheipi_: I'd pose the question on the ML
335 2012-04-27 23:56:40 <sipa> bitcoin's varint is silly :)
336 2012-04-27 23:56:53 <sipa> and i don't mind using varints, but only in storage-size-limited settings
337 2012-04-27 23:58:15 <etotheipi_> well maybe that's it... my wallet file is not really size limited:  at 250 bytes for a block of address data, it really doesn't matter if I reserve 4 bytes for each of two fields that are normally 1 byte
338 2012-04-27 23:58:52 <luke-jr> IMO, the only problem with bitcoin varints are that they have limited size :p
339 2012-04-27 23:59:12 <luke-jr> and aren't a standard
340 2012-04-27 23:59:17 <luke-jr> but nothing bitcoin is standard :/
341 2012-04-27 23:59:22 <etotheipi_> doesn't BER/DER address this?
342 2012-04-27 23:59:30 <etotheipi_> I don't know enough about it, though
343 2012-04-27 23:59:32 <luke-jr> that would be ironic