1 2011-11-12 00:11:52 <gmaxwell> luke-jr: so I'm thinking that as a useful security improvement, mining nodes ought to be smart enough to detect network partitions and to stop adding transactions (or only add 'trusted' txn) to blocks when they suspect there may be a parition. (They'd keep mining of course, hoping that they're on the wining side of any partition) Do you have any thoughts on what metrics would be acceptable for this.
  2 2011-11-12 00:12:24 <luke-jr> gmaxwell: I see no reason to stop accepting txns
  3 2011-11-12 00:14:56 <gmaxwell> luke-jr: imagine that the EU and and US were mostly partitioned due to some crazy cable cuts/terrorist attack whatever. People could spend on both sides.. get many confirmations.. but only one side would survive.
  4 2011-11-12 00:15:36 <luke-jr> gmaxwell: that's why you get a warning when the hashrate dropoff is detected on your client
  5 2011-11-12 00:15:37 <gmaxwell> The vulnerability would be greatly reduced if both sides stopped processing txn during such an event automatically... knowing that there is a chance the txn they're validating could end up on the losing side.
  6 2011-11-12 00:15:57 <makomk> In theory it only takes one person with a connection across to stop the partition.
  7 2011-11-12 00:15:58 <luke-jr> miners are no better off at detecting it than users
  8 2011-11-12 00:16:25 <luke-jr> but if miners stop accepting txns altogether, it makes recovery harder
  9 2011-11-12 00:16:36 <gmaxwell> makomk: yes, in _theory_. But seeming redundant infrastructure often has shared fate.
 10 2011-11-12 00:16:55 <makomk> Indeed.
 11 2011-11-12 00:16:57 <gmaxwell> luke-jr: how does it make recovery harder, except a bigger backlog?
 12 2011-11-12 00:17:13 <luke-jr> gmaxwell: bigger backlog is what i meant
 13 2011-11-12 00:17:58 <luke-jr> it should be up to clients to refuse to Confirm transactions when they detect a split
 14 2011-11-12 00:18:04 <gmaxwell> Yes, slow txn after an unspeakably severe network partition is a pretty boring problem compared to a lot of doublespending activity.
 15 2011-11-12 00:18:24 <gmaxwell> In particular, a shutdown behavior would discourage trouble makers from intentionally bringing about such a partition.
 16 2011-11-12 00:18:50 <gmaxwell> luke-jr: I guess you're right that the client part is necessary and sufficient. Fair enough.
 17 2011-11-12 00:19:03 <graingert> gmaxwell: the connection algorithm could be altered to use a distributed algorithm that protects against splits
 18 2011-11-12 00:19:26 <graingert> eg a circle of nodes
 19 2011-11-12 00:19:44 <gmaxwell> graingert: randomly wired graphs already have pretty fantastic properties... and they're immune to gaming behavior.
 20 2011-11-12 00:20:17 <gmaxwell> graingert: vs if the nodes tried to achieve some particular well distributed property an attacker could game it to create cuts.
 21 2011-11-12 00:20:27 <graingert> the fact that a single connection can ruin a split
 22 2011-11-12 00:20:30 <graingert> is sufficient to me
 23 2011-11-12 00:20:33 <graingert> tbh
 24 2011-11-12 00:20:46 <graingert> taking advantage of multicast would be pretty cool
 25 2011-11-12 00:21:30 <gmaxwell> graingert: nontrivial partitions happen on the internet with some regularity.. usually not geographic ones (though e.g. see how we lost most of the middle east/india two years ago) but ones between providers... often due to human error with massive shared fate.
 26 2011-11-12 00:22:24 <graingert> if bitcoin became "big"
 27 2011-11-12 00:22:36 <graingert> ensuring the internet did not split will become even more important
 28 2011-11-12 00:23:07 <luke-jr> anyone remember when some large portion of internet traffic US->US got rerouted through China for some time period?
 29 2011-11-12 00:23:17 <graingert> oh dear
 30 2011-11-12 00:23:18 <graingert> that
 31 2011-11-12 00:23:19 <gmaxwell> we can make bitcoin splits less likely by providing non-internet links between big miners.
 32 2011-11-12 00:23:20 <graingert> lol
 33 2011-11-12 00:23:32 <luke-jr> gmaxwell: good idea
 34 2011-11-12 00:23:45 <luke-jr> except perhaps not necessarily miners
 35 2011-11-12 00:23:46 <graingert> HAM radio
 36 2011-11-12 00:23:52 <graingert> maybe use the ionosphere
 37 2011-11-12 00:24:04 <luke-jr> graingert: yeah, peer with whoever talks on HAM radio :D
 38 2011-11-12 00:24:15 <gmaxwell> graingert: I've tried to get people to do an HF bitcoin link with me between the US and europe but I can't find a taker on the europe side.
 39 2011-11-12 00:24:25 <graingert> bounce it off sky's satellite
 40 2011-11-12 00:24:46 <graingert> gmaxwell: I know a wireless society
 41 2011-11-12 00:24:50 <gmaxwell> Satellite is often kinda tricky.. there is now a lot of internet reliance at the ground stations.
 42 2011-11-12 00:25:11 <graingert> gmaxwell: sky's satalite bounces irrispectively
 43 2011-11-12 00:26:07 <graingert> gmaxwell: okay talking to someone from SOWN now
 44 2011-11-12 00:26:17 <gmaxwell> bitcoin via moonbounce. ;)
 45 2011-11-12 00:26:23 <roconnor> gmaxwell: are you serious about a radio link?
 46 2011-11-12 00:26:27 <luke-jr> HAM is probably good
 47 2011-11-12 00:26:33 <luke-jr> UDP HAM ideally
 48 2011-11-12 00:26:36 <gmaxwell> roconnor: sure.
 49 2011-11-12 00:27:01 <graingert> Eliel: tracking would be insane
 50 2011-11-12 00:27:09 <graingert> microwaves are much better
 51 2011-11-12 00:27:14 <gmaxwell> Eliel: sounds like the plot for a superman villian.. "I'll clame its for comms but I'll really use it as a reflector for a DEATH BEAM"
 52 2011-11-12 00:27:26 <Eliel> yep, would need quite advanced tracking :)
 53 2011-11-12 00:27:31 <Eliel> gmaxwell: haha, yep :)
 54 2011-11-12 00:27:35 <roconnor> gmaxwell: do we need to transmit transactions or just blocks?
 55 2011-11-12 00:27:47 <luke-jr> just blocks imo
 56 2011-11-12 00:27:49 <gmaxwell> roconnor: I'd just transmit blocks. And probably pruned blocks.
 57 2011-11-12 00:27:54 <Eliel> blocks is sufficient.
 58 2011-11-12 00:28:08 <roconnor> gmaxwell: pruned blocks seems insufficent
 59 2011-11-12 00:28:18 <graingert> gmaxwell: SUWS*
 60 2011-11-12 00:28:23 <gmaxwell> roconnor: you'd have to trust that it was actually validated.
 61 2011-11-12 00:28:36 <graingert> gmaxwell: http://suws.susu.org/index.php/Southampton_University_Wireless_Society
 62 2011-11-12 00:30:07 <luke-jr> speaking of netsplits&
 63 2011-11-12 00:30:16 <graingert> luke-jr: that was excess flood
 64 2011-11-12 00:30:30 <luke-jr> but anyhow, IMO HAM should be as anonymous as possible-- ie, not publish where the links are
 65 2011-11-12 00:30:44 <luke-jr> graingert: yeah, packet loss = delayed traffic = all of it hits Freenode at once
 66 2011-11-12 00:31:01 <graingert> IC
 67 2011-11-12 00:33:01 <Eliel> the wlans I've used so far have proved to be very unusable if there's a lot of users.
 68 2011-11-12 00:33:02 <JFK911> like 802.11s?
 69 2011-11-12 00:33:09 <graingert> Eliel: an automated metal grappel
 70 2011-11-12 00:33:18 <graingert> that can fire and connect between divices
 71 2011-11-12 00:33:23 <luke-jr> Eliel: GSM?
 72 2011-11-12 00:33:26 <luke-jr> GPRS
 73 2011-11-12 00:33:29 <graingert> powerfull enough to penetrate through people
 74 2011-11-12 00:34:12 <luke-jr> Motive for murder: the victim was blocking his direct line of sight to his network link
 75 2011-11-12 00:34:17 <Eliel> luke-jr: GSM and 3G fit the bill but they're rather ... umm. specific tech.
 76 2011-11-12 00:34:32 <luke-jr> 3G isn't something you can run at home :/
 77 2011-11-12 00:34:38 <luke-jr> GSM/GPRS is
 78 2011-11-12 00:34:52 <Eliel> interesting
 79 2011-11-12 00:34:52 <luke-jr> provided it's low-power
 80 2011-11-12 00:35:08 <luke-jr> and not interfering with others I presume
 81 2011-11-12 00:35:39 <phantomcircuit> GSM is pretty slow actually
 82 2011-11-12 00:37:13 <luke-jr> phantomcircuit: fast enough for blocks!
 83 2011-11-12 00:37:20 <phantomcircuit> maybe
 84 2011-11-12 00:37:32 <Eliel> JFK911: 802.11s doesn't quite fit the bill since it relies on the easily congested links made with wlan standard.
 85 2011-11-12 00:37:34 <phantomcircuit> fast enough for blocks
 86 2011-11-12 00:37:42 <phantomcircuit> maybe fast enough for transactions
 87 2011-11-12 00:59:22 <roconnor> Ugh!
 88 2011-11-12 00:59:35 <roconnor> the alternate stack is cleared on each call to EvalScript
 89 2011-11-12 00:59:44 <roconnor> this protocol is like a minefield
 90 2011-11-12 01:00:01 <roconnor> anyone want to make a note in the wiki?
 91 2011-11-12 01:02:29 <roconnor> To be more specific, the alternate stack is effectively cleared between when the publickey script and the sigature script are executed.
 92 2011-11-12 01:03:28 <etotheipi_> ahh.. I always wondered about that (I guess I could've just looked in the src code)
 93 2011-11-12 01:04:19 <roconnor> TD is probably more careful than me
 94 2011-11-12 01:07:29 <roconnor> it looks like bitcoinj doesn't support non-standard transactions.
 95 2011-11-12 01:07:51 <roconnor> but I was told that there are non-standard transactions in the mainline
 96 2011-11-12 01:08:03 <roconnor> oh wait, maybe bitcoinj doesn't verify transactions
 97 2011-11-12 01:08:56 <etotheipi_> btw, I don't remember any scripts exercising the alt stack, but I did extract every non-std tx from the testnet, last week
 98 2011-11-12 01:09:09 <etotheipi_> there's some pretty elaborate ones in there, if you're interested in seeing them
 99 2011-11-12 01:09:27 <etotheipi_> err... they do use the alt stack, but not between TxNew.script and TxOld.script
100 2011-11-12 01:11:32 <etotheipi_> https://github.com/etotheipi/PyBtcEngine/blob/master/testnetNonStdScript.txt  -- I found them really useful for debugging my scripting engine
101 2011-11-12 01:12:31 <roconnor> etotheipi_: thanks
102 2011-11-12 01:13:04 <etotheipi_> https://github.com/etotheipi/PyBtcEngine/blob/master/scriptEvalStackState.txt
103 2011-11-12 01:13:11 <pumpkin> roconnor: still planning on doing it in coq?
104 2011-11-12 01:13:14 <etotheipi_> that is the intermediate output of the scripts at every step
105 2011-11-12 01:14:03 <roconnor> pumpkin: heh, not really
106 2011-11-12 01:14:33 <roconnor> etotheipi_: does that mean you know if numbers are big or little endian?
107 2011-11-12 01:14:56 <etotheipi_> in scripts, most numbers are big endian
108 2011-11-12 01:15:32 <roconnor> etotheipi_: really?  I think they are little endian, but I have very little confidence
109 2011-11-12 01:15:35 <etotheipi_> but it's not always the case, I can double check for you on any particular number
110 2011-11-12 01:15:44 <etotheipi_> the public key integers are stored in big-endian (in the 65-byte public key)
111 2011-11-12 01:15:52 <roconnor> yes that is true
112 2011-11-12 01:16:10 <etotheipi_> hold on, I'll check
113 2011-11-12 01:16:28 <roconnor> etotheipi_: you need to run an operations that overflows 256 with OP_ADD
114 2011-11-12 01:17:34 <etotheipi_> okay, var_ints are little endian
115 2011-11-12 01:17:35 <roconnor> etotheipi_: are you building test scripts?
116 2011-11-12 01:17:58 <roconnor> cause it would be great to build a test script that fails if then endianess is implemented wrong
117 2011-11-12 01:18:16 <etotheipi_> so you're right, most numbers are little endian
118 2011-11-12 01:18:32 <roconnor> and another if the alternate stack isn't cleared between pubkey script and signing script
119 2011-11-12 01:18:56 <pumpkin> wait, there are differing endiannesses in the protocol?
120 2011-11-12 01:18:58 <pumpkin> that's kinda weird
121 2011-11-12 01:19:09 <etotheipi_> the endianness is a disaster
122 2011-11-12 01:19:18 <roconnor> pumpkin: the difference is roughly that bitcoin is all little endian and openssl stuff is big endian
123 2011-11-12 01:19:25 <pumpkin> ouch
124 2011-11-12 01:19:31 <pumpkin> and openssl shit is encoded into the protocol?
125 2011-11-12 01:19:42 <roconnor> yep
126 2011-11-12 01:19:44 <roconnor> directly
127 2011-11-12 01:19:55 <pumpkin> sounds like a blast for mr. reimplement it all in pure haskell
128 2011-11-12 01:20:18 <pumpkin> :P
129 2011-11-12 01:20:19 <roconnor> pumpkin: oh, and I don't think bitcoin runs properly on non Intel arch
130 2011-11-12 01:20:33 <pumpkin> roconnor: for reasons other than endianness?
131 2011-11-12 01:20:40 <roconnor> for endianness
132 2011-11-12 01:20:53 <pumpkin> oh, so anything big-endian
133 2011-11-12 01:21:00 <roconnor> ya
134 2011-11-12 01:21:04 <roconnor> I guess that's what I mean
135 2011-11-12 01:21:06 <pumpkin> anyone have an old ppc?
136 2011-11-12 01:21:13 <etotheipi_> I think functional programming language will be excellent platform for BTC
137 2011-11-12 01:21:14 <pumpkin> or even a new ppc :P
138 2011-11-12 01:21:24 <roconnor> etotheipi_: I have a Haskell implementation
139 2011-11-12 01:21:27 <etotheipi_> at least the protocol
140 2011-11-12 01:21:37 <pumpkin> roconnor accidentally the whole thing
141 2011-11-12 01:21:38 <etotheipi_> err.. the computational
142 2011-11-12 01:21:43 <roconnor> of the core block verification engine
143 2011-11-12 01:22:12 <etotheipi_> I'll tell you the most confusing endianness
144 2011-11-12 01:22:12 <roconnor> the scripting langauge is incomplete; I'm working on supporting nonstandard transactions
145 2011-11-12 01:22:22 <etotheipi_> in OP_CHECKSIG
146 2011-11-12 01:22:59 <etotheipi_> you have to attach a little-endian hashcode... then hash the value, and convert to big-endian before ECDSA signing
147 2011-11-12 01:23:05 <pumpkin> lol
148 2011-11-12 01:23:14 <pumpkin> nice
149 2011-11-12 01:23:18 <pumpkin> I gotta go, but will bbiab
150 2011-11-12 01:24:09 <etotheipi_> well, that file I gave you with non-std scripts is invaluable
151 2011-11-12 01:24:14 <etotheipi_> but only test ones that have been spent
152 2011-11-12 01:24:43 <etotheipi_> people can put anything in the TxOut script, but you don't know if it's a "legit" script until you see them spend it
153 2011-11-12 01:24:54 <roconnor> etotheipi_: right
154 2011-11-12 01:25:05 <etotheipi_> there's quite a few confusing ones: like the first 6 or so in that file that look like pubkey scripts... but contain 6 extra bytes
155 2011-11-12 01:25:27 <etotheipi_> do you have OP_CHECKSIG implemented?
156 2011-11-12 01:25:32 <roconnor> yes
157 2011-11-12 01:25:40 <etotheipi_> okay, well that's the worst part
158 2011-11-12 01:26:24 <roconnor> oh, maybe I haven't done the signature filtering
159 2011-11-12 01:26:54 <etotheipi_> I mean, have you gotten to the part with hashcodes, txCopy, and actually signing/verifying?
160 2011-11-12 01:26:57 <etotheipi_> because that's a total bitch
161 2011-11-12 01:27:52 <roconnor> yep
162 2011-11-12 01:28:01 <roconnor> though txCopy isn't so hard in an immutable language :P
163 2011-11-12 01:28:09 <etotheipi_> https://github.com/etotheipi/PyBtcEngine/blob/master/unittest.py
164 2011-11-12 01:28:14 <roconnor> since everything is a copy (ish)
165 2011-11-12 01:28:27 <etotheipi_> the bottom of that file contains a 2-of-2, 2-of-3, and a OP_CHECKMULTISIG
166 2011-11-12 01:28:42 <etotheipi_> both TxOut script and TxIn script spending them
167 2011-11-12 01:28:52 <roconnor> etotheipi_: python implementation?
168 2011-11-12 01:29:11 <etotheipi_> yes, I'm putting together a ton of tools in python... eventually a client
169 2011-11-12 01:29:50 <roconnor> nice
170 2011-11-12 01:30:02 <roconnor> I'd be happy to copy your tests :D
171 2011-11-12 01:30:09 <etotheipi_> go for it
172 2011-11-12 01:30:22 <etotheipi_> those three tests at the bottom are all you need for upcoming multi-sig tx's
173 2011-11-12 01:30:32 <etotheipi_> if they ever make it into the client
174 2011-11-12 01:30:53 <etotheipi_> they're probably overkill for it
175 2011-11-12 01:31:01 <roconnor> well, I want to be able to verify everything in testnet
176 2011-11-12 01:31:11 <roconnor> everything that is executed
177 2011-11-12 01:31:42 <etotheipi_> https://github.com/etotheipi/PyBtcEngine/blob/master/scriptEvalStackState.txt again, that's the intermediate output of each of those three tests
178 2011-11-12 01:31:53 <etotheipi_> there's like 30 opcodes each
179 2011-11-12 01:32:05 <etotheipi_> if you can handle that, you are in really good shape
180 2011-11-12 01:53:24 <roconnor> etotheipi_: for me, my addBlock code is what is still a mess
181 2011-11-12 01:53:52 <etotheipi_> you mean, updating your internal blockchain with a new block?
182 2011-11-12 01:54:37 <roconnor> mostly checking all the things you need to check before adding a block
183 2011-11-12 01:54:53 <etotheipi_> I had quite a battle with mine
184 2011-11-12 01:54:57 <roconnor> checking timestamps, recalculating difficulties, making sure transactions are final
185 2011-11-12 01:55:04 <etotheipi_> oh, I don't actually do that
186 2011-11-12 01:55:21 <roconnor> it is so complicated that even satoshi got it wrong
187 2011-11-12 01:55:28 <etotheipi_> I believe it
188 2011-11-12 01:55:33 <etotheipi_> I've seen the lists of things to check
189 2011-11-12 01:56:00 <etotheipi_> I'm skipping that step because it's going to be godawful slow in Python, and even Gavin said that normal clients probably won't need to be doing it in the future
190 2011-11-12 01:56:03 <roconnor> oh an you have to round all the calcualtions eactly the right way
191 2011-11-12 01:56:50 <etotheipi_> for me, the fact that the block made it into my blockchain is evidence enough that it's valid:  all the miners are verifying it for me :)
192 2011-11-12 01:57:20 <roconnor> etotheipi_: unless you have been isolated from the network and are being scammed :P
193 2011-11-12 01:57:28 <etotheipi_> ...except for that
194 2011-11-12 01:58:25 <etotheipi_> I had to make some... tradeoffs... I knew that was going to be a bitch, and I didn't think it was entirely necessary, so I decided to skip it
195 2011-11-12 01:58:32 <roconnor> it's reasonable :P
196 2011-11-12 01:59:09 <etotheipi_> my plan is actually to just to put in very light networking code, and access my bitcoin/bitcoind node through a localhost socket
197 2011-11-12 01:59:13 <roconnor> I don't have any features like wallets sending transactions, or even a decent network connection.
198 2011-11-12 01:59:26 <etotheipi_> then my node can do all the complicated verification and networking
199 2011-11-12 01:59:40 <etotheipi_> and my python code can sit back and only worry about making/receiving txsw
200 2011-11-12 01:59:42 <roconnor> ya, I only connect to localhost :D
201 2011-11-12 02:00:04 <etotheipi_> Well I"m sure you know, too... there's a LOT of details
202 2011-11-12 02:00:13 <etotheipi_> SelectCoins was a bitch
203 2011-11-12 02:00:27 <gmaxwell> selectcoins isn't normative at least
204 2011-11-12 02:00:27 <roconnor> ooh, my funny transactions on testnet have a confirmation
205 2011-11-12 02:00:29 <etotheipi_> and I'm workign on wallets and wallet encyrption now
206 2011-11-12 02:00:59 <gmaxwell> you could do that crazy thing someone on the forums suggested... just take inputs in order of smallest to largest and stop when you reach the required output size. :)
207 2011-11-12 02:01:19 <etotheipi_> I think I actually came up with a really good idea.... and it seems to work really well
208 2011-11-12 02:01:36 <etotheipi_> write a method for *evaluating* a SelectCoins answer
209 2011-11-12 02:01:44 <etotheipi_> put a lot of time into getting it right
210 2011-11-12 02:01:45 <gmaxwell> link to a non-linear integer programming solver. and let it handle it?
211 2011-11-12 02:02:01 <etotheipi_> In my case, my evaluator spits out six scores
212 2011-11-12 02:02:14 <etotheipi_> for tx_size, num-addr-combined, anonymity, etc
213 2011-11-12 02:02:25 <etotheipi_> you can choose some weights for each score
214 2011-11-12 02:02:31 <roconnor> http://blockexplorer.com/testnet/rawtx/362bbbf21f6d0b47ee2e45f975b4c2bd81ed49ba371cbd618835e91b00a66006
215 2011-11-12 02:02:37 <gmaxwell> Hopefully fee/priority is one/two of them?
216 2011-11-12 02:02:38 <roconnor> "ver":971503818
217 2011-11-12 02:02:40 <roconnor> :)
218 2011-11-12 02:02:50 <etotheipi_> then just randomize the order of your coins 1000 times
219 2011-11-12 02:03:02 <etotheipi_> and pick the one with the best score (yes allowFree is my top priority)
220 2011-11-12 02:03:27 <gmaxwell> etotheipi_: that kind of solver will fail impressively if your wallet gets bloated with a large number of 'useless' txn.
221 2011-11-12 02:03:41 <etotheipi_> haha, well that's the start of it
222 2011-11-12 02:03:50 <etotheipi_> I also have a dozen non-random inputs
223 2011-11-12 02:03:50 <gmaxwell> E.g. if I send you a bunch of 1e-8 coins you'll probably fail to reach a solution.
224 2011-11-12 02:04:30 <etotheipi_> every time I think of a solution for one type of coin-selection-problem, I write up a quick method and throw it in with the randoms
225 2011-11-12 02:04:42 <gmaxwell> In any case, any weight of those optimization targets could be stated as a non-linear integer program, and the relaxiation can be linearized and solved with branch/bound/cut.
226 2011-11-12 02:04:56 <etotheipi_> I'm sure simplex might help
227 2011-11-12 02:05:31 <gmaxwell> Might be fun to have a contest.
228 2011-11-12 02:05:50 <etotheipi_> but yeah, I didn't mean to suggest COMPLETELY random, but it prevents you from having to come up with ONE algorithm... you can throw in dozens and the best one for the moment wins
229 2011-11-12 02:06:00 <etotheipi_> and it's easy to change the weights to just change the prioiritization
230 2011-11-12 02:06:10 <etotheipi_> perhaps I want max anonymity on this tx
231 2011-11-12 02:06:27 <gmaxwell> You've made the measurement code... generate a bunch of fake wallets and transactions to evaluate against them. .. publish half the fake problems... people submit code... then you score the winners on the hidden set.
232 2011-11-12 02:06:58 <etotheipi_> that's what I did to test my algorithm actually
233 2011-11-12 02:07:02 <etotheipi_> for myself
234 2011-11-12 02:07:25 <etotheipi_> but it does seem like it would make a good competition
235 2011-11-12 02:07:41 <gmaxwell> So how well does your work compared to the solver it bitcoin e.g. for best txn size?
236 2011-11-12 02:08:20 <roconnor> Also my transaction uses nHashType = 0xa0
237 2011-11-12 02:09:01 <etotheipi_> but I'm extremely happy with the outputs... sometimes it adds one too many input addresses... but it always finds a solution I'm happy with
238 2011-11-12 02:09:09 <gmaxwell> etotheipi_: it the testing I did it seemed to always pick the smallest tx data size (of the txn it was considering). Does a pretty good job at that.
239 2011-11-12 02:09:48 <etotheipi_> now that you mention it, I will have to re-run with some really challenging wallets: to see if I can find free tx in difficult situations
240 2011-11-12 02:10:30 <gmaxwell> yea, the flaw with the current code is that its priority blind .. and the fact that the first cut is only 6 confirms means that it will often end up generating a fee needing txn when it wouldn't have to.
241 2011-11-12 02:10:40 <gmaxwell> (well, depending on the composition of the wallet)
242 2011-11-12 02:11:01 <etotheipi_> one of my priority/scores is number of trailing zeros
243 2011-11-12 02:11:10 <gmaxwell> \0/
244 2011-11-12 02:11:17 <etotheipi_> and if the zeros are close, then size of change output compared to target
245 2011-11-12 02:11:19 <roconnor> trailing zeros?
246 2011-11-12 02:11:23 <gmaxwell> Yea, cancel out that dust.
247 2011-11-12 02:11:33 <gmaxwell> roconnor: dust elimination.
248 2011-11-12 02:11:52 <etotheipi_> and one of my filters targets making tx's twice as big as target: remove small change outputs, improve anonymity
249 2011-11-12 02:11:55 <gmaxwell> Now that all the pool are giving out full precision payments the whole fresh address for change is a complete waste of time.
250 2011-11-12 02:12:02 <gmaxwell> You can almost always identify people's change now.
251 2011-11-12 02:12:37 <roconnor> meh, I don't even pretend that bitcoin is anonymous
252 2011-11-12 02:12:41 <etotheipi_> right... well if you send someone 1 BTC, that 10000000, and if you send 1.274823 that's 127482300
253 2011-11-12 02:12:49 <gmaxwell> forget anonymous. Anonymous shouldn't be a goal.
254 2011-11-12 02:12:51 <etotheipi_> the first has 8 trailing zeros
255 2011-11-12 02:12:55 <etotheipi_> the second has only 2
256 2011-11-12 02:13:25 <gmaxwell> roconnor: the problem isn't lacking anonymity, it's lacking _privacy_. It sucks when bitcoin is more subject to snooping by your neighbor, coworkers, family, etc. than traditional banking.
257 2011-11-12 02:13:30 <etotheipi_> if one is output the other is change:  I look for txs that are within 1 trailing zero of each other
258 2011-11-12 02:13:35 <gmaxwell> 'anonymity' in bitcoin is our only source of privacy.
259 2011-11-12 02:13:46 <etotheipi_> extra credit if the change tx has more trailing zeros
260 2011-11-12 02:14:32 <etotheipi_> and to my surprise, I got a lot of selections that led to say, a target 1.24, and change of 1.3
261 2011-11-12 02:14:47 <roconnor> gmaxwell: I had an idea once about using homomorphic encryption to encrypt transaction amounts
262 2011-11-12 02:15:15 <etotheipi_> how do you do that in BTC
263 2011-11-12 02:15:40 <etotheipi_> I'm pretty sure you can't hide the amount
264 2011-11-12 02:15:43 <roconnor> well it wouldn't be bitcoin anymore since the protocol would have to be vastly different
265 2011-11-12 02:15:48 <gmaxwell> hm. so you could see the outputs add to the input.. but not what the ouputs are?
266 2011-11-12 02:15:55 <roconnor> gmaxwell: exactly
267 2011-11-12 02:16:12 <gmaxwell> cute. a zillion X data expansion though?
268 2011-11-12 02:16:12 <roconnor> though you still need to make sure that the balances aren't negative
269 2011-11-12 02:16:25 <bd_> actually the only parties that need to know the outputs add to the input are the ones who eventually receive the coin
270 2011-11-12 02:16:26 <roconnor> but it appears that this is still doable
271 2011-11-12 02:16:35 <roconnor> (or at least with very high probability)
272 2011-11-12 02:16:53 <gmaxwell> bd_: hm? the network needs to know that you're not pulling coin out of thin air.
273 2011-11-12 02:16:55 <bd_> you could in principle encrypt all the txouts with an ephemeral key, and include this key in any txins referencing it, as well as encrypted to the recipient keys
274 2011-11-12 02:17:24 <gmaxwell> ah, then only the miner mining it would see it.. but then he could throw out the key and forget.
275 2011-11-12 02:17:28 <roconnor> gmaxwell: ya, the coinbase won't really be hidden; everyone will know its value
276 2011-11-12 02:17:32 <bd_> gmaxwell: no, only the people receiving the coins need to be able to do validation. If you make an illegal transaction you simply waste any coins you reference
277 2011-11-12 02:17:47 <bd_> (since the resulting coin would be unspendable)
278 2011-11-12 02:18:06 <bd_> downside is that you have to validate the entire transaction chain in order to accept a coin
279 2011-11-12 02:18:16 <gmaxwell> bd_: I was just about to say...
280 2011-11-12 02:18:19 <bd_> which could be extremely expensive
281 2011-11-12 02:18:28 <roconnor> gmaxwell: the miner just needs to know that the sum of the inputs equals the sum of the outputs; not the values themselves.
282 2011-11-12 02:18:36 <gmaxwell> especially since it grows exponentially as coins are merged and split.
283 2011-11-12 02:19:06 <bd_> roconnor: yes, but if you find some way to hide this information we get back to the problem of who validates this sum
284 2011-11-12 02:19:12 <roconnor> bd_: my idea was to make it publically verifiable that the sum of the inputs equals the sum of the outputs in each transaction.
285 2011-11-12 02:19:17 <bd_> and then we have the validating-entire-txn-tree-on-recipt problem
286 2011-11-12 02:19:37 <bd_> roconnor: how do you validate txins then, though?
287 2011-11-12 02:19:40 <roconnor> bd_: the miner (and strong clients) can do the verification; like it is done now.
288 2011-11-12 02:19:45 <gmaxwell> bd_: roconnor proposes that you use a cryptographic scheme that makes it easy for anyone to validate the sum but hard to know the values.
289 2011-11-12 02:19:54 <bd_> say someone makes a coin with two txouts: A = 1 BTC, B = 2 BTC
290 2011-11-12 02:19:59 <bd_> (with amounts blinded)
291 2011-11-12 02:20:12 <bd_> now, say there's another coin, with TXIN=A, TXOUT = 1 BTC, 1 BTC
292 2011-11-12 02:20:26 <bd_> miners can't determine if this is invalid, since they can't see the amount of A
293 2011-11-12 02:20:30 <gmaxwell> E.g. addition over ecc can have properties like this.. but I think you can end up with multiple solutions that still sum but are crazy.
294 2011-11-12 02:20:34 <bd_> therefore the recipient must validate
295 2011-11-12 02:21:00 <bd_> but they need to validate the entire tree, because an attacker can build an arbitrarily deep tree of illegal transactions
296 2011-11-12 02:22:39 <gmaxwell> bd_: You've ignored what roconnor said he was considering. It would allow the public to verify the sum. For example I can give you a big number and you can tell that it's big.. but you can't easily tell me what its prime factors are (if I picked a big number that had no small factors)
297 2011-11-12 02:22:52 <bd_> the sum isn't what I'm worried about
298 2011-11-12 02:23:03 <bd_> I'm worried about the value in a txin being equal to the value in the txout it's referring to
299 2011-11-12 02:23:25 <bd_> How do you check this? And without giving away information about the txins in the parent coin?
300 2011-11-12 02:23:28 <gmaxwell> bd_: you combine all the inputs and all the outputs and validate that they sum to zero.
301 2011-11-12 02:23:36 <roconnor> bd_: if the transaction leaks the value of TXOUT then and there is only one intput then the person leaks the value of the one input.
302 2011-11-12 02:24:18 <roconnor> people can leak the value of their coins if they want.
303 2011-11-12 02:24:25 <bd_> roconnor: I don't think you understand. Given two coins, A and B, where B references A (and possibly others) as txins, and where I hold a key to one of the txouts in B, how do I verify that the value that B claims A has is actually the value in A?
304 2011-11-12 02:25:01 <roconnor> bd_: you would have the decription key to decrypt the value of B.
305 2011-11-12 02:25:11 <bd_> roconnor: you mean A?
306 2011-11-12 02:25:18 <bd_> but okay, now how do I know that A is valid in the same way?
307 2011-11-12 02:25:23 <bd_> A has some other parents - call them X and Z
308 2011-11-12 02:25:41 <bd_> I don't have A's keys
309 2011-11-12 02:26:26 <roconnor> right, but you can verify that the sum of the outputs transaction producing A is equal to the sum of the inputs
310 2011-11-12 02:26:38 <bd_> roconnor: how?
311 2011-11-12 02:26:48 <roconnor> that is what homomorphic encryption lets you do :)
312 2011-11-12 02:26:56 <bd_> roconnor: and how much overhead does this carry?
313 2011-11-12 02:27:15 <bd_> but seriously, this is too much handwaving
314 2011-11-12 02:27:24 <roconnor> I agree I'm handwaving
315 2011-11-12 02:27:42 <bd_> and the other problem is the txins and txouts are based on an entirely different set of keys
316 2011-11-12 02:28:00 <gmaxwell> I don't know of a particular homomorphic scheme that lets you do this, but I can see some what would almost work, so it seems likely to be possible.
317 2011-11-12 02:28:15 <bd_> I could see you proving that the sum of a set of numbers X, all encrypted with key K, equals the sum of a set of numbers Y, encrypted with the _same_, _single_ key K
318 2011-11-12 02:28:39 <bd_> but when every number is encrypted with a completely different key?
319 2011-11-12 02:29:14 <roconnor> bd_: hmm, what you say sounds reasonable
320 2011-11-12 02:29:50 <gmaxwell> I think I can see how to get over that if the miner will do an interactive proof with you... but I guess that doesn't convince anyone else.
321 2011-11-12 02:31:11 <etotheipi_> on a not-really-related note... anyone know what the crazy defines in serialize.h do for mlock?
322 2011-11-12 02:31:30 <etotheipi_> around line 50:  I'm not sure why mlock alone isn't sufficient
323 2011-11-12 02:32:26 <etotheipi_> #define mlock(a,b) \n2132006
324 2011-11-12 02:32:40 <gmaxwell> :)
325 2011-11-12 02:32:45 <gmaxwell> Yes, I know what that does.
326 2011-11-12 02:33:10 <roconnor> gmaxwell: there are ways of doing non-interactive interactive proofs using hashes.
327 2011-11-12 02:33:19 <gmaxwell> etotheipi_: man mlock
328 2011-11-12 02:33:19 <roconnor> but this starts really getting beyond my knowledge
329 2011-11-12 02:33:22 <etotheipi_> gmaxwell:  go on
330 2011-11-12 02:33:26 <copumpkin> gmaxwell: it needs to be aligned
331 2011-11-12 02:33:29 <gmaxwell> etotheipi_: EINVAL (Not on Linux) addr was not a multiple of the page size.
332 2011-11-12 02:33:31 <copumpkin> to your page size
333 2011-11-12 02:33:51 <copumpkin> that's fancy code for "snapping" to the beginning of a page
334 2011-11-12 02:33:58 <etotheipi_> ahhh, got it
335 2011-11-12 02:34:19 <gmaxwell> well it snaps and fixes the size.
336 2011-11-12 02:34:28 <copumpkin> sure
337 2011-11-12 02:34:49 <gmaxwell> I thought there was a comment in jrmithdobbs's patch about why this was required (on OSX)
338 2011-11-12 02:34:54 <bd_> wonderful, non-hygenic macros ftw
339 2011-11-12 02:34:54 <gmaxwell> guess it fell out.
340 2011-11-12 02:35:08 <bd_> what's wrong with a nice inline static function? :(
341 2011-11-12 02:35:26 <bd_> maybe even a RAII-style LockedMemoryBlock
342 2011-11-12 02:35:31 <copumpkin> bd_: macros are moar l33t
343 2011-11-12 02:35:33 <gmaxwell> bd_: that macros is perfectly hygenic.
344 2011-11-12 02:35:46 <etotheipi_> haha
345 2011-11-12 02:36:05 <bd_> gmaxwell: mlock(foo[i++], bar[j++]); <-- undefined behavior :3
346 2011-11-12 02:36:29 <bd_> actually, just mlock(listofptrs[i++], length);
347 2011-11-12 02:36:33 <gmaxwell> bd_: it's unspecified, and it's also unspecified in a function call.
348 2011-11-12 02:36:42 <bd_> gmaxwell: no, this is undefined behavior
349 2011-11-12 02:36:47 <bd_> as in anything can happen.
350 2011-11-12 02:36:57 <bd_> including summoning demons through your nose
351 2011-11-12 02:37:21 <copumpkin> oh shit, I just tried running it and he's right
352 2011-11-12 02:37:26 <copumpkin> aaaaahjhhh'
353 2011-11-12 02:37:46 <bd_> ISO/IEC 9899:1999 (E) J.2: The behavior is undefined in the following circumstances: [...] Between two sequence points, an object is modified more than once, or is modified
354 2011-11-12 02:37:49 <bd_> and the prior value is read other than to determine the value to be stored (6.5).
355 2011-11-12 02:38:25 <gmaxwell> bd_: I misread it and thought you did mlock(foo[i++], bar[i++])
356 2011-11-12 02:38:26 <bd_> 'undefined behavior' is the same category of behavior used to describe the semantics of dereferencing a null pointer, or reading an uninitialized variable
357 2011-11-12 02:38:31 <copumpkin> my e-penis is longer than yours because I know which of the two undesirable forms of C you are using
358 2011-11-12 02:38:54 <bd_> gmaxwell: well, yeah, that would be UB no matter what :)
359 2011-11-12 02:39:04 <gmaxwell> copumpkin: its an important distinction and bd_ is correct. I was being daft.
360 2011-11-12 02:39:08 <bd_> but seriously, that's a perfect example of what NOT to use macros for
361 2011-11-12 02:39:26 <bd_> it has more parenthesis than a typical lisp function, ffs
362 2011-11-12 02:39:26 <copumpkin> gmaxwell: from a practical standpoint, you want to avoid both of them :)
363 2011-11-12 02:39:58 <gmaxwell> copumpkin: it's still an important distinction. Only one is allowed to cause the universe to end without documenting it.
364 2011-11-12 02:40:01 <etotheipi_> so... I'm tempted to copy this from the serialize.h, but I looks like it's controversial
365 2011-11-12 02:40:11 <gmaxwell> copumpkin: do YOU want to be responsible for the end of the universe??
366 2011-11-12 02:40:15 <etotheipi_> well also, might there be copyright issues with it?
367 2011-11-12 02:40:16 <copumpkin> nooooooooo
368 2011-11-12 02:40:28 <copumpkin> okay, I shall make the distinction when deciding not to use one or the other
369 2011-11-12 02:40:54 <gmaxwell> etotheipi_: there is no copyright issue. It's a common form and not especially tricky. It just subtracts to convert a number into a mask.
370 2011-11-12 02:41:16 <etotheipi_> haha, well it was easier to ask here, than to try to decipher what it's actually doing
371 2011-11-12 02:41:33 <gmaxwell> etotheipi_: you're just not used to doing systems programming in C or something? :)
372 2011-11-12 02:41:35 <etotheipi_> I mean, I get the pagesize thing.... but it's pretty obvious where I copied it from if I used it
373 2011-11-12 02:42:56 <etotheipi_> btw, am I missing something?  I'm new to IRC, and I keep getting the highlighted username when someone uses "etotheipi_:"... is there a command for that?
374 2011-11-12 02:43:15 <etotheipi_> or do I just type the username: at the beginning?
375 2011-11-12 02:43:29 <gmaxwell> my client tab completes the username.
376 2011-11-12 02:43:41 <etotheipi_> gmaxwell, is this right?
377 2011-11-12 02:43:44 <gmaxwell> (yours probably does too)
378 2011-11-12 02:43:49 <gmaxwell> yes, you're highlighted for me.
379 2011-11-12 02:43:53 <etotheipi_> perfect
380 2011-11-12 02:44:16 <etotheipi_> thanks
381 2011-11-12 04:32:31 <roconnor> a bit off topic, but are there any whitepapers on open-transactions?
382 2011-11-12 06:06:58 <CIA-89> poolserverj: shadders * 29cf4a34c920 r227 /poolserverj-main/src/main/java/com/shadworld/poolserver/conf/Conf.java: fix for nullpointer when aux daemon payout address not set
383 2011-11-12 06:06:59 <CIA-89> poolserverj: shadders * 93ca178a6bce r228 / (6 files in 4 dirs):
384 2011-11-12 06:24:18 <amiller> has anyone ever heard of a model of bitcoin in the E language
385 2011-11-12 06:24:27 <amiller> for dsitributed cryptographic protocols
386 2011-11-12 06:24:48 <SomeoneWeird> E?
387 2011-11-12 06:24:52 <SomeoneWeird> never heard of it
388 2011-11-12 06:25:02 <amiller> erobank.com/download/index.html
389 2011-11-12 06:25:16 <amiller> er
390 2011-11-12 06:25:20 <SomeoneWeird> lol
391 2011-11-12 06:26:00 <amiller> Welcome to ERights.org, home of E, the secure distributed pure-object platform and p2p scripting language
392 2011-11-12 08:13:08 <ThomasV> Mqrius: you here?
393 2011-11-12 08:20:11 <jrmithdobbs> can you mine bitcoins on high capacity 2.5" sata2 drives now or something?
394 2011-11-12 08:20:33 <jrmithdobbs> haven't seen anything limited in ordering quantity this much since spring/summer with the gpu rush
395 2011-11-12 08:21:05 <jrmithdobbs> 1 per customer does not work. i need 4 drives damn it. charge me $20/ea more or something
396 2011-11-12 08:25:22 <phantomcircuit> jrmithdobbs, flooding in thailand destroyed a ton of hdd factories
397 2011-11-12 08:25:46 <phantomcircuit> the response of limiting sales of hdds is dumb
398 2011-11-12 08:25:51 <phantomcircuit> they should just be increasing prices
399 2011-11-12 08:28:12 <jrmithdobbs> phantomcircuit: this is dumb, i need 4 2.5" drives
400 2011-11-12 08:28:28 <phantomcircuit> borrow someone elses creditcard
401 2011-11-12 08:40:07 <JFK911> tech data is selling disks, but not at regular prices.
402 2011-11-12 09:03:48 <extor> So is there anything a CPU can do that a GPU absolutely cannot do?
403 2011-11-12 09:12:15 <lianj> boot linux? :P
404 2011-11-12 09:17:08 <wumpus> extor: complicated code with a lot of decisions that is inherently linear / single threaded, or has very dynamic data access patterns
405 2011-11-12 09:17:26 <wumpus> well the GPU can do it but is subpar in those cases
406 2011-11-12 09:18:39 <extor> but most proggies today are multithreaded, hence not single threaded
407 2011-11-12 09:18:45 <extor> But are they "linear"?
408 2011-11-12 09:18:45 <wumpus> the single threaded performance of CPUs (at least intel/amd ones) is much better than that of GPUs, and CPUs have more advanced branch prediction and caching
409 2011-11-12 09:19:25 <wumpus> Most of the code written is still "linear". Multi-threaded algorithms are being used more these days, for scalability, but not really for application code.
410 2011-11-12 09:20:01 <extor> I was thinking of diving into programming. And my first project would be a captcha cracking application. I wondered if I'd be able to use a GPU for that being a total noob and all who has just messed with a little C++ and script programming on x86 CPUs
411 2011-11-12 09:20:45 <extor> And of course, wondering if the GPU would be super fast at that compared to say a regular intel CPU
412 2011-11-12 09:20:53 <wumpus> also, writing gpu code is conceptually harder, except for embarassingly parallel problems... though I agree that with the multicore trend both are coming closer together
413 2011-11-12 09:21:37 <extor> why is writing gpu code harder, do you have to substitute floating point operations for "linear" steps in execution perhaps?
414 2011-11-12 09:22:13 <wumpus> well gpus are very suited to image processing, also for recognition tasks, so that might be a good area for GPU yes
415 2011-11-12 09:22:54 <extor> And to harness a GPU I need a NUMA driver I take it. And an sdk kit.
416 2011-11-12 09:22:57 <wumpus> when I wrote a captcha cracker I also used GPU, at least for the initial steps (which involves a convolutional neural network, very computation-expensive to train)
417 2011-11-12 09:23:41 <extor> In your opinion then, how many times faster was your GPU in cracking captchas than a CPU of that era would have been?
418 2011-11-12 09:23:41 <wumpus> NUMA driver?
419 2011-11-12 09:24:10 <wumpus> OpenCL or CUDA (depending on AMD/NVidia)
420 2011-11-12 09:24:19 <extor> Ok that's what I meant to say then
421 2011-11-12 09:24:24 <wumpus> 100x or so...
422 2011-11-12 09:24:29 <extor> Good grief
423 2011-11-12 09:24:44 <extor> That is one hell of a reason to run such code in gpus
424 2011-11-12 09:24:51 <wumpus> and I didn't even write the GPU code myself in this case but used Theano to generate it :-)
425 2011-11-12 09:25:03 <extor> There's plenty of blackhat software that depends on captcha cracking. So definately a market out there.
426 2011-11-12 09:25:25 <extor> What is Theano, some sort of RAD toolkit for GPU programming?
427 2011-11-12 09:25:27 <wumpus> hand-optimized it could have been a factor 2-3 faster even I think... but that wasn't worth the trouble in this case, it was already incredibly fast
428 2011-11-12 09:25:53 <wumpus> yes, it is a symbolic manipulation library that generates CPU/GPU code
429 2011-11-12 09:26:19 <wumpus> great for tensor/matrix math
430 2011-11-12 09:26:41 <extor> Were you rehashing libcaca or did you write all your code from scratch
431 2011-11-12 09:27:14 <wumpus> the ocr algorithms was geared to a specific kind of captcha and written from scratch
432 2011-11-12 09:28:39 <wumpus> it usually first involves some steps to get to a normalized representation, then you use machine learning on that
433 2011-11-12 09:29:38 <extor> machine learning as in...you match OCR guesses with human input to "train" the algorithm to work better, in conjunction with the database that you build?
434 2011-11-12 09:29:54 <wumpus> getting to the normalized representation is more of a cpu job, can involve such things such as finding the convex hull, detecting orientation, partial rotation/skew etc...
435 2011-11-12 09:30:24 <wumpus> yes
436 2011-11-12 09:30:32 <extor> Also matching the input with a database of sorts
437 2011-11-12 09:30:34 <wumpus> you need tons of training samples
438 2011-11-12 09:30:58 <extor> that's very "linear" too is it not? Even though you'd probably store the db in a binary tree format for fast access
439 2011-11-12 09:31:22 <extor> Gosh how many total hours of work did that take you, it sounds like a massive effort if it was done from scratch
440 2011-11-12 09:31:59 <wumpus> nah the 'db' in this case was simply a directory structure on disk with a lot of images :-) but caching the intermediate results in a real database can make a lot of sense if you're iteratively improving
441 2011-11-12 09:33:56 <extor> Ok I was thinking you probably digitized different smudged, skewed versions of each character into a sort of matrix that was indexed in some trickey way; optimized so as to be parsed rapidly for a match with the freshly OCRed characters
442 2011-11-12 09:34:00 <wumpus> nah just use the tools and algorthms that are available
443 2011-11-12 09:34:31 <wumpus> btw, if you have the algorithm for generating the capcha you can very quickly generate a training set without humans
444 2011-11-12 09:35:01 <wumpus> (I didn't, in my case, but heh)
445 2011-11-12 09:35:25 <extor> so the algorithm basically smudges and skews a character amirite?
446 2011-11-12 09:35:43 <wumpus> that's one of the steps in a long pipeline
447 2011-11-12 09:36:13 <extor> How would you tacke reCaptcha then? That doesn't really have an algorithm obviously.
448 2011-11-12 09:36:19 <wumpus> but you need to mangle it into a recognizable as possible form for the machine learning algorithm
449 2011-11-12 09:36:31 <wumpus> tons of training samples
450 2011-11-12 09:36:59 <wumpus> recapcha is probably not a good one to start with :-)
451 2011-11-12 09:37:36 <extor> what other public source is out there besides libcaca
452 2011-11-12 09:38:38 <wumpus> uhm there are a lot of resources on character recognition
453 2011-11-12 09:39:51 <wumpus> if you want source code you can find anything from simple neural networks to packages like tesseract
454 2011-11-12 09:40:59 <extor> This isn't really a project a noob would excel at I take it. Like someone who has just done some linux scripting and taken a couple of semesters of C++ in school?
455 2011-11-12 09:41:20 <wumpus> nope
456 2011-11-12 09:41:40 <extor> How many years of schooling and hands on experience have you had
457 2011-11-12 09:43:02 <wumpus> 20+, I've been programming all my life
458 2011-11-12 09:44:28 <extor> Oh gawd
459 2011-11-12 09:44:49 <wumpus> but most of the AI stuff I learned at university or reading papers or simply trying and iterating
460 2011-11-12 09:45:23 <extor> There's that 10,000 hour rule this reminds me of. It basically says that in order to become an expert in the field your path of experience and educatgion needs to cross 10,000 total hours
461 2011-11-12 09:45:42 <extor> divided by 40 that's 250 workweeks or about 5 years
462 2011-11-12 09:46:13 <wumpus> well I crossed that threshold quite some time ago I guess and I still feel like I know nothing :)
463 2011-11-12 11:25:28 <wumpus> I just generated bitcoin doxygen docs, see https://dev.visucore.com/bitcoin/doxygen  ... not much is documented yet (that's a todo), but it can help already a bit in finding your way around the source code
464 2011-11-12 11:35:48 <nathan7> Yay!
465 2011-11-12 11:39:28 <Eliel> http://jkaartinen.iki.fi/~jojkaart/ntxbymarket.html
466 2011-11-12 14:08:08 <CIA-89> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r68802b2 / test/simnet.js : Added test case that simulates two connected nodes. (+10 more commits...) - http://git.io/X98SgA
467 2011-11-12 14:11:12 <roconnor> For BIP_0012, wouldn't it be better to target block numbers instead of dates for the switchover?
468 2011-11-12 14:11:50 <iddo> what's the difference?
469 2011-11-12 14:12:21 <roconnor> iddo: everyone agrees on block numbers, but no one agrees on what time it is exactly
470 2011-11-12 14:14:45 <iddo> the client supporting OP_EVAL wasn't released yet i think
471 2011-11-12 14:15:20 <iddo> i suppose it would be easier to implement it so the nodes switch at certain block num
472 2011-11-12 14:15:30 <roconnor> https://en.bitcoin.it/wiki/BIP_0012 says new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012.
473 2011-11-12 14:15:54 <roconnor> but it seems less error prone to intepret OP_EVAL as no-op until block number whatever
474 2011-11-12 14:16:09 <iddo> hmm check gavin's branch to see how he actually implemented it?
475 2011-11-12 14:19:09 <roconnor> iddo: as far as I can tell gavin's branch evaluates OP_EVAL unconditionally
476 2011-11-12 14:19:44 <roconnor> *sigh* I wish these changes were more thoughly doucmented
477 2011-11-12 14:20:53 <roconnor> such as "during OP_EVAL The alternate stack is pushed onto a stack of alternate stacks and a new empty alternate stack is initalized when executing OP_EVAL, the old alternate stack is restored when the OP_EVAL completes"
478 2011-11-12 14:21:46 <iddo> i still don't see the big difference? respect op_eval if block timestamp reached some value or block number reached some value?
479 2011-11-12 14:22:56 <roconnor> iddo: well block timestamps can retrograde by several hours
480 2011-11-12 14:23:25 <lfm> not that much
481 2011-11-12 14:23:25 <roconnor> so with your suggestion block could flip back and forth between before and after the time threshold
482 2011-11-12 14:23:53 <roconnor> Fine, I can say yes, the timestamp approach can work, but it is full of landmines
483 2011-11-12 14:24:23 <roconnor> do you switch over one the first block in recieved with a suitable timestamp, or is it on a per block basis, etc.
484 2011-11-12 14:24:55 <roconnor> does it matter on the block the script is executed, or on the block that the script is made?
485 2011-11-12 14:27:08 <iddo> maybe feb 1 2012 meant block estimate around that time, so it will be implemented as block num, which seems a little better i agree
486 2011-11-12 14:31:53 <roconnor> If serialized script is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver.
487 2011-11-12 14:32:01 <roconnor> This claim seems to be false:
488 2011-11-12 14:32:40 <roconnor> wait, maybe I don't know how opsigs are counted
489 2011-11-12 14:34:13 <lfm> any fees have to be included in the txn by the sender. but they could be "paid" by the receiver, thats just an accounting decision
490 2011-11-12 14:35:01 <roconnor> are only the number of signature operations exectued in the transactions in a block counted?
491 2011-11-12 14:39:43 <lfm> largest backward timestamp step in the block chain so far is 118.583 minutes
492 2011-11-12 14:39:56 <Eliel> roconnor: you do realize that when OP_EVAL is used in an output, the actual script the transaction uses won't be in the output tx. It'll be introduced in the input.
493 2011-11-12 14:40:13 <Eliel> when that transaction is spent
494 2011-11-12 14:41:36 <roconnor> Eliel: My concern is that I can construct serialized scripts using arithmetic operations, so that the number of op_sig operations is not plainly visible in the script.
495 2011-11-12 14:42:07 <Eliel> roconnor: you mean that you worry that they can't be filtered out?
496 2011-11-12 14:42:07 <sipa> roconnor: good point
497 2011-11-12 14:42:30 <roconnor> well, I'm not sure of the details on how the limit of the number of op_sigs used is enforced
498 2011-11-12 14:42:34 <roconnor> I can't find any documentation.
499 2011-11-12 14:42:37 <Eliel> just filter them out at the input then. Refuse to accept those at that point (or ask huge fee)
500 2011-11-12 14:42:37 <lfm> he thinks they cant be used for setting fees?
501 2011-11-12 14:43:38 <roconnor> Eliel: well, every client has to do the computation, not just the miner.
502 2011-11-12 14:44:16 <roconnor> Like I said, I'm not entirely sure how the op_sigs are counted, but I don't see a counter in the script interpretation code
503 2011-11-12 14:44:30 <Eliel> roconnor: It's unlikely clients other than miners will be doing the verification for too long.
504 2011-11-12 14:45:00 <roconnor> Eliel: still, all the miners will have to do the verification, not just the one getting the fees
505 2011-11-12 14:45:02 <Eliel> it'll become increasingly resource heavy.
506 2011-11-12 14:45:31 <roconnor> I conjecture that OP_EVAL can be used to reimplement the OP_SIG DOS attack
507 2011-11-12 14:45:43 <lfm> you think fancy scripts would be used a lot?
508 2011-11-12 14:46:04 <roconnor> lfm: by maillicous users, certianly.
509 2011-11-12 14:46:11 <Eliel> roconnor: I see no reason why you can't defend against that with OP_EVAL as opposed to defending against it in regular scripts.
510 2011-11-12 14:46:37 <sipa> the problem is that certains checks that are now part of the verification of an output, move to verification of an imput
511 2011-11-12 14:46:58 <sipa> if there are inconsistencies, you end up with an output that was accepted, without possible input to spend it (worst case scenario)
512 2011-11-12 14:47:04 <roconnor> Eliel: ya, you can probably defend against this, but someone, you know, should implement this.
513 2011-11-12 14:47:08 <Eliel> with current scripts, you prevent the transaction with too complex script from going out at all. with OP_EVAL, you just prevent it being spent.
514 2011-11-12 14:47:11 <sipa> s/possible/acceptable/
515 2011-11-12 14:48:05 <Eliel> yes, true. which version is OP_EVAL slated to go into?
516 2011-11-12 14:48:07 <Eliel> 0.6?
517 2011-11-12 14:48:27 <sipa> not earlier than 0.6
518 2011-11-12 14:49:16 <roconnor> anyhow, sipa, you understand what I'm saying, so you can make sure that if it is a real problem it is dealt with :)
519 2011-11-12 14:50:43 <sipa> my largest fear with OP_EVAL is that it will become the de-facto way for creating more advanced transactions, and stand in the way of a decent pay-to-URL standard that supports advanced txouts
520 2011-11-12 14:52:05 <Eliel> huh? why would that be a problem? OP_EVAL just simplifies the URLs a lot.
521 2011-11-12 14:52:29 <Eliel> the payer doesn't need to know what kind of transaction the payment is going into.
522 2011-11-12 14:53:48 <sipa> as such, no it is not a problem, and it only simplifies things, but i fear it may be overused
523 2011-11-12 14:56:59 <roconnor> heh
524 2011-11-12 14:57:09 <roconnor> OP_EVAL is like adding loops to a linear langauge.
525 2011-11-12 14:57:30 <roconnor> It probably becomes Turing complete if it weren't for the recursion limit.
526 2011-11-12 14:58:18 <sipa> i suppose so
527 2011-11-12 14:59:07 <sipa> assuming you have full access to the arithmetic operators
528 2011-11-12 15:00:40 <Eliel> roconnor: kind of :D
529 2011-11-12 15:00:56 <roconnor> ya, hard to say;  I suspect even without multiplication you are fine; but it isn't so clear.
530 2011-11-12 16:14:12 <etotheipi_> is op-eval using recursion?
531 2011-11-12 16:14:22 <etotheipi_> that scares me a little bit if it is
532 2011-11-12 16:14:33 <sipa> limited recursion
533 2011-11-12 16:14:44 <etotheipi_> how limited?
534 2011-11-12 16:14:50 <sipa> 2 levels, iirc
535 2011-11-12 16:15:16 <sipa> i'm not sure whether there is a use case for it yet, and if not, maybe it should be disabled for now
536 2011-11-12 16:15:36 <etotheipi_> I just fear someone finding a bug in it that allows them to infinitely recurse, and crash every node on the network when they hit the system recursion limit
537 2011-11-12 16:16:06 <sipa> that's definitely something that should be part of the standard test suite
538 2011-11-12 16:20:22 <TD> good evening
539 2011-11-12 16:20:59 <sipa> hello, TD
540 2011-11-12 16:27:55 <sipa> casascius?
541 2011-11-12 16:33:41 <TD> yeah
542 2011-11-12 16:34:20 <sipa> have you tried redeeming one?
543 2011-11-12 16:34:55 <justmoon> TD: did customs open your package as well?
544 2011-11-12 16:34:58 <justmoon> (they did mine)
545 2011-11-12 16:35:24 <TD> huh
546 2011-11-12 16:35:29 <TD> i don't think so. it didn't look opened.
547 2011-11-12 16:35:44 <TD> sipa: not yet. going to try in a bit. i didn't get any ACK from mike that he filled them up yet
548 2011-11-12 16:35:53 <TD> justmoon: did they provide any explanation for that ?
549 2011-11-12 16:35:59 <justmoon> yeah in my case they ripped it to bits and then put the bits in new SwissPost packaging
550 2011-11-12 16:36:01 <TD> i'd think x-ray would be enough to check the label on the outside is correct
551 2011-11-12 16:36:06 <justmoon> no explanation
552 2011-11-12 16:36:13 <TD> that's kind of stupid. i wonder what they were looking for.
553 2011-11-12 16:36:30 <justmoon> well, it was an array of little paperbags with metal inside ^^
554 2011-11-12 16:36:52 <TD> so what can that be other than coins?
555 2011-11-12 16:37:11 <justmoon> coin-shaped... cocaine... bombs?
556 2011-11-12 16:37:21 <TD> hmmm :)
557 2011-11-12 16:37:25 <TD> you'd make a better criminal than me obviously
558 2011-11-12 16:37:32 <justmoon> the coins were all there and undamaged, so no harm no foul :)
559 2011-11-12 16:37:43 <justmoon> they look gorgeous, don't they?
560 2011-11-12 16:38:13 <TD> yeah, mike did an amazing job
561 2011-11-12 16:39:04 <TD> justmoon: got hit by this today: http://www.swiss.com/web/EN/various/Pages/optional_payment_charge.aspx
562 2011-11-12 16:39:17 <TD> 22 CHF for booking a flight outside the eu via credit card :-(
563 2011-11-12 16:39:30 <justmoon> hm!
564 2011-11-12 16:39:44 <justmoon> speaking of travels - are you going to prague?
565 2011-11-12 16:39:48 <TD> nope
566 2011-11-12 16:39:51 <TD> not this year
567 2011-11-12 16:39:56 <TD> but say hi to the gang for me :)
568 2011-11-12 16:39:57 <justmoon> aww :(
569 2011-11-12 16:40:23 <justmoon> TD: I can get you in free?
570 2011-11-12 16:40:23 <TD> it's sort of complicated because of the employment thing. don't want people to feel i'm representing google or anything
571 2011-11-12 16:40:38 <justmoon> go in disguise!
572 2011-11-12 16:40:48 <TD> lol. i could go as satoshi :)
573 2011-11-12 16:40:58 <justmoon> see problem solved!
574 2011-11-12 16:40:58 <sipa> go dressed as someone from facebook
575 2011-11-12 16:41:13 <justmoon> I can lend you my "I AM SATOSHI" t shirt
576 2011-11-12 16:41:16 <justmoon> (from the ny conf)
577 2011-11-12 16:42:16 <TD> i wouldn't have much to say at the conf anyway. i didn't get any time for bitcoin research lately.
578 2011-11-12 16:42:27 <justmoon> ah well
579 2011-11-12 16:42:29 <TD> hopefully can return to it in a few weeks
580 2011-11-12 16:42:48 <justmoon> we do have to do another swiss meetup sometime soon - maybe after the conf
581 2011-11-12 16:42:52 <TD> yeah, definitely
582 2011-11-12 16:42:55 <TD> it's been too long
583 2011-11-12 16:42:58 <justmoon> and you have to go paragliding!
584 2011-11-12 16:43:00 <justmoon> :P
585 2011-11-12 16:43:13 <TD> right. long list of things i want to do :-)
586 2011-11-12 16:43:44 <TD> next thing i want to research is p2p credit and lending topics
587 2011-11-12 16:44:02 <justmoon> TD: mmh, interesting
588 2011-11-12 16:44:23 <TD> seeing as how that's a big function of banks, beyond routing payments.
589 2011-11-12 16:44:36 <TD> smart property is a start but not enough
590 2011-11-12 16:45:29 <justmoon> mi...@google.com = devrandom?
591 2011-11-12 16:45:45 <TD> yeah
592 2011-11-12 16:46:06 <sipa> devrandom is another mi[...] ?
593 2011-11-12 16:46:39 <justmoon> mike is he...@google.com :D
594 2011-11-12 16:46:55 <sipa> right
595 2011-11-12 16:47:48 <justmoon> TD: the multibit guy will be in prague - I really like their solution with dragging and dropping QR codes into the client
596 2011-11-12 16:48:17 <TD> mmmhm
597 2011-11-12 16:48:19 <TD> i tried to discourage that
598 2011-11-12 16:48:29 <justmoon> how come?
599 2011-11-12 16:48:46 <TD> it seems not as smooth as clicking a link to a magic url or file
600 2011-11-12 16:48:52 <TD> qrcodes are fundamentally ugly, mechanical things
601 2011-11-12 16:49:01 <TD> even though you can prettify them a bit, they're still intended for machines not people
602 2011-11-12 16:49:11 <TD> so dragging and dropping a qrcode isn't a natural action at all
603 2011-11-12 16:49:32 <justmoon> you could easily have all three ways hooked up: qr for mobile phones, drag & drop and bitcoin://
604 2011-11-12 16:49:32 <sipa> you mean dragging an image file into the client?
605 2011-11-12 16:49:33 <TD> that said, jim is doing a good job of putting a nice desktop gui on top of bitcoinj
606 2011-11-12 16:49:40 <TD> just wish i had more time to work on it
607 2011-11-12 16:49:54 <TD> yeah, for sure, though i think single-click is easier than drag/drop for most people
608 2011-11-12 16:50:04 <TD> so on the desktop that's how i'd prefer to implement it myself.
609 2011-11-12 16:50:06 <justmoon> sipa: http://www.youtube.com/watch?v=LlFPYBYIayU
610 2011-11-12 16:50:52 <TD> in the screencase note that the browser is sized rather awkwardly. i use everything maximized all the time
611 2011-11-12 16:50:54 <TD> so drag/drop is a pain
612 2011-11-12 16:50:57 <justmoon> TD: I suppose that makes sense - drag and drop is going to be more responsive though - protocol handlers have to run an executable and my experience with them is that they always have a little delay
613 2011-11-12 16:51:16 <TD> i don't think it's a big deal. you can use browser plugins/extensions if you need tighter integration
614 2011-11-12 16:51:30 <TD> a browser extension can easily render these links/files as qrcodes if you want that
615 2011-11-12 16:51:42 <justmoon> whenever I argue with you, I lose ^^
616 2011-11-12 16:51:42 <TD> but the best way (for android users) is C2DM
617 2011-11-12 16:51:54 <TD> ie, you click a link and it automatically opens the app on your phone on the confirm screen
618 2011-11-12 16:52:05 <TD> it takes a second or two. really fast. no need to ever see a qrcode
619 2011-11-12 16:52:07 <TD> well i'm stubborn :)
620 2011-11-12 16:52:31 <justmoon> yeah, or just right :P
621 2011-11-12 16:52:50 <justmoon> I suppose it still can't hurt to hook up d&d
622 2011-11-12 16:53:00 <sipa> d&d?
623 2011-11-12 16:53:06 <justmoon> sorry, drag and drop
624 2011-11-12 16:53:09 <da2ce7> hello everone :)
625 2011-11-12 16:53:28 <sipa> right, i interpreted it as dungeons&dragons :)
626 2011-11-12 16:54:02 <justmoon> sipa, every bitcoin client should have a basic D&D game builtin I agree :D
627 2011-11-12 16:54:25 <sipa> haha
628 2011-11-12 16:54:31 <da2ce7> when I'm running ldconfig -n -v /usr/local/lib  for my newly compiled lib... libotapi-java.so.0.0.1  it isn't creating the libotapi-java.so symbolic link automaticaly...
629 2011-11-12 16:54:34 <da2ce7> any ideas?
630 2011-11-12 16:54:55 <sipa> justmoon: hope to see you in prague, btw
631 2011-11-12 16:55:05 <justmoon> sipa: awesome, looking forward to it!
632 2011-11-12 16:55:09 <da2ce7> sipa, cool, cannot wait to see ya :)
633 2011-11-12 16:55:20 <da2ce7> and justmoon :)
634 2011-11-12 16:55:36 <justmoon> da2ce7, yay! we're social!
635 2011-11-12 16:55:40 <sipa> anyone an idea of how many registrations there are?
636 2011-11-12 16:55:45 <TD> da2ce7: that link is one you have to create yourself. it's only used for compilation so the runtime linker doesn't create it
637 2011-11-12 16:56:23 <da2ce7> so I have to do EVEN MORE messy stuff in my makefile :S
638 2011-11-12 16:56:33 <da2ce7> grrr...
639 2011-11-12 16:56:39 <TD> it's done for you by autotools
640 2011-11-12 16:57:04 <da2ce7> yeah I really should move the project over to autotools, except I didn't start it.
641 2011-11-12 16:59:30 <sipa> justmoon: also, a friend of mine who works at google zurich now came to see a presentation of yours a few months ago about bitcoin
642 2011-11-12 16:59:48 <TD> sipa: who is your friend? do i know them ?
643 2011-11-12 17:00:01 <sipa> TD: sebastiaan indesteege, i don't think he knows you
644 2011-11-12 17:00:09 <justmoon> sipa: cool, hope he enjoyed it
645 2011-11-12 17:00:12 <TD> no, never heard of the guy. i hope he's on the bitcoin mailing list.
646 2011-11-12 17:00:59 <sipa> justmoon: anyway, rather funny to hear about my nickname being mentioned irl somewhere in switzerland :)
647 2011-11-12 17:07:23 <TD> how is that better than sqlite or bdb?
648 2011-11-12 17:08:06 <Eliel> I made this graph today. I think it's reasonably useful for gauging if bitcoin is overvalued. http://jkaartinen.iki.fi/~jojkaart/ntxbymarket.html
649 2011-11-12 17:08:10 <justmoon> TD: one benchmark
650 2011-11-12 17:08:14 <justmoon> http://tokyocabinet.sourceforge.net/benchmark.pdf
651 2011-11-12 17:08:22 <wumpus> justmoon: drag&dropping bitcoin: urls already works with the standard client, no need to use qr codes for that :p
652 2011-11-12 17:08:34 <justmoon> (insert usual disclaimer about benchmarks here)
653 2011-11-12 17:08:42 <copumpkin> you already did, by saying "one benchmark"
654 2011-11-12 17:08:51 <TD> yeah that doesn't seem to be a very realistic benchmark
655 2011-11-12 17:08:52 <copumpkin> :)
656 2011-11-12 17:08:58 <TD> writing new records only? what about mutating existing records?
657 2011-11-12 17:09:07 <justmoon> TD: you don't do that in bitcoin
658 2011-11-12 17:10:23 <TD> huh
659 2011-11-12 17:10:27 <TD> i wonder why we renamed zippy to snappy
660 2011-11-12 17:10:33 <TD> trademarks i guess
661 2011-11-12 17:10:57 <justmoon> it has nothing to do with zip, does it?
662 2011-11-12 17:11:06 <justmoon> so maybe it's just a less confusing name
663 2011-11-12 17:12:00 <TD> that's true
664 2011-11-12 17:25:27 <roconnor> Hi TD.  Does bitcoinj do any evaluation of scripts?
665 2011-11-12 17:25:33 <TD> no
666 2011-11-12 17:25:44 <roconnor> thanks; explains why I couldn't find it :)
667 2011-11-12 17:31:08 <TD> it's a lightweight client, it can't evaluate scripts
668 2011-11-12 17:31:15 <TD> that requires a full blockchain copy+index
669 2011-11-12 17:31:18 <sipa> wumpus: good idea about the doxygen page, by the way
670 2011-11-12 17:31:29 <sipa> wumpus: i hope it encourages more documentation in the code
671 2011-11-12 17:32:11 <wumpus> sipa: yep :)
672 2011-11-12 17:32:49 <sipa> i'm not familiar with doxygen myself, but i'll sure try to use whatever style of comments it requires
673 2011-11-12 17:33:28 <wumpus> doxygen can cope with a lot of kinds of comment style, see http://www.stack.nl/~dimitri/doxygen/docblocks.html
674 2011-11-12 17:33:53 <wumpus> I'm still learning it as well
675 2011-11-12 18:25:27 <DrHaribo> Is it not possible to search by block hash or transaction hash on the namecoin block explorer?
676 2011-11-12 18:39:24 <eueueue> Hi people, I'm newbie and would like to do a question: If I don't want to let the bitcoin app opened but would like to always have the blockchain updated. Is there a way to do this?
677 2011-11-12 18:39:58 <cjdelisle> minimize it?
678 2011-11-12 18:40:11 <eueueue> I have a slow pc
679 2011-11-12 18:40:13 <TD> you could run it in server mode. it'd still be running but the window wouldn't be visible. minimization is probably easier though
680 2011-11-12 18:40:19 <TD> ah, well, that won't help. you could try MultiBit
681 2011-11-12 18:40:24 <eueueue> and the gui make it slow
682 2011-11-12 18:40:25 <TD> it's not as stable as the main client but has lower resource usage
683 2011-11-12 18:40:48 <eueueue> Yes, I already tested multibit
684 2011-11-12 18:41:08 <cjdelisle> TD: you do interesting projects. Was reading backscroll re credit system.
685 2011-11-12 18:41:10 <eueueue> but why multibit doesn't allow the same wallet of bitcoin?
686 2011-11-12 18:41:39 <TD> it's a different app
687 2011-11-12 18:41:44 <TD> you have to send the coins between them
688 2011-11-12 18:41:56 <eueueue> don't have any project to multibit accept bitcoin wallet?
689 2011-11-12 18:41:58 <TD> cjdelisle: well i didn't come up with much for credit yet :-) it just seems important
690 2011-11-12 18:42:04 <TD> eueueue: well, it's possible, but hard
691 2011-11-12 18:42:09 <TD> there are higher priorities
692 2011-11-12 18:42:14 <TD> it's not hard to send coins from one to another
693 2011-11-12 18:42:23 <eueueue> hehe
694 2011-11-12 18:42:27 <eueueue> right
695 2011-11-12 18:42:54 <eueueue> but why people started multi bit if we have bitcoin?
696 2011-11-12 18:43:32 <TD> multibit is written in a different way that makes it much less resource intensive (but gives it different security tradeoffs)
697 2011-11-12 18:44:11 <eueueue> hum, so why bitcoin devs just don't migrate to multibit?
698 2011-11-12 18:44:23 <eueueue> if it's better
699 2011-11-12 18:44:34 <TD> it's not
700 2011-11-12 18:44:36 <TD> it's just different
701 2011-11-12 18:44:37 <sipa> you can't compare the applications
702 2011-11-12 18:44:43 <TD> the network can't have _only_ lightweight clients like multibit
703 2011-11-12 18:44:52 <TD> some people have to run full bitcoin or the system can't function
704 2011-11-12 18:44:55 <sipa> multibit does not implement a full bitcoin node like bitcoind or bitcoin-qt
705 2011-11-12 18:45:11 <eueueue> understand
706 2011-11-12 18:45:42 <sipa> your question is comparable to "why doesn't microsoft developers migrate to OSX?"
707 2011-11-12 18:45:47 <sipa> *don't
708 2011-11-12 18:46:04 <TD> if you just want to send/receive coins, eventually things like multibit will be better. for merchants, companies, miners, people who want to help the network, full bitcoin is going nowhere
709 2011-11-12 18:46:30 <eueueue> right
710 2011-11-12 18:47:06 <eueueue> but what happens almost all people use light clients, the network will stop?
711 2011-11-12 18:47:16 <TD> that's a topic that's discussed from time to time.
712 2011-11-12 18:47:28 <eueueue> hum
713 2011-11-12 18:47:30 <TD> no, it probably won't stop. there will always be some people running the full client
714 2011-11-12 18:47:39 <TD> there's a risk of overload
715 2011-11-12 18:47:44 <TD> but there are projects underway to address that
716 2011-11-12 18:47:59 <eueueue> ok
717 2011-11-12 18:48:17 <TD> before he left satoshi thought you could support millions of users on lightweight clients with a core network of around 10,000 nodes
718 2011-11-12 18:48:24 <TD> you don't need a huge backbone to support lots of users.
719 2011-11-12 18:48:37 <TD> if bitcoin ever gets that big there'll be plenty of people willing to run full nodes
720 2011-11-12 18:49:07 <eueueue> probably companies right?
721 2011-11-12 18:49:26 <eueueue> and anyone who wants
722 2011-11-12 18:49:27 <TD> yes, companies, hobbyists ..... kind of like saying what happens when everyone uses web browsers and nobody runs web servers :)
723 2011-11-12 18:50:52 <eueueue> conclusion: for now it's necessary people run full client. On future will not be necessary
724 2011-11-12 18:51:14 <sipa> No - there will always be a need for people running full clients.
725 2011-11-12 18:51:23 <sipa> Just not everyone.
726 2011-11-12 18:51:39 <eueueue> right
727 2011-11-12 18:52:38 <TD> eueueue: if you can't run the full client, just use multibit for now and send the coins across
728 2011-11-12 18:52:40 <eueueue> what is time size of blockchain today?
729 2011-11-12 18:52:45 <eueueue> 1 gb
730 2011-11-12 18:52:47 <TD> just be careful. multibit is not as well tested or as stable as regular full bitcoin
731 2011-11-12 18:53:02 <eueueue> Td: thamks
732 2011-11-12 18:53:03 <TD> about 700mb
733 2011-11-12 18:53:09 <TD> multibit will use about 15mb of disk i guess
734 2011-11-12 18:53:43 <eueueue> so when be 100gb, we have a estimate year when this will happen?
735 2011-11-12 18:53:55 <TD> 100gb?
736 2011-11-12 18:54:00 <TD> that's a lot
737 2011-11-12 18:54:02 <TD> hard to say for two reasons
738 2011-11-12 18:54:06 <TD> 1) depends how much bitcoin is used
739 2011-11-12 18:54:14 <TD> 2) depends if/when somebody implements tx pruning, which can delete a lot of data
740 2011-11-12 18:54:20 <eueueue> and will necessary more cpu to run 100gb instead of 700mb right?
741 2011-11-12 18:54:33 <TD> well cpu usage is proportional to activity
742 2011-11-12 18:54:47 <eueueue> ha ok
743 2011-11-12 18:54:48 <TD> https://en.bitcoin.it/wiki/Scalability
744 2011-11-12 18:54:50 <TD> see that page
745 2011-11-12 18:55:12 <eueueue> will read. Will let you free now. Was a lot of questions
746 2011-11-12 18:55:15 <eueueue> thanks
747 2011-11-12 18:55:57 <sipa> gavinandresen: does shutting down cleanly but immediately after encrypting guarantee that no leftover caches will be written to the database files?
748 2011-11-12 18:56:15 <TD> np
749 2011-11-12 18:56:34 <cjdelisle> I had an interesting idea today.. it should be possible if the namecoin stuff was merged into bitcoin to have a sendto() for a "domain name" by looking up the ip addr of the domain in the blockchain then connect directly to the node at the other end and ask for an address to sendTo along with a proof that the owner of the "domain" also owns the btc address.
750 2011-11-12 18:57:01 <gavinandresen> sipa: I don't know.  It seems to work in practice...
751 2011-11-12 18:57:53 <gavinandresen> sipa:  ... but I wouldn't be surprised if there could be a race condition that breaks it (encrypt, then a tx comes in on the network that makes bdb do some more work that puts extra stuff in the new wallet.dat, then shutdown)
752 2011-11-12 18:58:19 <sipa> cjdelisle: which is what you would get if a general pay-to-domain system was implemented (which i hope will be), and you have a resolver on your system that uses namecoin
753 2011-11-12 18:58:28 <sipa> no need to hardcode it
754 2011-11-12 18:58:50 <sipa> gavinandresen: yes, that's what i fear
755 2011-11-12 18:58:52 <cjdelisle> if there isn't a namecoin resolver then it's relying on dns which is not safe.
756 2011-11-12 18:59:05 <sipa> and namecoin is?
757 2011-11-12 18:59:35 <sipa> all depends on how much your trust the authority
758 2011-11-12 18:59:50 <TD> cjdelisle: it can be with DNSSEC
759 2011-11-12 18:59:54 <TD> i'm not sure you need namecoin for that
760 2011-11-12 18:59:58 <TD> (or ssl)
761 2011-11-12 19:00:00 <cjdelisle> Namecoin is extremely safe compared to dns.
762 2011-11-12 19:00:06 <AlexWaters> sipa: it's nearly identical to bitcoin except that the namecoin protocol allows you to buy namecoin domains with namecoins
763 2011-11-12 19:00:17 <sipa> AlexWaters: i know what namecoin is :)
764 2011-11-12 19:00:23 <cjdelisle> Dnssec is sad.
765 2011-11-12 19:00:32 <AlexWaters> sipa: lol, i jumped in here a little out of step then =P sorry
766 2011-11-12 19:00:39 <cjdelisle> I'm sorry to troll but dnssec just isn't going to happen.
767 2011-11-12 19:00:44 <AlexWaters> sipa: i was surprised thinking you didn't
768 2011-11-12 19:01:21 <cjdelisle> You can't put an rsa-1024 chain of trust into a udp packet
769 2011-11-12 19:01:27 <sipa> cjdelisle: well, if you don't trust the dns (or dnssec) system, you shouldn't use any resolver but namecoin i suppose
770 2011-11-12 19:01:38 <sipa> that is still independent from bitcoin
771 2011-11-12 19:02:03 <cjdelisle> The advantage of it being included in bitcoin is that you don't have to trust the big bad world.
772 2011-11-12 19:02:20 <sipa> but you do trust the big bad world for web browsing?
773 2011-11-12 19:02:34 <cjdelisle> sending money != web browsing
774 2011-11-12 19:02:40 <gavinandresen> AlexWaters: can you look over:  https://gist.github.com/1361001   (test plan for wallet encryption bugfix)
775 2011-11-12 19:03:23 <cjdelisle> if you send money, there is #1 a higher loss and #2 a greater incentive to attack then if you are looking for google.
776 2011-11-12 19:03:46 <cjdelisle> You can be pretty certain that once something has been in the bitcoin chain for a while, it's not going to vanish or suddenly change.
777 2011-11-12 19:04:10 <sipa> if someone got access to my gmail but mitm'ing my connection to google, i may have larger problems than if my entire stash of bitcoins was stolen.
778 2011-11-12 19:04:29 <sipa> that may not be the case anymore "if bitcoin got big"
779 2011-11-12 19:04:52 <AlexWaters> gavinandresen: i promised my girlfriend I would work on her website, but i can look at that and the bugs I plan to test  (about 7) this evening / tomorrow. is it time sensitive?
780 2011-11-12 19:05:05 <kiba> hey
781 2011-11-12 19:05:12 <gavinandresen> sipa: maybe a sanity check after wallet re-encryption should be coded... something like:  Store all private keys in memory during re-encryption.  Then during shtudown, after bdb is shut down, scan the new wallet.dat to make sure none are in it
782 2011-11-12 19:05:52 <sipa> cjdelisle: but still, the problem is trust in a domain system, and if you think the existing dns setup on your own system is not sufficient for certain applications, you need some other setup.
783 2011-11-12 19:06:03 <cjdelisle> mitm'ing gmail connections has happened in the wild
784 2011-11-12 19:06:13 <gavinandresen> AlexWaters: yes, it is time sensitive, but if you can't get to it until Monday we'll survive
785 2011-11-12 19:07:02 <cjdelisle> dns is what we have and it's okish for most things, I don't see anyone changing dns any time soon.
786 2011-11-12 19:07:15 <AlexWaters> gavinandresen: ok i will play with it first thing this evening
787 2011-11-12 19:07:19 <sipa> gavinandresen: that's quite extensive - maybe something for a tool in contrib/ rather than in mainline client?
788 2011-11-12 19:07:44 <gavinandresen> AlexWaters: the time sensitive part is just looking over the test plan and seeing if I forgot something
789 2011-11-12 19:07:45 <cjdelisle> for sending money through a pseudoanonymous non-chargeback-able system, making sure you sent to the right addr is serious business.
790 2011-11-12 19:08:30 <gavinandresen> (I don't expect testing to happen until there's an easy-to-run tool for extracting private keys from an encrypted wallet)
791 2011-11-12 19:09:06 <sipa> gavinandresen: you've seen etotheipi_'s tools?
792 2011-11-12 19:09:31 <gavinandresen> sipa:  yes
793 2011-11-12 19:09:59 <gavinandresen> sipa: ... I don't think he's implemented decryption, though.
794 2011-11-12 19:10:12 <sipa> Oh, that's what you mean - no indeed.
795 2011-11-12 19:10:40 <gavinandresen> sipa: actually, your feedback on the testplan would be great, too:  https://gist.github.com/1361001]
796 2011-11-12 19:10:59 <gavinandresen> sipa:  the little python code I've been using to find private keys in files is part of that.
797 2011-11-12 19:13:15 <kiba> I wonder why the gas station isn't like a warehouse where you just pay and they deliver the gas or goodies to you
798 2011-11-12 19:13:47 <kiba> when you order food
799 2011-11-12 19:13:54 <kiba> they should be able to just ship it to you
800 2011-11-12 19:15:07 <sipa> gavinandresen: to extract the keys from the encrypted wallet.dat file, you could use my private key export patch?
801 2011-11-12 19:15:26 <sipa> (maybe a separate executable, not the actual executable being tested)
802 2011-11-12 19:15:59 <gavinandresen> sipa: what format does it export to?
803 2011-11-12 19:16:13 <sipa> wallet export exports to json
804 2011-11-12 19:16:37 <sipa> oh, in base58, not hex
805 2011-11-12 19:17:15 <gavinandresen> I've been meaning to teach bitcointools to understand 'wkey' entries, and implement the passphrase decryption....
806 2011-11-12 19:17:25 <sipa> that would be great
807 2011-11-12 19:17:45 <sipa> but maybe not trivial, as you'd need to mimick OpenSSL's EVP_BytesToKey function e.g.
808 2011-11-12 19:17:46 <gavinandresen> That'll be more work, but at least it would be useful-in-the-future work
809 2011-11-12 19:18:05 <sipa> anyway, it's easy to write a function that just dumps all private keys in hex to a text file
810 2011-11-12 19:18:15 <sipa> i can adapt the export code to do that, if you like
811 2011-11-12 19:18:16 <gavinandresen> I could just call EVP_BytesToKey and add a soft-dependency on openssl.   I think.
812 2011-11-12 19:18:47 <gavinandresen> sipa:  short-term, if you could create a version of your patch that just spits out private keys in hex, one-per-line, that'd be spiffy
813 2011-11-12 19:19:19 <gavinandresen> (I'm about to turn into a pumpkin-- going to a Bruins hockey game tonight)
814 2011-11-12 19:20:07 <AlexWaters> gavinandresen: as a testcase - this seems pretty straightforward and simple. I think this is a high priority test to be running continuously, and it should be evolving with penetration testing to foil it. in my limited experience, there might be something that this test is missing - and I'll do my best to try and find that. Overall, I think it covers the vectors that I can imagine for preventing unencrypted data being mistaken for encrypted
815 2011-11-12 19:23:03 <AlexWaters> gavinandresen: i'm hoping that's the bigger goal for why we need to test for this? to make sure that private keys aren't lurking in corners?
816 2011-11-12 19:23:37 <sipa> AlexWaters: we know that private keys are lurking in corners
817 2011-11-12 19:23:38 <gavinandresen> AlexWaters: yes-- and good point about running it continuously
818 2011-11-12 19:24:21 <gavinandresen> AlexWaters: I thought I cc'ed you on the discussion, but if not, see: https://bitcointalk.org/index.php?topic=51604.0
819 2011-11-12 19:25:36 <AlexWaters> gavinandresen: sorry I missed that, trying to play catchup this weekend with bitcoin qa
820 2011-11-12 19:40:52 <CIA-89> libbitcoin: genjix * r0df89ac1c7c5 / (6 files in 5 dirs): Initial BDB skeleton.
821 2011-11-12 19:40:53 <CIA-89> libbitcoin: genjix * rfd5cbecf44b7 / (5 files in 5 dirs): genesis_block()
822 2011-11-12 19:40:59 <CIA-89> libbitcoin: genjix * r4ca6ea360ed7 /include/bitcoin/bitcoin.hpp: added bc namespace alias.