1 2011-11-13 00:05:44 <roconnor> I still don't understand the purpose of CODE_SEPARATOR
  2 2011-11-13 00:20:59 <roconnor> wtf, there is a negative 0
  3 2011-11-13 00:21:35 <roconnor> sipa: I don't understand this format at all :(
  4 2011-11-13 00:22:48 <roconnor> etotheipi_, sipa: it looks like [0x80] is negative 0
  5 2011-11-13 00:23:10 <roconnor> rather than -128
  6 2011-11-13 00:23:15 <roconnor> I think
  7 2011-11-13 00:25:34 <roconnor> etotheipi_: I don't suppose you can test if PUSHDATA [0x80] OP_0 OP_EQUAL is true or false?
  8 2011-11-13 00:33:29 <roconnor> sipa: I think you are wrong, this isn't two's complement
  9 2011-11-13 00:37:37 <roconnor> but this is really confusing
 10 2011-11-13 00:44:55 <devrandom> sipa: devrandom == mi...@google.com == mi...@hyper.to
 11 2011-11-13 00:54:51 <Rabbit67890> is the network clooged?
 12 2011-11-13 00:55:22 <Rabbit67890> in technical details
 13 2011-11-13 00:59:11 <gmaxwell> How is babby formed?
 14 2011-11-13 01:05:48 <copumpkin> you need to do way instain mother
 15 2011-11-13 01:05:57 <copumpkin> who kill thier babby because these babby cant frigth back?
 16 2011-11-13 01:06:08 <copumpkin> it was in the news this mroing a mother in ar who had kill her three kids!
 17 2011-11-13 01:06:11 <Rabbit67890> ...
 18 2011-11-13 01:06:15 <cjdelisle> roconnor: where are you looking?
 19 2011-11-13 01:06:16 <copumpkin> they are taking the babby back to new york too lady to rest
 20 2011-11-13 01:06:24 <roconnor> cjdelisle: bignum.h
 21 2011-11-13 01:06:33 <copumpkin> my pary are with the rather, who lost his chrilden. i am truley sorry for your lots
 22 2011-11-13 01:06:34 <Rabbit67890> any devs willing to help?
 23 2011-11-13 01:07:12 <Rabbit67890> im stuck at 0 confirmations and broadcasts for one transaction
 24 2011-11-13 01:07:21 <Rabbit67890> and i pastebinned some part of my log http://pastebin.com/ZXTm39EY
 25 2011-11-13 01:07:32 <cjdelisle> looks like everyone hates your tx
 26 2011-11-13 01:07:34 <cjdelisle> too bad
 27 2011-11-13 01:07:44 <Rabbit67890> FFFFFFFUUUUUUUUUUUUUU
 28 2011-11-13 01:07:51 <Rabbit67890> that was 10 BTC
 29 2011-11-13 01:08:02 <gmaxwell> Rabbit67890: what version of the software are you using?
 30 2011-11-13 01:08:21 <Rabbit67890> 4.0-beta
 31 2011-11-13 01:08:38 <gmaxwell> Rabbit67890: any modifications to it?
 32 2011-11-13 01:08:42 <Rabbit67890> no
 33 2011-11-13 01:08:44 <gmaxwell> also, I don't see any retransmits there.
 34 2011-11-13 01:08:53 <gmaxwell> how long have you been waiting?
 35 2011-11-13 01:09:02 <Rabbit67890> a few mins
 36 2011-11-13 01:09:05 <gmaxwell> ...
 37 2011-11-13 01:09:08 <Rabbit67890> or 10 - 20 minutes
 38 2011-11-13 01:09:30 <gmaxwell> sometimes a transaction doesn't get confirmed in the first block after it. You're expecting it to move too quickly.
 39 2011-11-13 01:09:51 <Rabbit67890> i started on block 15035
 40 2011-11-13 01:10:14 <gmaxwell> oh, you're not even synced with the blockchain yet?
 41 2011-11-13 01:10:23 <gmaxwell> how many blocks do you see right now?
 42 2011-11-13 01:10:27 <gmaxwell> ;;bc,blocks
 43 2011-11-13 01:10:28 <gribble> 153038
 44 2011-11-13 01:10:31 <Rabbit67890> i started on 15035, im on 15038
 45 2011-11-13 01:10:43 <Rabbit67890> it was block 15035 when i sent it
 46 2011-11-13 01:10:45 <gmaxwell> are you dropping some digits??
 47 2011-11-13 01:10:53 <Rabbit67890> no?
 48 2011-11-13 01:11:04 <gmaxwell> The network is at _153038_
 49 2011-11-13 01:11:07 <roconnor> Rabbit67890: dropped a 3
 50 2011-11-13 01:11:17 <Rabbit67890> no
 51 2011-11-13 01:11:23 <Rabbit67890> i started a few mins at 15035
 52 2011-11-13 01:11:32 <Rabbit67890> my count is at 15038
 53 2011-11-13 01:11:33 <roconnor> Rabbit67890: you started a few mins at 153035
 54 2011-11-13 01:12:15 <gmaxwell> roconnor: can't tell, he doesn't even recieve any blocks in that log segment.
 55 2011-11-13 01:12:34 <gmaxwell> roconnor: if you're really at 15038 and not 153038 then you'll need to wait a while while it syncs up.
 56 2011-11-13 01:13:00 <Rabbit67890> i mean 153038
 57 2011-11-13 01:13:06 <Rabbit67890> didnt notice that 3
 58 2011-11-13 01:13:34 <gmaxwell> 153037 processed no zero fee txns.
 59 2011-11-13 01:14:11 <Rabbit67890> im dumping everything
 60 2011-11-13 01:14:15 <Rabbit67890> except my wallet
 61 2011-11-13 01:14:28 <gmaxwell> Whats that mean?
 62 2011-11-13 01:14:37 <Rabbit67890> deleting %APPDATA%/Bitcoin
 63 2011-11-13 01:14:46 <gmaxwell> why?
 64 2011-11-13 01:14:57 <gmaxwell> You really sound like you're being far too impatient.
 65 2011-11-13 01:15:12 <gmaxwell> Also, by restarting you're delaying retransmission.
 66 2011-11-13 01:15:33 <gmaxwell> So if indeed your txn hadn't propagated well you're making it worse.
 67 2011-11-13 01:17:16 <gmaxwell> Rabbit67890: can you find your txn here? http://bitcoincharts.com/bitcoin/
 68 2011-11-13 01:19:10 <cjdelisle> looking at satoshi's templating tricks is like looking at God
 69 2011-11-13 01:20:32 <roconnor> what templating tricks?
 70 2011-11-13 01:20:34 <Rabbit67890> not really
 71 2011-11-13 01:20:49 <Rabbit67890> God --> Satoshi --> Pools --> Us :3
 72 2011-11-13 01:26:13 <Rabbit67890> w00t reloading fixed it
 73 2011-11-13 01:26:26 <Rabbit67890> i think my chain was corrupted so i loaded a backup
 74 2011-11-13 01:33:14 <gmaxwell> Rabbit67890: no,... most likely having patience fixed it.
 75 2011-11-13 01:33:40 <gmaxwell> It probably just got confirmed in 153039 and would have been confirmed in 153039 regardless of what you did.
 76 2011-11-13 01:34:28 <Rabbit67890> and i just wonder why your not op here
 77 2011-11-13 01:34:42 <roconnor> sipa: I'm now very confused
 78 2011-11-13 01:35:05 <cjdelisle> roconnor: can you tell me where to look for the serialization of bignums? am I looking at getvch()/setvch()?
 79 2011-11-13 01:35:33 <roconnor> cjdelisle: ya there
 80 2011-11-13 01:35:52 <cjdelisle> bignum.h is fucking brilliant IMO
 81 2011-11-13 01:36:07 <roconnor> cjdelisle: I was also browsing at setint64 and setuint64
 82 2011-11-13 01:36:38 <cjdelisle> Using templates and operator overloading to make bignums act like ints
 83 2011-11-13 01:36:41 <cjdelisle> brilliant
 84 2011-11-13 01:37:22 <gmaxwell> cjdelisle: thats ... what operator overloading is there for!
 85 2011-11-13 01:37:24 <roconnor> cjdelisle: OTOH, wrapping an existing bignum library to make another bignum library is ... confusing.
 86 2011-11-13 01:37:55 <gmaxwell> overloading is a shit feature generally, but using it to make bignums, vectors, and matrixes work sanely is pretty much the only good use for it.
 87 2011-11-13 01:38:24 <cjdelisle> gmaxwell++
 88 2011-11-13 01:38:42 <cjdelisle> I can't stand that streaming with >> it's just pointless
 89 2011-11-13 01:39:27 <gmaxwell> yea, I was so confused when I first saw C++ code... You're ... right shifting a string?! wtf?!
 90 2011-11-13 01:39:53 <gmaxwell> What even more sad is the occasional stackoverflow question where someone is confused because they're unaware of the shift operators.
 91 2011-11-13 01:40:19 <cjdelisle> I took 1 c++ class and just did as told, then went on and learned java and C, then came back and was like "oh I was doing that horrific hack"
 92 2011-11-13 01:40:41 <cjdelisle> Actually in my 1 semester of c++ I wrote...
 93 2011-11-13 01:40:46 <cjdelisle> a bignum library
 94 2011-11-13 01:42:15 <gmaxwell> Want to talk about crazy uses of overloading... I sometimes use a C++ library that makes it so you write some code that implements an arbitrarily complex function x=f(a,b,c,d,e,...) and the library gives you the partial derivatives ???x/a,???x/b,???x/c,...
 95 2011-11-13 01:42:55 <gmaxwell> it's ... utterly hideous, and if anything goes wrong misplace a character the compiler spits 40 pages of template garbage.
 96 2011-11-13 01:43:03 <roconnor> gmaxwell: ya, you can do that using automatic forward differentation
 97 2011-11-13 01:43:06 <cjdelisle> That went over my head but ok
 98 2011-11-13 01:43:14 <roconnor> it isn't so much harder than implementing complex numbers
 99 2011-11-13 01:43:51 <gmaxwell> roconnor: well, its reverse mode to get the partials as a function of each of the inputs.. forward mode gets you the partials on the outputs.
100 2011-11-13 01:44:27 <gmaxwell> But yea... its a lifesaver because correctly implementing derivatives for software you keep changing is impossibly annoying. But the libraries are also impossibly annoying.. :)
101 2011-11-13 01:44:39 <roconnor> :)
102 2011-11-13 01:44:47 <gmaxwell> (at least in C++, perhaps there are also solutions in other languages which are nicer)
103 2011-11-13 01:44:57 <roconnor> I use it to do por
104 2011-11-13 01:45:02 <roconnor> portfolio optimisation
105 2011-11-13 01:47:09 <gmaxwell> Ah, I use it for audio codec development. Drop a whole chunk of the codec, complete with a psychoacoustic model, into an optimizer... and do local optimizations on hundreds of parameters at once.
106 2011-11-13 01:53:30 <Kiba> hello
107 2011-11-13 01:53:57 <theymos> Hi. I haven't seen you in a while.
108 2011-11-13 02:38:01 <cocktopus> calling all devs, especially gavinandresen: http://research.microsoft.com/apps/pubs/default.aspx?id=156072 look at the PDF in that article
109 2011-11-13 02:38:18 <cocktopus> microsoft's ideas to imporve bitcoin
110 2011-11-13 02:38:24 <cocktopus> improve*
111 2011-11-13 02:40:26 <OneFixt> whoa
112 2011-11-13 02:40:47 <cocktopus> mathematical proofs showing how to prevent a sybil attack
113 2011-11-13 02:41:27 <OneFixt> excellent
114 2011-11-13 02:47:20 <imsaguy> good press is a wonderful thing
115 2011-11-13 02:48:11 <imsaguy> although, I find it ironic that the one company the open source community loves to complain about is the one that did it
116 2011-11-13 02:48:23 <cocktopus> lol me too
117 2011-11-13 02:48:24 <imsaguy> well not one, but one of the biggest
118 2011-11-13 02:48:34 <imsaguy> maybe microsoft isn't so bad after all ;)
119 2011-11-13 02:48:37 <cocktopus> but i bet they have ulterior motives
120 2011-11-13 02:48:56 <cocktopus> they have been discussign plans for a distributed voting system
121 2011-11-13 02:49:05 <cocktopus> who's to say it won't be based on bitcoin
122 2011-11-13 03:16:29 <MimeNarrator> Is there seriously a vulnerability in wallet encryption in 0.4 client?
123 2011-11-13 03:52:41 <phantomcircuit> MimeNarrator, yes if you take a wallet and then encrypt it the private key might still be in plaintext
124 2011-11-13 03:53:50 <cocktopus> is it safe to assume that new wallets that are encryped before any transactions happen are safe?
125 2011-11-13 03:54:06 <gmaxwell> MimeNarrator: I cringe to see it called serious. It absolutely is serious, but at the same time only a small minority use encryption at all and its still more secure than not using encryption.
126 2011-11-13 03:54:18 <gmaxwell> cocktopus: no. They aren't.
127 2011-11-13 03:54:53 <MimeNarrator> gmaxwell: really? Why on earth are so many people using no encryption at all?
128 2011-11-13 03:55:18 <cocktopus> as long as isn't s data destroying bug, then its cool with me, i protect my wallet with external means as well
129 2011-11-13 03:55:26 <gmaxwell> MimeNarrator: ::shrugs:: Most users haven't even upgraded to 0.4 (the first version that has it available)
130 2011-11-13 03:55:57 <gmaxwell> It's also a (minor) inconvenience, and people obviously believe their computers are secure.
131 2011-11-13 03:56:06 <MimeNarrator> Seems like encryption would be a very good incentive to upgrade. I'm surprised.
132 2011-11-13 03:56:27 <phantomcircuit> MimeNarrator, in practical terms it isn't worth a lot truth be told
133 2011-11-13 03:56:37 <gmaxwell> What phantomcircuit said.
134 2011-11-13 03:56:46 <gmaxwell> The actual improvement is real but modest.
135 2011-11-13 03:56:51 <phantomcircuit> it just requires a *slightly* more sophisticated attack
136 2011-11-13 03:56:59 <phantomcircuit> so
137 2011-11-13 03:57:01 <phantomcircuit> whatevah
138 2011-11-13 03:57:16 <gmaxwell> MimeNarrator: if there is a trojan on your system it can pull the key data out of memory or sniff your keyboard. It's only a few lines of modification to existing attack tools.
139 2011-11-13 03:57:20 <MimeNarrator> sure, but upgrading is pretty easy.
140 2011-11-13 03:58:03 <phantomcircuit> i think i speak for most users when i say
141 2011-11-13 03:58:04 <phantomcircuit> meh
142 2011-11-13 03:58:28 <MimeNarrator> if someone can run arbitrary code on your machine you're fucked. But at least it should prevent someone from easily copying your wallet.dat to a USB drive while you are away from your machine and taking your balance.
143 2011-11-13 03:59:23 <gmaxwell> Looks like 4.0+ is about 35% of the network. More than last time I checked, still not that much.
144 2011-11-13 03:59:52 <gmaxwell> MimeNarrator: yes. A real improvement, but thats not a particular attack people are usually worried about.
145 2011-11-13 04:00:06 <gmaxwell> If I can attach USB to your computer I can also insert a keyboard shim.
146 2011-11-13 04:00:19 <gmaxwell> http://www.keyghost.com/
147 2011-11-13 04:02:26 <MimeNarrator> sure, it mostly deters very unsophisticated attackers, but that's a benefit. I'm not saying it's even close to perfect, but it's a good thing. I'm less concerned by the bug itself than by it's not getting caught sooner.
148 2011-11-13 04:03:18 <gmaxwell> MimeNarrator: The 'bug' wasn't visible in the bitcoin source. It's due to BDB having non-obvious (though expectable) behaivor.
149 2011-11-13 04:03:35 <MimeNarrator> ah
150 2011-11-13 04:03:38 <gmaxwell> When the client deletes the database records for the old plain-text private keys... SURPRISE they aren't reliably deleted.
151 2011-11-13 04:03:52 <MimeNarrator> that's unfortunate
152 2011-11-13 04:05:05 <cocktopus> wonder if it would be easier or possible even to simply overrite the old addresses with blank data before deleting
153 2011-11-13 04:05:06 <gmaxwell> Just as a sanity check we should have scanned the files for them... but apparently no one did. I did a @#$@@!#! load of testing, but I was mostly concerned with accidently losing keys during reencryption, losing keys durning runtime, and deadlocks.
154 2011-11-13 04:05:49 <gmaxwell> cocktopus: No. Thats the point. The database lets you replace/delete records but it doesn't actually do these operations in place. (and it shouldn't in order to reduce the risk of corruption if you're shutdown while updating the files)
155 2011-11-13 04:06:41 <gmaxwell> cocktopus: in any case, the fix is (mostly) to create a new wallet and move the data over and nuke the old one.
156 2011-11-13 04:07:49 <cocktopus> yep ok
157 2011-11-13 04:08:01 <MimeNarrator> so is there a timeframe on pushing a fix?
158 2011-11-13 04:08:46 <gmaxwell> 'a few days'
159 2011-11-13 04:09:01 <MimeNarrator> ah
160 2011-11-13 04:10:01 <gmaxwell> The fixes are up but they need more testing and review (and backporting)
161 2011-11-13 04:10:12 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/635
162 2011-11-13 04:10:39 <MimeNarrator> so transfering coins to a freshly installed client (with a fresh wallet.dat) would fix it, yes?
163 2011-11-13 04:11:06 <gmaxwell> No.
164 2011-11-13 04:11:10 <phantomcircuit> yes
165 2011-11-13 04:11:15 <gmaxwell> Gah. Stop.
166 2011-11-13 04:11:24 <phantomcircuit> gmaxwell, yes
167 2011-11-13 04:11:28 <gmaxwell> No. it will not, not until you're running a fixed version.
168 2011-11-13 04:11:33 <cocktopus> ^
169 2011-11-13 04:11:44 <gmaxwell> phantomcircuit: No sir. It will _NOT_. Because the keypool in the new wallet may have leaked.
170 2011-11-13 04:11:58 <gmaxwell> (s/may/almost certantly will have/)
171 2011-11-13 04:12:00 <phantomcircuit> gmaxwell, private keys generated as encrypted are written to the database unencrypted?
172 2011-11-13 04:12:09 <phantomcircuit> lol
173 2011-11-13 04:12:13 <gmaxwell> ...
174 2011-11-13 04:12:20 <phantomcircuit> yeah i get it
175 2011-11-13 04:12:22 <gmaxwell> I thought you knew how the software works?
176 2011-11-13 04:12:24 <gmaxwell> okay.
177 2011-11-13 04:12:30 <phantomcircuit> that's unfortunately
178 2011-11-13 04:12:37 <phantomcircuit> i never looked at the encryption layer
179 2011-11-13 04:14:16 <gmaxwell> Yea, the keypool is generated on startup. You encrypt after that.. so... The fact that the keypool hit the disk wasn't surprising, in fact it was a documented behaivor. The surprising and unfortunate part is that they stayed in the wallet.dat file afterwards.
180 2011-11-13 04:15:21 <nanotube> i thought gavin ran some tests and found that doing a bunch of compactions fixed it as well?
181 2011-11-13 04:16:21 <gmaxwell> nanotube: nope. he still had one left behind in some runs.
182 2011-11-13 04:16:26 <phantomcircuit> nanotube, that's a game of probabilities
183 2011-11-13 04:17:38 <nanotube> heh ic. sucks
184 2011-11-13 05:19:34 <gmaxwell> Better than screwing up NOP, enh?
185 2011-11-13 05:22:46 <roconnor> :D
186 2011-11-13 05:22:57 <roconnor> I don't think I've implemented NOP actually
187 2011-11-13 05:25:43 <justmoon> roconnor, cartels just invite others to come in and undercut the cartel
188 2011-11-13 05:26:04 <gmaxwell> roconnor: who says they haven't? dum dum dum!
189 2011-11-13 05:28:03 <roconnor> justmoon: the idea of the cartel would be to filter out (almost) all non-cartel blocks
190 2011-11-13 05:28:23 <roconnor> giving more money to the cartel, and their pool members
191 2011-11-13 05:28:38 <justmoon> then we would start working on filtering out the cartel
192 2011-11-13 05:28:52 <bd_> roconnor: if you have less than 50% of the network's CPU power, then this actually works against you
193 2011-11-13 05:29:09 <justmoon> bd_, pretty sure he assumes a cartel with >50%
194 2011-11-13 05:29:10 <roconnor> bd_: a cartel of the top pools easily holds more than 50% of the network
195 2011-11-13 05:29:26 <bd_> such a cartel breaks the network's security model :)
196 2011-11-13 05:30:04 <roconnor> bd_: I'm not sure what you mean by that
197 2011-11-13 05:30:59 <bd_> a cartel holding >50% of the network's processing power could double-spend coins, by secretly minting blocks including a spending transaction for coin X, but not revealing them publically until another transaction spending X has been confirmed in another, shorter block chain
198 2011-11-13 05:31:26 <roconnor> bd_: well pools rely on their members, so they pools can't do anything to piss them off very much.
199 2011-11-13 05:31:58 <gmaxwell> bd_: secret fork mining and pool operation aren't super compatible.
200 2011-11-13 05:31:59 <roconnor> but a cartel would actually enchance their member's returns, so they'd probably like that.
201 2011-11-13 05:32:02 <bd_> roconnor: how often do most members get payouts? I could see a pool pulling this off in a timespan shorter than a typical payout interval
202 2011-11-13 05:32:12 <gmaxwell> Though I guess the fact that we've got >1TH of pps pools makes it more possible.
203 2011-11-13 05:32:24 <bd_> assuming the recipient of the voided txn only needs an hour or two worth of confirmations
204 2011-11-13 05:33:06 <gmaxwell> the loss of rate during the forking time would still be quite visible.
205 2011-11-13 05:33:39 <bd_> not if the pool makes up for it by paying its members extra out of pocket in the meantime
206 2011-11-13 05:33:43 <gmaxwell> (and people show up whining every time there is an unlucky run)
207 2011-11-13 05:33:57 <Graet> what long term advantage is there to pool owners to collude to do this?
208 2011-11-13 05:34:03 <gmaxwell> bd_: no, the lack of the pools hashpower on the main chain is still visible.
209 2011-11-13 05:34:14 <roconnor> bd_: whether or not it breaks the security model or not, the incentives seem to be in place for cartel forming.
210 2011-11-13 05:34:17 <gmaxwell> Graet: none. They could debase bitcoin in order to steal it...
211 2011-11-13 05:34:29 <Graet> yep
212 2011-11-13 05:34:44 <bd_> I suppose it would be self-defeating to do something that would reduce confidence in bitcoin security though
213 2011-11-13 05:34:50 <Graet> yes
214 2011-11-13 05:35:12 <justmoon> gmaxwell, would we checkpoint a cartel's profits out of existence? tricky question
215 2011-11-13 05:35:23 <gmaxwell> justmoon: of course not.
216 2011-11-13 05:35:36 <roconnor> It seems like the major pools will eventually form a cartel and become as evil as the banks bitcoiners are trying to subvert :)
217 2011-11-13 05:35:48 <gmaxwell> roconnor: say you own $big_pool_x.  You want to form a cartel.  You ask $big_pool_y to join you.  Big pool y can maximize their income by simply publishing the request.
218 2011-11-13 05:36:01 <nanotube> roconnor: unless the major pools become p2pool :)
219 2011-11-13 05:36:34 <roconnor> gmaxwell: I'm not so sure about that.
220 2011-11-13 05:36:49 <roconnor> nanotube: I guess I'm not familiar with p2pool
221 2011-11-13 05:36:52 <gmaxwell> roconnor: depends on how stupid the hash power is.
222 2011-11-13 05:37:54 <nanotube> roconnor: check out #p2pool and p2pool.org
223 2011-11-13 05:38:08 <justmoon> gmaxwell, i don't think you can assume that it's rational not to form a cartel because you worry about bitcoin's value
224 2011-11-13 05:38:10 <gmaxwell> roconnor: because of the frequent DOS attacks pretty much every pool miner is already setup to easily switch pools. If you found out some pool was doing evil that would endanger the success of bitcoin, you'd switch.
225 2011-11-13 05:38:30 <justmoon> gmaxwell, a cartel could easily make some extra money without endangering bitcoin
226 2011-11-13 05:38:40 <gmaxwell> justmoon: it's rational to not join a cartel containing a big pool because you can do better by exposing their evil.
227 2011-11-13 05:38:46 <justmoon> I think it'd be the user who have an incentive to stop them mostly
228 2011-11-13 05:39:24 <gmaxwell> the ecosystem has mostly done an adequate job keeping the biggest pools below 50%.
229 2011-11-13 05:39:33 <justmoon> gmaxwell, only if miners switch away from the cartel, not to it
230 2011-11-13 05:39:54 <justmoon> gmaxwell, in essence you're just moving the argument back one step, i.e. what is rational to do for the miners
231 2011-11-13 05:40:24 <justmoon> gmaxwell, in my opinion it would be joining a cartel if the cartel seems responsible (i.e. keep bitcoin competitive, just extract as much as they can get away with)
232 2011-11-13 05:40:27 <gmaxwell> welp, the debate is kinda pointless the motivations haven't changed and there is no evidence of this behavior.
233 2011-11-13 05:40:46 <gmaxwell> In the prior three months solo mining I had zero invalid solutions (and a lot of luck)
234 2011-11-13 05:41:27 <roconnor> gmaxwell: it is more profitable for you to join the cartel; because (1) they are now paying out more and (2) no one outside the cartel can mine.
235 2011-11-13 05:41:58 <roconnor> ya, sorry for bringing this up
236 2011-11-13 05:42:34 <gmaxwell> roconnor: and then people widely advertise that bitcoin's security model has been compromised and all your bitcoin lose value. ::shrugs::
237 2011-11-13 05:43:38 <justmoon> gmaxwell, it wouldn't compromise bitcoin's security - as long as the cartel is honest, just it's economic model and the fact that it's decentralized
238 2011-11-13 05:44:29 <justmoon> it would become closer to something like swift perhaps
239 2011-11-13 05:44:45 <roconnor> justmoon: I moved the conversation to #bitcoin
240 2011-11-13 06:07:25 <roconnor> 0  30460221  30440220  2  048c006f  04b68ef7  0  3
241 2011-11-13 06:07:39 <roconnor> 0  30460221...  30440220...  2  048c006f...  04b68ef7...  0  3
242 2011-11-13 06:07:53 <roconnor> how can OP_CHECKMULT succeed on that stack?
243 2011-11-13 06:08:09 <roconnor> there is no way that 2 is the signature for public key 0
244 2011-11-13 06:09:50 <roconnor> etotheipi_: you still awake?
245 2011-11-13 06:20:07 <gmaxwell> OP_CHECKMULT pops an extra element off the stack for no good reason.
246 2011-11-13 06:20:13 <roconnor> oh I don't undrestand OP_CHECK_MULT
247 2011-11-13 06:20:25 <gmaxwell> (I think that was the OP that did that)
248 2011-11-13 06:20:31 <roconnor> the number of sigs and keys can be different :?
249 2011-11-13 06:21:05 <roconnor> oh all sigs must match some public key?
250 2011-11-13 06:21:50 <roconnor> wow
251 2011-11-13 06:22:04 <roconnor> that is quite the number of CHECKSIGs that need to be executed
252 2011-11-13 06:24:28 <gmaxwell> you looking at that dos attack transaction?
253 2011-11-13 06:24:38 <roconnor> nope
254 2011-11-13 06:24:48 <gmaxwell> https://en.bitcoin.it/wiki/Incidents#OP_CHECKSIG_abuse
255 2011-11-13 06:24:48 <roconnor> Just trying to implement OP_CHECKMULTI
256 2011-11-13 06:27:03 <roconnor> this OP_CHECKMULTI seems ... bizzare
257 2011-11-13 06:28:41 <roconnor> and certainly not adquately documented on the wiki
258 2011-11-13 06:30:16 <gmaxwell> roconnor: this patch implements using checkmulti in txn for the official client: https://github.com/groffer/bitcoin/commit/77f429dfaabd9a077662d2c66df72fa47addeff5
259 2011-11-13 06:45:55 <CIA-89> poolserverj: shadders * b2cbf2720659 r229 /poolserverj-main/ (8 files in 6 dirs):
260 2011-11-13 06:45:56 <CIA-89> poolserverj: shadders * 05f11a46ca80 r230 / (3 files in 3 dirs): catch nullpointer where bitcoin connection fails due to bad address
261 2011-11-13 06:45:57 <CIA-89> poolserverj: shadders * 83e3f6857e69 r231 /poolserverj-core/src/main/java/com/shadworld/ (2 files in 2 dirs):
262 2011-11-13 06:45:58 <CIA-89> poolserverj: https://bitcointalk.org/index.php?topic=51226.msg613311#msg613311
263 2011-11-13 06:45:59 <CIA-89> poolserverj: shadders * 3cde080ff0b7 r232 / (8 files in 8 dirs): (log message trimmed)
264 2011-11-13 06:46:00 <CIA-89> poolserverj:  - extra debug output when failed to resolve auth realm credentials
265 2011-11-13 06:46:01 <CIA-89> poolserverj:  - support unregistered realms by creating a clone with the requested realm if not found
266 2011-11-13 06:46:41 <CIA-89> poolserverj: isDebug now true if debug || trace
267 2011-11-13 06:52:40 <CIA-89> bitcoin: Wladimir J. van der Laan master * r405ce5a / src/qt/bitcoingui.cpp :
268 2011-11-13 07:16:50 <CIA-89> poolserverj: shadders * d5e730c5756c r233 /poolserverj-main/src/main/java/com/shadworld/poolserver/servlet/mgmt-header.html: fix javascript confirm message on mgmt interface shutdown and fireblockchange links
269 2011-11-13 07:53:32 <coderrr> anyone see any mistakes here? http://coderrr.wordpress.com/2011/11/13/simplified-summary-of-microsoft-researchs-bitcoin-paper-on-incentivizing-transaction-propagation/
270 2011-11-13 08:03:13 <gmaxwell> coderrr: they're assuming that nodes are incentivized to not relay transactions because they want to keep the fees for themselves.
271 2011-11-13 08:04:06 <gmaxwell> In reality forwarding is super duper cheap, and lots of nodes do it without mining. The originiator of the txn also has a good incentive to spread his transaction far and wide.
272 2011-11-13 08:04:06 <justmoon> for now.
273 2011-11-13 08:04:20 <coderrr> gmaxwell, im not asking if the paper is accurate, just if my summary was accurate
274 2011-11-13 08:05:02 <gmaxwell> Moreover, it would be really bad to bake more assuptions about the current craptastic p2p network into the system. The bitcoin algorithim is completely blind to the transport, and should stay that way.
275 2011-11-13 08:05:53 <gmaxwell> There isn't any reason, e.g. that we couldn't have edge nodes simply hand txn directly to their pick of miners rather than p2p flooding them... it's just that there isn't any great way to bootstrap that, and back when all nodes were miners it didn't make sense.
276 2011-11-13 08:06:23 <gmaxwell> IP multicast would be a pretty no-brainer thing to use for this, for example, if it actually worked across the internets.
277 2011-11-13 08:07:03 <coderrr> i guess i'll add a disclaimer that im not supporting their assumptions :P
278 2011-11-13 08:08:14 <gmaxwell> coderrr: there is other fun crap like, "find miners and then maxsybil txn before handing directly to them"
279 2011-11-13 08:08:31 <coderrr> yea, i thot about that
280 2011-11-13 08:08:49 <gmaxwell> also, there is a much easier way for miners to give incentives to people to relay to them.. just randomly use IP transactions to give lottery payouts to nodes that give them txn with big fees. :)
281 2011-11-13 08:08:51 <coderrr> there could definitely be negative consequences of their proposed solution
282 2011-11-13 08:10:18 <coderrr> gmaxwell,  hey the other day u and thomasv were talking about that word encoding stuff, was that just basically converting a number to base X and then using a word list as the digits ? or was it something totally different
283 2011-11-13 08:10:45 <OneFixt> <gmaxwell> coderrr: there is other fun crap like, "find miners and then maxsybil txn before handing directly to them" <-- yeah, pools would maxsybil it themselves
284 2011-11-13 08:11:22 <gmaxwell> coderrr: it was different same end goal, but using multiple words and a list that was much smaller than the base of the number.
285 2011-11-13 08:11:42 <coderrr> ah ic
286 2011-11-13 08:13:23 <coderrr> i did a test of base 10^6 using unique two word pairs from the cablegate dump and it came out kinda interesting https://gist.github.com/3a9e65bb5d8509abef7d
287 2011-11-13 08:13:29 <gmaxwell> OneFixt: nah, part of the basis of the argument here is that they'd want to give fee to relayers.
288 2011-11-13 08:13:35 <coderrr> seemed like it might be easier to memorize
289 2011-11-13 08:14:12 <OneFixt> gmaxwell: but wouldn't a large miner want to relay it and then mine it himself?
290 2011-11-13 08:15:18 <coderrr> OneFixt, the reward is based on chain length
291 2011-11-13 08:15:25 <coderrr> so if the chain is shorter u get a higher reward
292 2011-11-13 08:15:34 <coderrr> so they actually dont need to maxsybl i think
293 2011-11-13 08:15:41 <OneFixt> hm
294 2011-11-13 08:16:11 <OneFixt> then the incentive is to not forward it... i'll have to read the paper in detail and not the summary
295 2011-11-13 08:16:12 <coderrr> f + ??? (H  h + 1)
296 2011-11-13 08:16:21 <coderrr> where H is max length and h is actual length
297 2011-11-13 08:16:44 <coderrr> yea u should look at details is kinda complicated
298 2011-11-13 08:17:13 <coderrr> that's H-h
299 2011-11-13 08:17:24 <OneFixt> thankfully all nodes already do have an incentive to forward - the health of the network is the health of their wallets
300 2011-11-13 08:17:50 <coderrr> yea, it's in no way an immediate problem
301 2011-11-13 08:23:21 <gmaxwell> coderrr: when I looked at it earlier they didn't seem to even try to address how you could create unstrippable txn chains.
302 2011-11-13 08:23:42 <coderrr> yea, i didnt see that either
303 2011-11-13 08:23:48 <gmaxwell> So I just assumed that they were using bitcoin as a ... toy idea that they could hang their useful payout scheme ideas on.
304 2011-11-13 08:23:57 <coderrr> could be
305 2011-11-13 08:24:20 <gmaxwell> In an actual implementation you would just strip off the identities of all the prior forwarding nodes and pass it on.
306 2011-11-13 08:24:40 <coderrr> right, so is there a way to prevent that though
307 2011-11-13 08:25:12 <OneFixt> i think any system to prevent that is a re-implementation of bitcoin itself
308 2011-11-13 08:25:20 <gmaxwell> It could potentially be done in the right kinds of blinded cryptosystem, but not in anything that looks like bitcoin.
309 2011-11-13 08:25:36 <coderrr> well their proposal is a pretty big reimplementation already
310 2011-11-13 08:25:50 <gmaxwell> coderrr: its not a reimplementation at all though.
311 2011-11-13 08:26:16 <coderrr> i mean i'm not sure their incentive proposal could jsut be tacked on
312 2011-11-13 08:26:20 <gmaxwell> its a payment scheme that is unrelated to bitcoin that uses bitcoin to inspire the thoughts, as far as I can tell.
313 2011-11-13 08:26:35 <OneFixt> i mean proving that the tx chain is unstripped, and doing it in a decentralized system, would require proof-of-work
314 2011-11-13 08:26:46 <gmaxwell> OneFixt: yo dawg.
315 2011-11-13 08:26:51 <OneFixt> =D
316 2011-11-13 08:26:55 <coderrr> hah
317 2011-11-13 08:26:58 <OneFixt> i heard you like work ;)
318 2011-11-13 08:27:20 <gmaxwell> I heard you like decenteralized consensus algorithims...
319 2011-11-13 08:27:49 <gmaxwell> But who will incentivize the relay of the relay incentive consensus blocks?
320 2011-11-13 08:28:48 <gmaxwell> You can creat a system that works this way directly, e.g. when you relay a txn you encrypt (part of) it. And then the txn is eventually mined and in order to collect your reward you'd disclose the encryption keys you use.
321 2011-11-13 08:29:01 <coderrr> they do say this: Each node on the path in the tree from the seed to the authorizer appears on this
322 2011-11-13 08:29:01 <gmaxwell> but man, thats bloated and ugly.
323 2011-11-13 08:29:15 <coderrr> chain (nodes are not able to remove their predecessors from the chain due to the use of cryptographic
324 2011-11-13 08:29:19 <coderrr> signatures),
325 2011-11-13 08:29:26 <coderrr> but i dont think they expand on it
326 2011-11-13 08:29:33 <gmaxwell> yea, that doesn't make any sense however.
327 2011-11-13 08:30:04 <gmaxwell> SIGNC(SIGNB(SIGNA(TX()))) .. I can strip it all the way down to TX().
328 2011-11-13 08:30:25 <coderrr> i think the way it works is
329 2011-11-13 08:30:44 <coderrr> when the originator sends it out, they sign it with the pubkey of who theyre sending it to
330 2011-11-13 08:31:00 <coderrr> so its only valid if you have the correspodning privkey
331 2011-11-13 08:31:09 <coderrr> so when u broadcast, you broadcast a diff tx to each node
332 2011-11-13 08:31:09 <Graet> <gmaxwell> but man, thats bloated and ugly. <, um but fits with ms policy?
333 2011-11-13 08:31:15 <gmaxwell> Hm? still doesn't work.
334 2011-11-13 08:31:16 <coderrr> signed with their pubkey
335 2011-11-13 08:31:20 <coderrr> does that work
336 2011-11-13 08:31:24 <coderrr> ?
337 2011-11-13 08:31:40 <gmaxwell> Graet: MS research does some neat stuff,.. that has nothing to do with MS's products. :)
338 2011-11-13 08:31:57 <coderrr> hrm yea... cuz you can re-sign it urself, yea not sure
339 2011-11-13 08:32:01 <gmaxwell> coderrr: No, because you can still strip it... yea.
340 2011-11-13 08:32:52 <coderrr> ugh ,theres no way they overlooked that, theres gotta be something
341 2011-11-13 08:33:23 <gmaxwell> lets see.. you take the txn and add to it SIGN_A(TXN+giving_to_coderr) .. then SIGN_CODEERR(SIGN_A(TXN+giving_to_coderr)+giving_to_Graet) ... then SIGN_GRAET(SIGN_CODEERR(SIGN_A(TXN+giving_to_coderr)+giving_to_Graet)+giving_to_OneFixt)
342 2011-11-13 08:33:31 <gmaxwell> but .. thats horribly bloated too.
343 2011-11-13 08:33:48 <coderrr> yea
344 2011-11-13 08:33:56 <coderrr> that works right ?
345 2011-11-13 08:34:10 <gmaxwell> Yes, that works though. Terribly bloated and would also bloat the blockchain.
346 2011-11-13 08:34:15 <coderrr> thats not really _that_ bloated
347 2011-11-13 08:34:23 <gmaxwell> Perhaps there is a clever way to make that prunable though.
348 2011-11-13 08:34:57 <gmaxwell> You'll and 2/3rds the size of a normal txn at every hop.
349 2011-11-13 08:35:01 <coderrr> yea here it is
350 2011-11-13 08:35:05 <coderrr> We modify
351 2011-11-13 08:35:19 <coderrr> the protocol so that every node that transfers the transaction to its children cryptographically signs
352 2011-11-13 08:35:33 <coderrr> the transaction, and species the child to whom the information is being sent using that
353 2011-11-13 08:35:38 <coderrr> childs public key
354 2011-11-13 08:36:07 <gmaxwell> Yes, so you need to add 190 bytes of data every hop... which is pretty terrible.
355 2011-11-13 08:36:14 <gmaxwell> but yes, that would work.
356 2011-11-13 08:36:35 <OneFixt> if the number of hops > H there's no more reward for forwarding?
357 2011-11-13 08:36:56 <coderrr> yea
358 2011-11-13 08:37:09 <OneFixt> wouldn't that stop all forwarding after H hops?
359 2011-11-13 08:37:17 <gmaxwell> Sure.
360 2011-11-13 08:37:31 <coderrr> yea, but they assume forwading is already not happening due to no incentive
361 2011-11-13 08:37:33 <gmaxwell> (even if they would have otherwise done it for free.. go go incentives fucking things up)
362 2011-11-13 08:37:38 <coderrr> so its a better situation than that
363 2011-11-13 08:37:53 <OneFixt> gmaxwell: exactly
364 2011-11-13 08:38:02 <gmaxwell> coderrr: due to assuming there is a disincentive because nodes want to keep fees for themselves.
365 2011-11-13 08:38:12 <gmaxwell> Which is a bad assumption for bitcoin.
366 2011-11-13 08:39:02 <coderrr> yea, hard to predict the future though
367 2011-11-13 08:39:10 <gmaxwell> hm. amusingly, if we changed how signature checking applied to scripts, OP_EVAL almost allows this scheme.
368 2011-11-13 08:39:32 <gmaxwell> but the overhead is still terrible.
369 2011-11-13 08:39:52 <OneFixt> if the problem were real, a much easier solution could be to simply modify each node to send to more than 8 nodes
370 2011-11-13 08:40:22 <gmaxwell> OneFixt: just get miners announce deposit IP addressess, and have nodes deliver it to miners themselves.
371 2011-11-13 08:40:26 <OneFixt> or to have an available list of mining nodes
372 2011-11-13 08:40:30 <gmaxwell> jinx
373 2011-11-13 08:40:32 <OneFixt> right
374 2011-11-13 08:41:04 <gmaxwell> you can also encourage behavior by playing a little lottery using ip transactions, though we're going to remove them. :(
375 2011-11-13 08:41:48 <OneFixt> ip tx do sound impossible to secure
376 2011-11-13 08:41:57 <OneFixt> though interesting to play with
377 2011-11-13 08:42:56 <OneFixt> you could always have servers give a bitcoin address when a standardized request is sent to them though
378 2011-11-13 08:43:08 <OneFixt> that emulates sending by ip
379 2011-11-13 08:44:28 <gmaxwell> OneFixt: hm. I don't see what complaint you have about IP transactions which wouldn't apply to anything substantially similar.
380 2011-11-13 08:44:44 <OneFixt> how does it work with computers on a shared ip?
381 2011-11-13 08:45:20 <gmaxwell> OneFixt: if you were able to measure the node you wanted to incentivize then you have a way of communicating with it already.
382 2011-11-13 08:46:05 <gmaxwell> e.g. if you're trying to reward nodes for relaying to you... you have a connection up for it to relay to you over.. or if you're trying to incentivze people to run listening nodes or running a current version.. you just connect to it.
383 2011-11-13 08:47:13 <gmaxwell> There are two risks with IP transactions, one applies here one doesn't. The one that doesn't is the MITM risk... there isn't a risk because you don't care about the particular identity of the node for a good-behavior-lottery.
384 2011-11-13 08:47:18 <OneFixt> yes that's true, i was just drifting off into general thought about IP t
385 2011-11-13 08:47:19 <OneFixt> tx
386 2011-11-13 08:47:23 <gmaxwell> The other risk is the marked bills attack.
387 2011-11-13 08:47:46 <gmaxwell> Where you rain 1e-8 coins on all the nodes you can connect to...
388 2011-11-13 08:48:11 <gmaxwell> then when you see those used in txn you'll learn the IPs of the persons originating the txn.
389 2011-11-13 08:48:17 <gmaxwell> And that.. I have no solutions for.
390 2011-11-13 08:48:47 <OneFixt> that's a neat attack
391 2011-11-13 08:49:52 <gmaxwell> yea, also applicable to things like blackmarket sites.. rain nanocoins on them.. and then use the nanocoins to identify txn from the blackmarket showing up at exchanges.
392 2011-11-13 08:50:37 <OneFixt> the site could potentially identify and launder those nanocoins
393 2011-11-13 08:51:06 <gmaxwell> Yes. Potentially. Any attack has a countermeasure.
394 2011-11-13 08:51:25 <extor> Can someone explain to me why I must have an account on bit-pay in order to use the WHMCS plugin here? https://bit-pay.com/clientBilling.html
395 2011-11-13 08:51:29 <gmaxwell> Likewise you could improve things for the iptxn case by doing the same in the client.  In practice, no one will .. lots of complexity.
396 2011-11-13 08:52:18 <extor> Couldn't I just look at the sauce and mod it to work with my own wallet?
397 2011-11-13 08:52:57 <Habbie> extor, presumably, that WHMCS plugin uses the bit-pay API, not the bitcoind API. But looking at the source is always informative.
398 2011-11-13 08:53:38 <extor> Habbie, it just makes me wonder why bit-pay would set themselves up as a middleman for a supposedly anonymous currency. Puzzling.
399 2011-11-13 08:54:20 <Habbie> extor, if you're running a hosting service, why would you care about anonymity on your end?
400 2011-11-13 08:54:53 <extor> Habbie, I don't.
401 2011-11-13 08:55:31 <Habbie> and presumably, bit-pay makes some money off transactions
402 2011-11-13 08:56:09 <gmaxwell> They'll also pay you in USD rather than bitcoin, if you want.
403 2011-11-13 08:56:44 <gmaxwell> (I'd never heard of them before now for all I know its a scam. :) )
404 2011-11-13 08:56:50 <extor> Oh I didn't know bit-pay would convert it for you
405 2011-11-13 08:57:00 <gmaxwell> extor: see their FAQ
406 2011-11-13 08:57:29 <extor> There's another WHMCS plugin that is supposed to not work right now. I wish I was code savvy so I could just mod it for my use
407 2011-11-13 08:57:43 <gmaxwell> No time to learn like the present.
408 2011-11-13 08:57:48 <OneFixt> gmaxwell: they have some nice videos http://youtu.be/YZ-pqo0cLcE
409 2011-11-13 08:59:27 <OneFixt> http://youtu.be/DNpcf9rSBIk   win
410 2011-11-13 09:00:21 <gmaxwell> do.. people use QR codes to send data between phones like that!@#?!
411 2011-11-13 09:00:43 <OneFixt> i don't even have a phone capable of it so i don't know =)
412 2011-11-13 09:01:04 <gmaxwell> IRDA ... Bluetooth.. oh fuck it, lets jus display hieroglyphics. Perhaps the next gen phones will just use smoke signals.
413 2011-11-13 09:01:41 <OneFixt> we should yell private keys at each other
414 2011-11-13 09:02:20 <gmaxwell> hm. I should make a scheme to encode binary -> obscenity.
415 2011-11-13 09:02:40 <OneFixt> i can actually see that having a place in the world
416 2011-11-13 09:08:05 <justmoon> so what would be a better way than QR?
417 2011-11-13 09:09:45 <OneFixt> semaphores
418 2011-11-13 09:10:01 <gmaxwell> "MONKLEIGH DOMINATRIX PENAS TESTICLE PAKI KUNT KIKE PUSSY VITTU ARSCHLOCH MIBUN ASSHOLES NIGGA SEXY OROSPU RECKTUM MASTERBATE NAZIS PICKA PAKY PACKI DOMINATRICKS ENEMA KLOOTZAK INJUN FAEN TEETS AZZHOLE HELVETE KNOB FUCKING ORGASUM" < here is a bitcoin address in 'badcode'.   (don't blame me for the poorly spelled badwords, I got them from the internets)
419 2011-11-13 09:10:16 <OneFixt> i do like qr though, since it can be printed
420 2011-11-13 09:10:34 <gmaxwell> justmoon: there have been many different protocols for device to device communication over the years. QR is pretty darn crude, but I guess nothing else actually work(s/ed).
421 2011-11-13 09:11:04 <gmaxwell> sure, for printed things QR isn't especially ugly... but for device to device it seems weird.
422 2011-11-13 09:11:44 <gmaxwell> (because you'd probably like to have a duplex channel that can retransmit.. perhaps with low latency and high bandwidth too)
423 2011-11-13 09:17:18 <Eliel> has this paper been talked about yet? http://research.microsoft.com/pubs/156072/bitcoin.pdf
424 2011-11-13 09:18:10 <coderrr> Eliel, yea scroll up
425 2011-11-13 09:18:19 <OneFixt> gmaxwell: what's the algo for the words? alphabetic ordering of each letter signifying 1 or 0?
426 2011-11-13 09:18:37 <OneFixt> hm, that could be a fun encoding...
427 2011-11-13 09:39:45 <Eliel> hmm... the entities that would have the incentive to encourage relaying of transactions are the owner of the transaction, the receiver of the transaction and in a subtle way, miners.
428 2011-11-13 09:40:11 <Eliel> miners have the incentive to get transactions but not to spread them to other miners.
429 2011-11-13 09:40:31 <Eliel> while sender and receiver have the incentive to get the tx to every miner out there.
430 2011-11-13 09:41:38 <Eliel> so, if this is ever implemented, it sounds very much like it ought to be part of the fee system.
431 2011-11-13 09:42:09 <Eliel> and the central management it needs handled either by sender or receiver or both.
432 2011-11-13 09:48:29 <coderrr> Eliel, there's probably an incentive for miners to relay it also, you assume some other miners probably have the tx already, so if you dont relay it you might not solve the block first and get nothing, but if you do relay it, some miner in your chain may solve it and then you at least get  some reward
433 2011-11-13 09:49:44 <coderrr> how that is optimized is what the math in the paper deals with i think
434 2011-11-13 09:50:16 <Eliel> ah, yes, true. But it still needs central management of the chain so it doesn't get falsified.
435 2011-11-13 09:50:40 <coderrr> Eliel, what do you mean ?
436 2011-11-13 09:50:52 <Eliel> the incentive chain proposed in the paper
437 2011-11-13 09:51:07 <coderrr> i mena, what do you mean by falsified ?
438 2011-11-13 09:51:31 <Eliel> well, nodes have an incentive to drop it all out and pretend they started it.
439 2011-11-13 09:52:02 <coderrr> Eliel, we went over that earlier, how its possilbe to make it so you cant do that
440 2011-11-13 09:52:16 <Eliel> I better reread it, I think I missed it
441 2011-11-13 09:52:31 <coderrr> <gmaxwell> lets see.. you take the txn and add to it SIGN_A(TXN+giving_to_coderr) .. then SIGN_CODEERR(SIGN_A(TXN+giving_to_coderr)+giving_to_Graet) ... then SIGN_GRAET(SIGN_CODEERR(SIGN_A(TXN+giving_to_coderr)+giving_to_Graet)+giving_to_OneFixt)
442 2011-11-13 09:52:36 <coderrr> We modify
443 2011-11-13 09:52:49 <coderrr> the protocol so that every node that transfers the transaction to its children cryptographically signs
444 2011-11-13 09:53:03 <coderrr> the transaction, and species the child to whom the information is being sent using that
445 2011-11-13 09:53:09 <coderrr> childs public key
446 2011-11-13 09:53:39 <coderrr> so you dont broadcast the same data to each node, you broadcast a unique tx that specifies the pubkey that it's being sent to
447 2011-11-13 09:54:35 <Eliel> how does that prevent yanking the path off the tx?
448 2011-11-13 09:55:20 <Eliel> the Tx still needs to be clearly readably, what's to prevent a node from just pretending they're the first relay?
449 2011-11-13 10:00:11 <coderrr> SIGN_A(TXN+giving_to_coderr)
450 2011-11-13 10:00:22 <coderrr> only A can change that giving_to_coderr to giving_to_eliel
451 2011-11-13 10:01:18 <coderrr> they change the protocol to require that you include that giving_to field at each point
452 2011-11-13 10:01:48 <Eliel> oh, you mean A is the sender and that signature is part of the transaction? It can't be replaced by someone else while keeping the Tx valid?
453 2011-11-13 10:02:05 <coderrr> right
454 2011-11-13 10:03:38 <Eliel> ok, that way it could work.
455 2011-11-13 10:04:03 <Eliel> although, it'd also serve to quite clearly identify the nodes on the network too.
456 2011-11-13 10:04:09 <Eliel> Not sure if that's desired.
457 2011-11-13 10:06:28 <TD> i posted to the forum thread about it
458 2011-11-13 10:06:39 <TD> https://bitcointalk.org/index.php?topic=51712.0
459 2011-11-13 10:06:47 <TD> broadcast is probably going to become less important over time
460 2011-11-13 10:06:49 <TD> hey devrandom
461 2011-11-13 16:12:29 <CIA-89> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r263c5dc / lib/db/leveldb/storage.js : Actually obey path from config url. (+8 more commits...) - http://git.io/wCwY9w
462 2011-11-13 16:19:19 <CIA-89> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r6b165fb / (3 files in 3 dirs): Implemented index for spent outpoints in LevelDB backend. - http://git.io/-zXsXg
463 2011-11-13 16:19:20 <CIA-89> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r7984db0 / (test/blockchain.js test/simnet.js test/storage.js): Unique prefixes for all unittest temporary datastores. - http://git.io/9qlgnw
464 2011-11-13 16:26:22 <CIA-89> libbitcoin: genjix * re92c1798de6d / (21 files in 7 dirs): bdb plugin reading/saving blocks with txs.
465 2011-11-13 16:34:41 <roconnor> sipa: I don't suppose you'd be interested in editing the wiki to state how negative numbers are represented.
466 2011-11-13 16:35:43 <cjdelisle> isn't an MPI just represented as a 2's complement byte array?
467 2011-11-13 16:35:59 <cjdelisle> it should be well documented in the openssl documentation
468 2011-11-13 16:37:29 <sipa> cjdelisle: apparently not - it has an explicit sign bit
469 2011-11-13 16:37:46 <cjdelisle> where do you get this infoz?
470 2011-11-13 16:38:01 <sipa> from openssl's crypto/bn/bn_mpi.c
471 2011-11-13 16:38:13 <sipa> i misread it earlier
472 2011-11-13 16:38:47 <sipa> but if the number of bits to represent the absolute value is a multiple of 8, an extra byte is prepended in front
473 2011-11-13 16:38:55 <cjdelisle> hmm, I think it's documented in the libgcrypt documentation since it can export to "openssl format"
474 2011-11-13 16:39:05 <sipa> and the sign is just encoded by (|= 0x80)'ing the first byte
475 2011-11-13 16:42:19 <cjdelisle> sipa: that is 2's complement, the only difference is that they truncate the top byte if it happens to be 0
476 2011-11-13 16:42:30 <sipa> no
477 2011-11-13 16:42:40 <sipa> -1 is encoded as 0x81
478 2011-11-13 16:42:46 <sipa> not as 0xFF
479 2011-11-13 16:44:03 <cjdelisle> oh ic
480 2011-11-13 16:44:20 <cjdelisle> so it's an extra flag bit but if the top byte is 0x00 then it's dropped
481 2011-11-13 16:44:27 <cjdelisle> makes sense to me
482 2011-11-13 16:44:43 <cjdelisle> I remember, this is documented in the gcrypt documentation.
483 2011-11-13 16:45:19 <sipa> it also means that the number 128 would be encoded as 0x00 0x80
484 2011-11-13 16:45:32 <sipa> as 0x80 means negative zero
485 2011-11-13 16:45:38 <cjdelisle> oh indeed
486 2011-11-13 16:45:52 <cjdelisle> so the top number 0 isn't *always* dropped.
487 2011-11-13 16:45:56 <cjdelisle> goodjob openssl
488 2011-11-13 16:46:04 <sipa> 18:38:47 < sipa> but if the number of bits to represent the absolute value is a multiple of 8, an extra byte is prepended in front
489 2011-11-13 16:47:12 <Eliel> what if the governments of several big countries (with most of the bitcoin mining power) made a law that dictates that they're not allowed to include any transaction in any blocks they mine unless the target (and/or sender) addresses are on an approved addresses list.
490 2011-11-13 16:48:15 <sipa> that would cripple bitcoin, even for allowed purposes
491 2011-11-13 16:48:40 <Eliel> yes, it would. It'd basically mean mandatory registration of your addresses.
492 2011-11-13 16:48:59 <sipa> which would cripple bitcoin, even for those willing to use registered addresses
493 2011-11-13 16:49:15 <sipa> privacy of the system relies on using frsh addresses
494 2011-11-13 16:50:02 <Eliel> basically, I'm wondering if there's any way to counter that.
495 2011-11-13 16:50:35 <sipa> such a law would mean outlawing bitcoin's intended usage
496 2011-11-13 16:55:59 <etotheipi_> on that note, how difficult do you think it would be to add encryption to node-to-node communication?
497 2011-11-13 16:56:34 <etotheipi_> it wouldn't require a protocol change, would it?
498 2011-11-13 16:56:55 <sipa> not that hard, but i'm not sure how useful it would be
499 2011-11-13 16:57:18 <etotheipi_> well, even if they can identify the BTC packets, they can't identify which transactions are in them
500 2011-11-13 16:57:35 <sipa> if "they" are powerful enough, they'll just mitm
501 2011-11-13 16:58:01 <sipa> end-to-end encryption only works against passive eavesdroppers
502 2011-11-13 16:58:54 <etotheipi_> actually you're right:  the law would affect the miners, not the individual nodes -- and even with encrypted communication, it should be fairly easy to identify which miner created a block
503 2011-11-13 16:59:44 <wumpus> just run it over tor...
504 2011-11-13 17:00:02 <etotheipi_> but I think that the pools would have to follow suit
505 2011-11-13 17:00:33 <sipa> wumpus: yes, that's even how satoshi used bitcoin
506 2011-11-13 17:00:45 <wumpus> there's really no use in implementing overlay or encryption support in bitcoin itself, it's a too big a responsibility and very hard to do right
507 2011-11-13 17:00:48 <etotheipi_> most blocks are mined by the pools, and with anyone being able to connect to each pool, it would be fairly easy to determine which pool created a block
508 2011-11-13 17:01:14 <etotheipi_> wumpus, fair enough
509 2011-11-13 17:01:15 <wumpus> see how much time it takes people like ioerror to make tor *reasonably* private, a overlay network which has one specific function is really doomed to fail
510 2011-11-13 17:01:35 <wumpus> sipa: yup
511 2011-11-13 17:02:28 <sipa> well, end-to-end encryption (not a full overlay) does already have an advantage: privacy from passive attackers
512 2011-11-13 17:02:53 <sipa> but using tor is easier, and has more advantages
513 2011-11-13 17:03:16 <etotheipi_> sipa, and Tor is not trivial to use... not for average users
514 2011-11-13 17:03:25 <wumpus> tor is very easy to use with the bundle
515 2011-11-13 17:03:28 <wumpus> much easier than bitcoin
516 2011-11-13 17:03:37 <roconnor> etotheipi_: do you mean network encryption between peers? or something affecting the blockchain?
517 2011-11-13 17:03:51 <etotheipi_> the really devoted folks will figure it out, but the average user won't, and I think the average user needs it in order for it to be useful
518 2011-11-13 17:04:10 <wumpus> tor is really focusing on the average user/activist lately
519 2011-11-13 17:04:27 <etotheipi_> roconnor, I was just throwing out the idea of encrypted communication as a thought experiment about what it would achieve... it sounds like not much, though
520 2011-11-13 17:04:27 <sipa> etotheipi_: then maybe we need a bitcoin distribution that contains tor, and automatically uses it
521 2011-11-13 17:04:34 <wumpus> sipa: yes
522 2011-11-13 17:04:36 <Eliel> there is some work being done towards moving bitcoin blocks over freenet, for example.
523 2011-11-13 17:04:38 <wumpus> that'd be a good idea
524 2011-11-13 17:04:42 <etotheipi_> sipa, I had thought about that... but it's really tough for developers, too
525 2011-11-13 17:04:58 <etotheipi_> tor-integrated-into-client is in my long-term plans
526 2011-11-13 17:05:07 <wumpus> maybe even use a patched bitcoin that can *only* use the bundled tor, so make it extra safe (the tor bundle does similar things with the packaged applications)
527 2011-11-13 17:05:08 <sipa> freenet is indeed antoher option
528 2011-11-13 17:05:11 <etotheipi_> but first I have to get *a* client implemented :)
529 2011-11-13 17:05:26 <roconnor> etotheipi_: there is a group interested on distributing the blockchain (and transactions?) through freenet
530 2011-11-13 17:05:31 <roconnor> on #btcfn
531 2011-11-13 17:05:55 <wumpus> does freenet also support socks? or does it require specific support?
532 2011-11-13 17:06:00 <Eliel> freenet and it's darknet mode could theoretically work in china too.
533 2011-11-13 17:06:14 <Eliel> wumpus: freenet isn't a gateway protocol.
534 2011-11-13 17:06:31 <wumpus> tor also works in china, though you can't use the published relays
535 2011-11-13 17:06:35 <sipa> wumpus: freenet is an anonymous distributed storage engine, afaik
536 2011-11-13 17:06:47 <wumpus> ahh I was confused with i2p
537 2011-11-13 17:10:04 <etotheipi_> anyone know if there's a way to guarantee that python will clean up/deallocate memory?
538 2011-11-13 17:10:04 <roconnor> sipa: Do you know of any theorem that the memory usage of the script in O(n^2) in the lenght of the script?
539 2011-11-13 17:10:11 <roconnor> anyone looked into this?
540 2011-11-13 17:10:32 <sipa> roconnor: wah?
541 2011-11-13 17:15:24 <eueueue> Hi, is it possible know how many clients are connected on the network?
542 2011-11-13 17:15:36 <eueueue> how many people are with bitcoin client opened
543 2011-11-13 17:15:54 <CIA-89> libbitcoin: genjix * r79ca5761c170 / (21 files in 7 dirs): bdb plugin reading/saving blocks with txs.
544 2011-11-13 17:16:35 <eueueue> abd distinguish it by country
545 2011-11-13 17:16:49 <wumpus> etotheipi_: use the gc module
546 2011-11-13 17:18:10 <roconnor> sipa: the operations that have been disabled: multiplication, etc, seem to be designed to limit the memory use of scripting computations
547 2011-11-13 17:18:12 <wumpus> though with cpython it's the case that object immediately are deallocated once the refcount goes to zero afaik, so gc mainly cleans up reference cycles
548 2011-11-13 17:18:25 <Eliel> eueueue: http://bitcoinstatus.rowit.co.uk/
549 2011-11-13 17:18:34 <eueueue> will see
550 2011-11-13 17:19:07 <eueueue> Eliel: not possible real time?
551 2011-11-13 17:19:25 <Eliel> eueueue: if you want accuracy, no.
552 2011-11-13 17:19:37 <eueueue> ok
553 2011-11-13 17:19:43 <etotheipi_> wumpus, thanks, I'll look into that... I'm using cpython, and it looks like gc doesn't allow me to explicitly state what memory to clean up, but it can improve the situation
554 2011-11-13 17:19:52 <etotheipi_> err.. *not* using cpython
555 2011-11-13 17:21:04 <etotheipi_> I've got a pure-python module which does ECDSA signing, and I want to make sure it's cleaning up after itself
556 2011-11-13 17:21:31 <wumpus> cpython is the default python that most people are using
557 2011-11-13 17:21:52 <sipa> roconnor: it is my impression that disabling all those operations was over-cautious
558 2011-11-13 17:21:57 <etotheipi_> it's not critical, though, because I intend to offload all such secure operations to C++ (pulled in via SWIG) where I have better control... but I want to keep the pure-python part functional
559 2011-11-13 17:22:11 <wumpus> sipa: yes, afaik it was just to be sure
560 2011-11-13 17:22:37 <wumpus> some operations were unsafe, so it was decided that everything not directly needed was disabled
561 2011-11-13 17:23:08 <etotheipi_> wumpus, ohh... I'm thinking of a C-code importer module for python... I thought cpython was one of them, but I got mixed up
562 2011-11-13 17:23:32 <wumpus> etotheipi_:  maybe you're confused with cython :)
563 2011-11-13 17:23:39 <etotheipi_> wumpus, that's exactly it
564 2011-11-13 17:24:22 <wumpus> but for security it's  a different story; gc doesn't give you any guarantee that the memory is overwritten, just freed for re-use
565 2011-11-13 17:25:36 <etotheipi_> wumpus, that's better than nothing, though, since the biggest concern would be swapping
566 2011-11-13 17:25:47 <etotheipi_> if the memory is "freed", It wouldn't be swapped, as far as I know
567 2011-11-13 17:25:57 <sipa> surely it can
568 2011-11-13 17:26:09 <sipa> it is not erased, just marked available for reuse
569 2011-11-13 17:26:20 <sipa> and unused parts are easily swapped out
570 2011-11-13 17:26:42 <etotheipi_> sipa, agreed that it's not erased, but why would the system swap memory that is only "available" for use
571 2011-11-13 17:26:47 <luke-jr> Linux doesn't really free memory ever
572 2011-11-13 17:26:58 <sipa> because the system doesn't know it is available
573 2011-11-13 17:27:10 <sipa> only the memory allocator (which is user space)
574 2011-11-13 17:27:11 <etotheipi_> damnit
575 2011-11-13 17:27:12 <luke-jr> glibc just marks it free for reuse *within the application*
576 2011-11-13 17:27:22 <etotheipi_> okay, you guys win
577 2011-11-13 17:27:55 <etotheipi_> this is why I'm using secure allocators in C++... but I wanted to maintain some sense of "security" even the pure-python module is used
578 2011-11-13 17:27:59 <luke-jr> the only way to really allocate/free memory in Linux is mmap
579 2011-11-13 17:28:21 <etotheipi_> but it sounds like it's not easy to get python to really clean up that memory
580 2011-11-13 17:29:53 <Lolcust_Backup> join bitcoin
581 2011-11-13 17:30:02 <sipa> roconnor: did you read about my idea for a lazy script evaluator
582 2011-11-13 17:42:42 <roconnor> sipa: nope
583 2011-11-13 17:46:03 <wumpus> luke-jr: afaik at least for large allocations glibc's malloc uses mmap/mmunmap
584 2011-11-13 17:46:11 <roconnor> sipa: what is it?
585 2011-11-13 17:47:32 <luke-jr> wumpus: true
586 2011-11-13 17:49:37 <cjdelisle> wow I can't believe there are no converters for switching between openssl MPI and like any other format...
587 2011-11-13 17:50:11 <cjdelisle> I looked up the gcrypt apis and they don't parse or serialize openssl mpi, only openpgp's
588 2011-11-13 18:02:52 <eueueue> Make sense use other bitcoin clients, only when they be able to export private keys?
589 2011-11-13 18:06:28 <copumpkin> http://research.microsoft.com/pubs/156072/bitcoin.pdf ?
590 2011-11-13 18:10:15 <firesign> copumpkin: fun paper read ja
591 2011-11-13 18:10:49 <roconnor> copumpkin: do you have a summery?
592 2011-11-13 18:11:05 <copumpkin> I've only read the abstract, but I can summarize that for you if you want :P
593 2011-11-13 18:15:26 <firesign> paper clean ja
594 2011-11-13 18:23:36 <sipa> i believe bitcoin doesn't get it right either
595 2011-11-13 18:23:38 <etotheipi_> yeah, it's a pain
596 2011-11-13 18:23:50 <etotheipi_> although if you have OP_CHECKSIG, it's a lot easier
597 2011-11-13 18:24:03 <firesign> reward microsoft research people
598 2011-11-13 18:24:38 <roconnor> etotheipi_: the specification for CHECKMULTISIG is very bizzare to me.
599 2011-11-13 18:24:54 <roconnor> firesign: oh is it written by microsoft research?
600 2011-11-13 18:25:05 <etotheipi_> oh, I am looking at my code now... I tried following the Satoshi client implementaiton, and it was a mess
601 2011-11-13 18:25:07 <firesign> paper copumpkin link
602 2011-11-13 18:25:28 <roconnor> etotheipi_: good for you; I tried following the wiki, and it was a disaster :D
603 2011-11-13 18:25:42 <firesign> http://research.microsoft.com/pubs/156072/bitcoin.pdf
604 2011-11-13 18:25:47 <etotheipi_> roconnor, which wiki?
605 2011-11-13 18:26:19 <roconnor> etotheipi_: https://en.bitcoin.it/wiki/Script
606 2011-11-13 18:26:56 <roconnor> firesign: ya, microsoft research is pretty great.  It is important for them not to be confused with mircosoft
607 2011-11-13 18:27:10 <etotheipi_> roconnor, the wiki doesn't really tell you much
608 2011-11-13 18:27:20 <roconnor> nope
609 2011-11-13 18:27:27 <etotheipi_> I highly recommend looking at the satoshi implementation, or mine (which is basically the same thing, just in python)
610 2011-11-13 18:27:30 <firesign> PR good for M$ responsible social
611 2011-11-13 18:27:42 <roconnor> "For each signature and public key pair, OP_CHECKSIG is executed". <-- this is false
612 2011-11-13 18:27:48 <etotheipi_> right...
613 2011-11-13 18:28:09 <etotheipi_> it seems that you can have more pubKeys than sigs
614 2011-11-13 18:28:16 <etotheipi_> and it will walk down the list for each sig looking for a key
615 2011-11-13 18:28:25 <etotheipi_> but they must be in the same order
616 2011-11-13 18:28:41 <roconnor> etotheipi_: the tricky bit was trying to figure out from which end they walk down
617 2011-11-13 18:29:12 <etotheipi_> roconnor, just FYI... I recognize the value of working towards the standards, and I definitely think the standards should be updated to reflect the intent of code
618 2011-11-13 18:29:24 <etotheipi_> roconnor, the problem is, the Satoshi implementation is essentially "truth"
619 2011-11-13 18:29:36 <etotheipi_> regardless of whether it matches the spec
620 2011-11-13 18:29:52 <etotheipi_> (or intent, for that matter)
621 2011-11-13 18:30:21 <roconnor> yep
622 2011-11-13 18:30:38 <roconnor> and that is why OP_MULTISIG pops an extra stack item
623 2011-11-13 18:30:40 <etotheipi_> so I would default towards that
624 2011-11-13 18:31:02 <etotheipi_> I copied all 0.4.0 code into a MSVS project and use it to go scavenger hunting for these details
625 2011-11-13 18:31:23 <roconnor> Why didn't they just fix the CHECKMUTLISIG before people started using it?
626 2011-11-13 18:31:46 <etotheipi_> I bet no one noticed, since OP_CHECKMULTISIG isn't standard... there wasn't any scripts in the blockchain for them to realize it was wrong
627 2011-11-13 18:32:14 <roconnor> if there weren't any scripts in the block chain with the opcode, then you can just change the meaning of the opcode :)
628 2011-11-13 18:32:54 <etotheipi_> the problem is that it's still possible to inject scripts with those opcodes in the blockchain, even though the default client doesn't consider them standard
629 2011-11-13 18:33:03 <roconnor> that is true
630 2011-11-13 18:33:24 <etotheipi_> once the devs make that change, someone can mine a block with a tx that is invalid in the old chain but valid in the new chain (or vice versa) and fork the network
631 2011-11-13 18:33:27 <roconnor> you'd have to check that none of the scripts have this opcode; even the unexecuted ones
632 2011-11-13 18:39:22 <etotheipi_> anyone have an update on the wallet-encryption update?
633 2011-11-13 18:40:47 <etotheipi_> anyone want to donate to me for finding that bug ? :))
634 2011-11-13 18:41:09 <roconnor> etotheipi_: I can give you some testnet coins :)
635 2011-11-13 18:41:10 <etotheipi_> (err.. for disclosing the bug, instead of exploiting it... that's a bit more accurage)
636 2011-11-13 18:42:40 <copumpkin> MSR is behind a big chunk of the haskell development
637 2011-11-13 18:42:42 <copumpkin> so I'm a fan :)
638 2011-11-13 18:44:18 <roconnor> etotheipi_: heh, right; since you found the bug you should be able to exploit it to donate to yourself :P
639 2011-11-13 18:49:00 <etotheipi_> I suppose I could, if I had anyone elses' backed up wallets... but I'm more interested in seeing BTC succeed
640 2011-11-13 18:49:24 <etotheipi_> nothing will destroy the community faster than peoples' money just magically disappearing
641 2011-11-13 18:49:25 <roconnor> :D
642 2011-11-13 18:49:32 <sipa> etotheipi_: there's a pull request with a fix
643 2011-11-13 18:49:40 <sipa> but it needs testing
644 2011-11-13 18:50:02 <etotheipi_> sipa, I assume you need to compile the client yourself...?
645 2011-11-13 18:50:10 <sipa> yes
646 2011-11-13 18:50:27 <etotheipi_> gah... I would like to test it, but I could spend all day trying to figure that out
647 2011-11-13 18:52:56 <phantomcircuit> A node in the network has an incentive to keep
648 2011-11-13 18:52:57 <phantomcircuit> ahah
649 2011-11-13 18:53:05 <phantomcircuit> the entire premise of their paper is non sensical
650 2011-11-13 18:53:16 <phantomcircuit> that only applies to miners who comprise a tiny% of the network
651 2011-11-13 18:53:18 <phantomcircuit> idiots
652 2011-11-13 18:53:44 <etotheipi_> I haven't read it, but I suppose it's more relevant in the far future when the miners are the only really feasible nodes to be verifying the blocks/txs
653 2011-11-13 18:54:03 <etotheipi_> lightweight nodes aren't supposed to forward txs unless they can verify they are valid
654 2011-11-13 18:54:16 <cjdelisle> phantomcircuit: thankyou for the synopsys, I started on page 1 and it looked interestingish, now I don't need to read it :)
655 2011-11-13 18:54:20 <roconnor> phantomcircuit: seems fine to me; why should miners broadcast transactions?
656 2011-11-13 18:54:21 <etotheipi_> so the only nodes that would be forwarding (in a future with a multi-terabyte blockchain) is the miners
657 2011-11-13 18:54:38 <phantomcircuit> roconnor, they shouldn't, but who gives a shit they're a tiny % of the network
658 2011-11-13 18:55:10 <phantomcircuit> etotheipi_, wrong you'd still have the lightweight client connected to multiple nodes, so at the very least you would be connected to multiple miner
659 2011-11-13 18:55:36 <etotheipi_> phantomcircuit, I don't know what you mean by multiple miner
660 2011-11-13 18:55:36 <phantomcircuit> the entire basis of their criticism is false
661 2011-11-13 18:55:42 <phantomcircuit> miners
662 2011-11-13 18:55:58 <etotheipi_> oh, sorry, misread that
663 2011-11-13 18:56:48 <etotheipi_> arguably, you are correct... in such a future, if you broadcast a tx, you'll explicitly connect to a bunch of miners and make sure they each get it
664 2011-11-13 18:57:04 <etotheipi_> so.... yeah, I agree with you
665 2011-11-13 18:57:09 <phantomcircuit> a 17 page paper that boils down to "lol we dumb"
666 2011-11-13 18:57:35 <firesign> msr correct when txn fee strong
667 2011-11-13 18:58:14 <phantomcircuit> firesign, wat
668 2011-11-13 18:58:46 <etotheipi_> on the topic of huge blockchains, I'm trying to thresh out an idea (most likely debated thousands of times)
669 2011-11-13 18:58:48 <phantomcircuit> this paper shows a fundamental failure to comprehend the basic economics of the situation
670 2011-11-13 18:59:03 <phantomcircuit> it is in the best interest of the initial sender to forward the transaction to as many peers as possible
671 2011-11-13 18:59:04 <etotheipi_> but basically allowing, even miners to forget early blockchain
672 2011-11-13 18:59:12 <phantomcircuit> the cost of doing so is effectively zero
673 2011-11-13 18:59:31 <firesign> no, txn forwarding expensive when scale up
674 2011-11-13 18:59:38 <phantomcircuit> mining is so close to being a perfect market that the expected profits from running a mining operation are also zero
675 2011-11-13 19:00:04 <phantomcircuit> firesign, no actually it isn't
676 2011-11-13 19:00:46 <phantomcircuit> firesign, since i can connect to say 100 peers and send them all the transaction i can practically guarantee that miners wont be able to keep my transaction to themselves
677 2011-11-13 19:01:05 <phantomcircuit> their solution is some crazy ass scheme to incentivize forwarding transactions
678 2011-11-13 19:01:21 <phantomcircuit> when the real solution it simply to have the first peer that's sending connect to more nodes temporarily
679 2011-11-13 19:01:40 <phantomcircuit> truly a stunning failure to understand the situtation
680 2011-11-13 19:11:40 <roconnor> copumpkin: did you write elliptic curve bindings for haskell?
681 2011-11-13 19:11:51 <copumpkin> nope, bindings to what?
682 2011-11-13 19:12:07 <roconnor> presumably to openssl
683 2011-11-13 19:12:10 <copumpkin> nah
684 2011-11-13 19:12:17 <copumpkin> I thought you'd already written your own EC code in pure haskell
685 2011-11-13 19:12:21 <etotheipi_> roconnor, if you were a real man, you'd implement it yourself
686 2011-11-13 19:12:23 <roconnor> I did
687 2011-11-13 19:12:27 <copumpkin> etotheipi_: ^
688 2011-11-13 19:12:41 <copumpkin> never question the manliness of roconnor
689 2011-11-13 19:12:57 <etotheipi_> I was tempted to, in python... since they have arbitrary length integers
690 2011-11-13 19:13:03 <etotheipi_> but someone else did it already (Lis)
691 2011-11-13 19:13:12 <etotheipi_> I thought it would be fun
692 2011-11-13 19:13:18 <roconnor> it was fun :D
693 2011-11-13 19:13:23 <etotheipi_> but surely I don't actually have the time for it
694 2011-11-13 19:13:40 <roconnor> well, FWIW, it is much easier than the rest of bitcoin
695 2011-11-13 19:14:04 <copumpkin> roconnor: how general are your elliptic curves?
696 2011-11-13 19:14:08 <etotheipi_> yeah, well once you get EC-Point addition, I guess the rest isn't that bad
697 2011-11-13 19:14:22 <roconnor> copumpkin: it is somewhat optimized for this specific curve
698 2011-11-13 19:14:26 <copumpkin> ah
699 2011-11-13 19:14:45 <copumpkin> so it's not abstracted over a field
700 2011-11-13 19:15:00 <roconnor> copumpkin: one of the curve pameters, a, is 0
701 2011-11-13 19:15:18 <roconnor> which means you can remove some arithmetic
702 2011-11-13 19:15:29 <copumpkin> I see
703 2011-11-13 19:16:24 <firesign> sb goto -10
704 2011-11-13 19:16:28 <etotheipi_> roconnor, obviously you're a big fan of Haskell... I got into it briefly a couple years ago, but my impression was that the compilers aren't actually good at optimizing it (i.e. multithreading)
705 2011-11-13 19:16:49 <copumpkin> etotheipi_: quite the opposite :P although the situation has improved significantly over the past couple of years
706 2011-11-13 19:16:50 <etotheipi_> sure, there's a lot of other advantages of functional languages
707 2011-11-13 19:17:18 <etotheipi_> but one of my issues was that "optimal" haskell seemed to still be slower than C++, and not multithreaded to the extent I expected
708 2011-11-13 19:17:27 <copumpkin> oh, sure it is
709 2011-11-13 19:17:49 <copumpkin> but it's not that much slower than C++ :) and tends to be a hell of a lot safer (and friendlier, once you're used to it)
710 2011-11-13 19:18:14 <etotheipi_> I'm not disagreeing... I really do believe in the value of functional languages (I'm a mathematician... it's tough not to like it)
711 2011-11-13 19:18:21 <firesign> phantomcircuit: no incentive others relay txn. presume majority perfectly trusty, no verify
712 2011-11-13 19:19:00 <copumpkin> consider that good GHC-compiled code approaches around 2-3x of good C code, and GHC performs almost no low-level optimizations
713 2011-11-13 19:19:07 <etotheipi_> but when you take away the fact that it wasn't even close to C++ in terms of speed, I couldn't convince myself to dive in too deep
714 2011-11-13 19:19:14 <phantomcircuit> firesign, your english isn't good enough for me to understand you
715 2011-11-13 19:19:16 <copumpkin> things will change faster now that we have our nice LLVM back-end
716 2011-11-13 19:19:36 <etotheipi_> well maybe I'll give it another shot... someday
717 2011-11-13 19:19:51 <copumpkin> I recommend it :)
718 2011-11-13 19:19:58 <copumpkin> besides, there's more to programming than speed
719 2011-11-13 19:20:06 <firesign> phantomcircuit: you send txn to 100. why 100 relay txn?
720 2011-11-13 19:20:29 <phantomcircuit> again
721 2011-11-13 19:20:31 <copumpkin> although I do think speed is important :)
722 2011-11-13 19:20:33 <etotheipi_> copumpkin, I'm not disagreeing... but my application at the time was pretty speed-critical
723 2011-11-13 19:20:35 <copumpkin> yeah
724 2011-11-13 19:20:57 <copumpkin> never looked back :)
725 2011-11-13 19:20:59 <etotheipi_> I got sucked into CUDA
726 2011-11-13 19:21:01 <roconnor> etotheipi_: my main purpose is to understand the bitcoin protocol; my secondary purpose it to make a semi-formal functional specification of the bitcoin protocol.
727 2011-11-13 19:21:22 <etotheipi_> my workplace ended up putting high-power NVIDIA GPUs in all the computers
728 2011-11-13 19:21:34 <etotheipi_> so for "speed", CUDA programming was a much better choice than haskell
729 2011-11-13 19:21:42 <etotheipi_> 100x speedup in some situations
730 2011-11-13 19:22:49 <copumpkin> not mutually exclusive anymore :D
731 2011-11-13 19:23:02 <copumpkin> we have a couple of libraries for doing CUDA in haskell now, but I'm not sure how good they are :)
732 2011-11-13 19:23:12 <etotheipi_> copumpkin, it is mutually exclusive when you only have time to learn one
733 2011-11-13 19:23:16 <copumpkin> yep
734 2011-11-13 19:23:17 <etotheipi_> both were completely foreign to me
735 2011-11-13 19:25:06 <copumpkin> yeah
736 2011-11-13 19:25:08 <copumpkin> what kind of math?
737 2011-11-13 19:25:16 <copumpkin> (did you study)
738 2011-11-13 19:25:20 <etotheipi_> we're doing a lot of image processing
739 2011-11-13 19:25:51 <etotheipi_> oh... just "applied" math... mainly focused on stochastic processes
740 2011-11-13 19:26:01 <etotheipi_> but took quite a bit of crypto, too
741 2011-11-13 19:26:08 <copumpkin> ah, cool
742 2011-11-13 19:27:45 <etotheipi_> I think it was a good choice... but of course my brain is wired for it
743 2011-11-13 19:28:02 <etotheipi_> as such Bitcoin development is a lot of fun
744 2011-11-13 19:41:14 <cjdelisle> Is the coinbase placed in the location for the sigscript in the coinbase transaction?
745 2011-11-13 19:41:34 <cjdelisle> I've been looking through the specs and I figured it would be easier to just ask
746 2011-11-13 19:41:51 <etotheipi_> cjdelisle, this is why I made these pics:  https://bitcointalk.org/index.php?topic=29416.0
747 2011-11-13 19:42:10 <etotheipi_> there's 3 standard types of TxIns, and two types of TxOuts... they're all shown there
748 2011-11-13 19:42:24 <extor> etotheipi_, what does your work use CUDA for?
749 2011-11-13 19:42:27 <cjdelisle> ok thanks
750 2011-11-13 19:42:43 <copumpkin> so have people thought about the issue raised in that MSR paper?
751 2011-11-13 19:42:59 <copumpkin> the incentives to nodes to relay transactions
752 2011-11-13 19:43:01 <etotheipi_> cjdelisle, the coinbase TxIns have arbitrary scripts... you can put anything there... and they're frequently used as an extra nonce field
753 2011-11-13 19:43:10 <etotheipi_> extor, we do image processing at my work
754 2011-11-13 19:43:19 <etotheipi_> so CUDA is an excellent tool for it
755 2011-11-13 19:43:32 <extor> etotheipi_, you're a captcha farm? *snicker*
756 2011-11-13 19:43:39 <etotheipi_> extor, haha.... not quite
757 2011-11-13 19:43:52 <cjdelisle> I'm looking for the where they place the merged mining stuff
758 2011-11-13 19:44:15 <etotheipi_> but we regularly need to perform 9x9 convolutions over 1024x1024 images.... that's dirt slow on a CPU
759 2011-11-13 19:44:15 <extor> I'm thinking of making a captcha farm but not quite sure how feasable it is
760 2011-11-13 19:44:34 <graingert> extor: amazon mech turch
761 2011-11-13 19:44:40 <extor> convolutions as in re-rendering the pic to a thumbnail?
762 2011-11-13 19:44:46 <copumpkin> etotheipi_: at what point do convolutions become faster using the convolution theorem?
763 2011-11-13 19:44:52 <copumpkin> I've wondered this before
764 2011-11-13 19:44:56 <etotheipi_> well, I don't remember where I left it, but I my https://github.com/etotheipi/CUDA-Image-Processing library worked really well
765 2011-11-13 19:45:07 <etotheipi_> copumpkin, you mean using FFTs?
766 2011-11-13 19:45:08 <copumpkin> I guess when your mask is fairly large
767 2011-11-13 19:45:09 <copumpkin> yeah
768 2011-11-13 19:45:14 <extor> graingert, oh that's a good idea but there's still some visual captchas that can be solved by OCR and the right algos
769 2011-11-13 19:45:31 <etotheipi_> copumpkin, your kernel size needs to be on the order of the size of the image
770 2011-11-13 19:45:35 <copumpkin> yeah
771 2011-11-13 19:45:45 <etotheipi_> well wait... I shouldn't say "on the order"
772 2011-11-13 19:46:02 <etotheipi_> regular convolution gets extraordinarily slow with increasing PSF size
773 2011-11-13 19:46:11 <etotheipi_> (PSF here, because we're simulating blur)
774 2011-11-13 19:46:17 <copumpkin> ah
775 2011-11-13 19:46:30 <skitixch> Hey, would someone knowledgable about websockets mind taking a look at this and see if they can figure out what's going wrong? https://gist.github.com/1215530
776 2011-11-13 19:46:52 <etotheipi_> I was able to fit everything nicely into shared memory in the CUDA blocks up to 25x25 PSFs... beyond that, I would probably switch to FFT-based
777 2011-11-13 19:50:26 <extor> are the built in vidya cards on AMD Phenom mobos usually CUDA compliant? I should check the chipsets just in case I've got a mining situation at hand
778 2011-11-13 19:50:44 <etotheipi_> I seriously doubt it
779 2011-11-13 19:51:13 <etotheipi_> I'm spoiled, though... at work there's no question about money or savings... just get GTX 580s for all the computers
780 2011-11-13 19:51:18 <etotheipi_> two of 'em, if they fit
781 2011-11-13 19:52:57 <etotheipi_> extor, actually I misread your message
782 2011-11-13 19:53:17 <etotheipi_> AMD bought ATI and uses ATI chipsets on all their stuff
783 2011-11-13 19:53:28 <etotheipi_> CUDA is proprietary *NVIDIA*
784 2011-11-13 19:53:30 <extor> $600 each wow. I saw a chart a couple days ago that showed how many dollars and watts each GPU cost and how many hased/min it could do
785 2011-11-13 19:53:52 <etotheipi_> you have to use OpenCL if you want to do GPU proc on ATI chips
786 2011-11-13 19:54:31 <etotheipi_> the new AMD Llano CPUs *do* have quite a few cores in them, and you can use OpenCL on them
787 2011-11-13 19:54:39 <extor> yeah still would be nice to divert some of the GPU power of my 10 frankenservers to mining if possible. Right now they're just sitting half empty holding a few VPS
788 2011-11-13 19:55:02 <extor> LLano CPUs are the bulldozers?
789 2011-11-13 19:55:08 <etotheipi_> extor, no
790 2011-11-13 19:55:44 <etotheipi_> Llano is aimed more at midrange consumers who wouldn't mind having a decent GPU for light gaming, but not enough to purchase a dedicated GPU
791 2011-11-13 19:55:58 <extor> Ahh the FX ones perhaps
792 2011-11-13 19:56:30 <etotheipi_> bulldozer chips don't have the GPU cores... they're meant to be just powerful CPUs
793 2011-11-13 19:56:31 <extor> I wonder if these could be made to do double duty without too much of an increase in wattage consumptuon
794 2011-11-13 19:57:25 <extor> babby says: yes!
795 2011-11-13 19:58:09 <Mqrius> I've figured out a way for someone to securely generate a vanity address for someone else. (It's not that hard, really: http://bitcointalk.org/index.php?topic=25804.msg615923#msg615923 ) I was wondering though, if this could be expanded to securely generating vanity addresses for lots of people at the same time.
796 2011-11-13 19:58:11 <Mqrius> The problems involved seem to resemble multi-party signatures, albeit somewhat different. Maybe someone more knowledgeable in that field has an idea on how to implement it? (justmoon?)
797 2011-11-13 20:00:02 <etotheipi_> Mqrius, looks like a fun problem I'd like to dig into, but I'm way too distracted at the moment
798 2011-11-13 20:00:51 <gmaxwell> Mqrius: I posted the same scheme previously. :)
799 2011-11-13 20:00:57 <Mqrius> :) Are there any good papers on EC multi-key signing with threshold yet? I could see if I could understand it.
800 2011-11-13 20:01:20 <gmaxwell> Mqrius: thought I only came up with it because bytecoin said it was possible.
801 2011-11-13 20:01:35 <Mqrius> gmaxwell: Heh, didn't see it. It's nearly trivial for just 2 people though :P
802 2011-11-13 20:02:12 <CIA-89> bips: genjix master * r3ef3138 / bip-0014.md :
803 2011-11-13 20:02:13 <CIA-89> bips: BIP: 14
804 2011-11-13 20:03:00 <Mqrius> with a few more people, you could still ask for everyone's private key except for the person whose vanity address was found, but that would be troublesome, since all users need to be communicated with.
805 2011-11-13 20:03:07 <gmaxwell> Mqrius: to get multiparty speed up... sum several starting keys.. then increment.. if you find a solution you can give it to any of the starting key paries by telling them the sum of the rest and the increment.
806 2011-11-13 20:03:47 <Mqrius> gmaxwell: Yup. But ideally you would set up a site that wouldn't require contacting a user unless his address was found
807 2011-11-13 20:05:14 <gmaxwell> Mqrius: why would it? he wouldn't need to be contacted except at signup.
808 2011-11-13 20:05:51 <Mqrius> Well, you need the sum of the rest, so you need to contact all the rest to get the privkey they were using, and add that
809 2011-11-13 20:06:16 <Mqrius> Well, yeah, there's 2 distinct setups you could consider. 1 node searching for a lot of users (for a fee), or the distributed version where a lot of users search for a lot of users (probably fee-less).
810 2011-11-13 20:06:35 <gmaxwell> No you don't.
811 2011-11-13 20:06:56 <gmaxwell> oh darn, yes you do.
812 2011-11-13 20:07:00 <gmaxwell> Blonde moment.
813 2011-11-13 20:07:00 <Mqrius> Sure you do. :)
814 2011-11-13 20:07:47 <Mqrius> But yeah, the fully distributed search is easier, since all nodes are online searching anyway, but as soon as 1 node is offline, it doesn't work anymore.
815 2011-11-13 20:08:07 <gmaxwell> obvious way to solve this is by writing a daemon.
816 2011-11-13 20:08:14 <Mqrius> Myeah...
817 2011-11-13 20:09:18 <Mqrius> But I was wondering if there's a way to do this where just 2 private keys are enough. Like with threshold multikey signing, you would need just the "finder"'s privkey, who found the vanity address, and the person's privkey whose address was actually found
818 2011-11-13 20:09:25 <Mqrius> But I'm not sure if that's feasible.
819 2011-11-13 20:09:44 <Mqrius> It just reminded me of multikey signing :P
820 2011-11-13 20:09:54 <gmaxwell> no, It's not fesable, at least not without changing the type of keys and signing algo.
821 2011-11-13 20:11:28 <Mqrius> Hmm, I suppose I should look into multikey signing to find out why that /is/ possible, while this isn't :)
822 2011-11-13 20:18:03 <etotheipi_> roconnor, earlier, you asked about run time of scripts based on size:  I was wondering if you noticed the check in the main client that disallows scripts with more than one sigOP per 34 bytes...
823 2011-11-13 20:19:01 <etotheipi_> I don't know if that's part of the "spec" so to say... but it does consider tx's invalid if they don't meet that criteria