1 2011-09-25 00:00:09 <gmaxwell> casascius: ideally you'd just map the base36ish to base 58.
   2 2011-09-25 00:00:21 <casascius> as opposed to mapping base36 to base256?
   3 2011-09-25 00:00:30 <casascius> base36 -> base58 -> base256 instead?
   4 2011-09-25 00:00:34 <Diablo-D3> >base256
   5 2011-09-25 00:00:36 <Diablo-D3> I dont think so
   6 2011-09-25 00:00:44 <casascius> by base256 i just mean bytes
   7 2011-09-25 00:00:45 <Diablo-D3> no one is going to encode addresses with unicode.
   8 2011-09-25 00:01:12 <gmaxwell> well, I guess I don't care how its implemented... just so long as its possible to convert from one kind to another and work just as well. No need for more than one kind of minikey even if there are multiple representations.
   9 2011-09-25 00:01:20 <casascius> i don't mean unicode.... i am just saying...i would convert the base36 straight to its byte representation
  10 2011-09-25 00:01:45 <gmaxwell> e.g. don't do the validity checks differently on the base36 than you do on the base58.
  11 2011-09-25 00:01:52 <casascius> gmaxwell: that's what i have in mind
  12 2011-09-25 00:01:54 * sipa is wary for the moment people go create "vanity minikeys"
  13 2011-09-25 00:02:06 <casascius> minikeys are relatively expensive to make
  14 2011-09-25 00:02:23 <casascius> actually i take that back, since the ec is unnecessary if the check fails
  15 2011-09-25 00:02:34 ymirhotfoot has joined
  16 2011-09-25 00:02:36 <gmaxwell> sipa: the validity checking at least adds a little cost though thats another reason to have it be more than a single sha256 check....
  17 2011-09-25 00:02:37 <casascius> but if i go with requiring a minimum of 4096 pbkdf2 rounds for any valid minikey, then they will be
  18 2011-09-25 00:02:55 <sipa> 4096 rounds is still nothing
  19 2011-09-25 00:03:04 <Diablo-D3> I love how people say pbkdf2 is something, and how 4096 is a lot
  20 2011-09-25 00:03:07 <casascius> that's the minimum....do you recommend a higher one?
  21 2011-09-25 00:03:11 <Joric> sipa, +716 sha256 rounds for extra checking
  22 2011-09-25 00:03:29 <sipa> casascius: well, i'm not sure
  23 2011-09-25 00:03:37 <Diablo-D3> secure starts at 100k pbkdf2, sha512, with a 384 bit salt.
  24 2011-09-25 00:03:42 <gmaxwell> casascius: my random desktop does on the order of ~1M SHA256/s/core with not especially optimized code.
  25 2011-09-25 00:03:53 <casascius> pbkdf2 is an effective way to waste a hacker's computational resources by orders of magnitude, so that counts as "something" from a practical security perspective
  26 2011-09-25 00:03:57 <gmaxwell> so yea, 4096 isn't much but I'm sensitive to the needs of embedded devices.
  27 2011-09-25 00:04:11 <Diablo-D3> casascius: no, its a WAY of hashing, it doesnt define the actual cipher.
  28 2011-09-25 00:04:22 <gmaxwell> Diablo-D3: he has elsewhere
  29 2011-09-25 00:04:26 <sipa> casascius: as long as the minikey is completely randomly generated, there is no problem really
  30 2011-09-25 00:05:09 <[Tycho]> May be the correct way is embedding RFID chips in coins somehow :)
  31 2011-09-25 00:05:18 Nesetalis has joined
  32 2011-09-25 00:05:21 <sipa> given the success of vanity keys, maybe people will want vanity minikeys as well, which would just kill the entropy
  33 2011-09-25 00:05:27 <Diablo-D3> rfid chips are too easily damaged
  34 2011-09-25 00:05:29 <casascius> diablo-d3: my pbkdf2 proposal involves a key that self-selects the number of rounds - in my present tree, between 1 and 1048576 rounds, but as just discussed, intended to be between 4096 and 256 million rounds
  35 2011-09-25 00:05:42 <Diablo-D3> casascius: 4096 is too low of a bound
  36 2011-09-25 00:06:00 <Diablo-D3> needs to be at least 10k.
  37 2011-09-25 00:06:01 <casascius> diablo-d3: name the right number and i'll do it.... i don't have my heart set on that number
  38 2011-09-25 00:06:09 rdponticelli has joined
  39 2011-09-25 00:06:14 <[Tycho]> Diablo-D3, have you ever used one ?
  40 2011-09-25 00:06:19 <Diablo-D3> [Tycho]: used what?
  41 2011-09-25 00:06:26 <[Tycho]> RFID
  42 2011-09-25 00:06:32 <gmaxwell> casascius: well, what devices do you need to support? I avoided whining about 4096 because I'm trying to be sensitive to the needs of embedded devices.
  43 2011-09-25 00:06:33 <Joric> frankly i didnt think about it but does vanitygen actually use gpu accelerated ecdsa? theres a lot of operations - ecdsa + sha256 + ripemd160 + base58
  44 2011-09-25 00:06:36 <Diablo-D3> um, every time I go to the store?
  45 2011-09-25 00:06:41 <Diablo-D3> rfid tags are in EVERYTHING
  46 2011-09-25 00:06:43 <gmaxwell> Joric: yes
  47 2011-09-25 00:06:47 <[Tycho]> And how they are damaged ?
  48 2011-09-25 00:07:02 <Diablo-D3> [Tycho]: heat can very easily damage them
  49 2011-09-25 00:07:09 <Diablo-D3> and microwaves will melt them
  50 2011-09-25 00:07:23 <gmaxwell> casascius: in terms of anti-vanitygen what is important is the operations prior to the 7-bits-of-zeros check.
  51 2011-09-25 00:07:26 <[Tycho]> Why should anyone microwave coins ?
  52 2011-09-25 00:07:39 <Diablo-D3> [Tycho]: TSA mark 2.0.
  53 2011-09-25 00:07:42 <casascius> gmaxwell: well two ways i can go.  One would be to lower the bound.  The other would be to provide a way to produce a crappy (e.g. 1 round) key that is more difficult so someone has to go out of their way to want to do it.
  54 2011-09-25 00:08:00 <casascius> 4096 is very possibly too many for some of this equipment
  55 2011-09-25 00:08:03 <[Tycho]> They are not damaged in normal usage.
  56 2011-09-25 00:08:42 <casascius> but i will think about it for a bit.  I've gotta run for the time being
  57 2011-09-25 00:08:52 <gmaxwell> casascius: I don't follow what you're saying about 'difficult'. I'll think on it too.
  58 2011-09-25 00:09:11 <gmaxwell> But if you provide an easy out, people will just use that for vanityminikeys.
  59 2011-09-25 00:09:29 <gmaxwell> So I'd much rather have the minimum 4096 everywhere, even though I agree with the general notion that 4096 is not enough.
  60 2011-09-25 00:09:35 <casascius> maybe the typo check needs to be very expensive
  61 2011-09-25 00:09:40 <casascius> and sha256 isn't the answer
  62 2011-09-25 00:10:47 <gmaxwell> If you're worried about generating on weak devices then the typocheck needs to be fairly cheap, as they'll have to do it 128 times often.
  63 2011-09-25 00:10:49 <sipa> have a key Sxxxxxxxxyyyyyyyyyyyyy, where xxxxxxxx is part of the address :)
  64 2011-09-25 00:10:51 <luke-jr> ;;bc,stats
  65 2011-09-25 00:10:55 <gribble> Current Blocks: 146767 | Current Difficulty: 1755425.3203287 | Next Difficulty At Block: 147167 | Next Difficulty In: 400 blocks | Next Difficulty In About: 2 days, 20 hours, 26 minutes, and 40 seconds | Next Difficulty Estimate: 1698494.36622459 | Estimated Percent Change: -3.2431430403
  66 2011-09-25 00:11:33 <sipa> and you need to do iterated hashing on the yyyy, until some condition is met, then generate pubkey from it, hash it, and compare with xxxxxxx
  67 2011-09-25 00:11:38 <sipa> if not, continue :p
  68 2011-09-25 00:11:54 <b4epoche_> any thoughts on stripping SendMoneyToBitcoinAddress and SendMoney out of wallet.cpp?
  69 2011-09-25 00:12:03 EPiSKiNG- has quit ()
  70 2011-09-25 00:12:04 <b4epoche_> and sticking in UI/RPC code?
  71 2011-09-25 00:12:07 <gmaxwell> sipa: thats cute but you lose entropy fast that way. :)
  72 2011-09-25 00:12:19 <sipa> b4epoche_: why?
  73 2011-09-25 00:12:32 <b4epoche_> it's calling UI code
  74 2011-09-25 00:12:54 <b4epoche_> ThreadSafeAskFee
  75 2011-09-25 00:13:13 <sipa> we need hooks for that kind of thing
  76 2011-09-25 00:13:16 <luke-jr> ^
  77 2011-09-25 00:13:25 <sipa> but it SendMoney definitely doesn't belong inside GUI code
  78 2011-09-25 00:13:26 <luke-jr> or rather, two calls
  79 2011-09-25 00:13:33 <sipa> luke-jr: indeed
  80 2011-09-25 00:13:48 <luke-jr> should be CreateSuchTxn(), ThreadSafeAskFee(), ApproveTxn()
  81 2011-09-25 00:13:59 theorb has joined
  82 2011-09-25 00:14:00 <sipa> i agree
  83 2011-09-25 00:14:01 <luke-jr> I imagine the latter could be reused for both
  84 2011-09-25 00:14:25 theorbtwo has quit (Ping timeout: 248 seconds)
  85 2011-09-25 00:14:32 theorb is now known as theorbtwo
  86 2011-09-25 00:14:35 <b4epoche_> if you look at SendMoney, it's basically very much 'UI' code
  87 2011-09-25 00:15:15 <sipa> it's quite high-level already, yes
  88 2011-09-25 00:15:29 <sipa> but i think a lot of the UI and RPC is *way* too low-level already
  89 2011-09-25 00:15:36 <sipa> for one thing, it touches internal data structures
  90 2011-09-25 00:16:02 <b4epoche_> it does?
  91 2011-09-25 00:16:05 <b4epoche_> directly?
  92 2011-09-25 00:17:03 <sipa> yes
  93 2011-09-25 00:17:23 <b4epoche_> it calls CreateTransaction and CommitTransaction
  94 2011-09-25 00:17:24 therealnanotube is now known as nanotube
  95 2011-09-25 00:17:31 <b4epoche_> that's basically it
  96 2011-09-25 00:18:02 <sipa> true, those correspond to luke's proposed calls
  97 2011-09-25 00:18:09 <sipa> except there is locking in between
  98 2011-09-25 00:18:21 <sipa> creatr and commit now need to be done atomically
  99 2011-09-25 00:18:37 <b4epoche_> locking?  thread or wallet?
 100 2011-09-25 00:18:44 <sipa> coin-locking
 101 2011-09-25 00:19:08 <b4epoche_> coin-locking?
 102 2011-09-25 00:19:23 <luke-jr> btw, there might be an informal bitcoin meetup somewhere around Tampa
 103 2011-09-25 00:19:26 <luke-jr> anyone wanna go?
 104 2011-09-25 00:19:39 erus` has quit (Remote host closed the connection)
 105 2011-09-25 00:19:49 <sipa> b4epoche_: currently, create and commit are called back to back, in such a way that nothing can change internal structures in between
 106 2011-09-25 00:20:20 <b4epoche_> sipa:  and they could be called that way from UI code too, no?
 107 2011-09-25 00:21:04 <sipa> sure, but you'd need to have your UI code run inside code that holds a lock on those internal data structures
 108 2011-09-25 00:21:12 <sipa> to prevent anything from messing
 109 2011-09-25 00:21:36 <sipa> the solution is having a createtransaction that temporarily "locks" the input coins
 110 2011-09-25 00:21:56 <sipa> until you either commit (in which case they become spent), or abort
 111 2011-09-25 00:22:06 <sipa> well, there's other solutions as well
 112 2011-09-25 00:22:40 <sipa> but i was going to sleep
 113 2011-09-25 00:22:42 <sipa> cya all
 114 2011-09-25 00:22:47 <b4epoche_> I guess for the time being I'll hijack ThreadSafeAskFee
 115 2011-09-25 00:24:23 <jgarzik> Lolcust: not sure what you're referring to
 116 2011-09-25 00:26:19 devrandom has quit (Remote host closed the connection)
 117 2011-09-25 00:30:00 Kardos__ has joined
 118 2011-09-25 00:30:35 ymirhotfoot has quit (Remote host closed the connection)
 119 2011-09-25 00:30:50 EPiSKiNG- has joined
 120 2011-09-25 00:30:54 Kardos_ has quit (Read error: Operation timed out)
 121 2011-09-25 00:39:05 EPiSKiNG- has quit ()
 122 2011-09-25 00:45:39 surikator has joined
 123 2011-09-25 00:45:54 samthetechie has quit (Ping timeout: 245 seconds)
 124 2011-09-25 00:50:13 normanrichards has joined
 125 2011-09-25 00:51:15 karnac has joined
 126 2011-09-25 00:53:47 clr_ has joined
 127 2011-09-25 00:56:08 EPiSKiNG- has joined
 128 2011-09-25 00:59:20 soap_ is now known as soap
 129 2011-09-25 00:59:21 Joric has quit ()
 130 2011-09-25 01:01:41 samthetechie has joined
 131 2011-09-25 01:06:45 rdponticelli has quit (Read error: Connection reset by peer)
 132 2011-09-25 01:25:39 jgarzik has quit (Quit: Client exiting)
 133 2011-09-25 01:30:47 Turingi has quit (Read error: Connection reset by peer)
 134 2011-09-25 01:31:02 Turingi has joined
 135 2011-09-25 01:31:47 danbri has joined
 136 2011-09-25 01:34:20 c_k has quit (Read error: Operation timed out)
 137 2011-09-25 01:39:26 Lopuz has joined
 138 2011-09-25 01:45:08 <CIA-101> poolserverj: shadders * bd7054f3043f r118 /poolserverj-main/ (11 files in 7 dirs): - commit before branch change
 139 2011-09-25 01:45:09 <CIA-101> poolserverj: shadders * 62905e041fe3 r119 /bitcoin-jsonrpc/src/main/java/com/shadworld/jsonrpc/ (AbstractJsonRpcObject.java JsonRpcRequest.java):
 140 2011-09-25 01:45:09 <CIA-101> poolserverj: - add meaningful toString method for JsonRpc objects
 141 2011-09-25 01:45:09 <CIA-101> poolserverj: - commit pre branch change
 142 2011-09-25 01:45:10 <CIA-101> poolserverj: shadders * 492467e49e36 r120 /poolserverj-main/src/main/java/com/shadworld/poolserver/servlet/PoolServerJLongpollServlet.java:
 143 2011-09-25 01:45:10 <CIA-101> poolserverj: - fix: stop checking if continuation state is initial. It can be if a previous
 144 2011-09-25 01:45:10 <CIA-101> poolserverj: Jetty filter has suspended/resumed the request. In that case it immediately
 145 2011-09-25 01:45:10 <CIA-101> poolserverj: sends and empty LP response. This might be the cause of a bug where cgminer
 146 2011-09-25 01:45:10 <CIA-101> poolserverj: immediately sends another LP. This turns into a spam loop. This only seems to
 147 2011-09-25 01:45:11 <CIA-101> poolserverj: be triggered under heavy load and only seems to happen with cgminer clients
 148 2011-09-25 01:45:11 <CIA-101> poolserverj: connected.
 149 2011-09-25 01:45:12 <CIA-101> poolserverj: shadders * f32fe348fe5a r121 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (BlockChainTracker.java PoolServer.java conf/Conf.java):
 150 2011-09-25 01:46:02 <CIA-101> poolserverj: - add some extra log info about native long poll config
 151 2011-09-25 01:46:02 <CIA-101> poolserverj:  - change default native LP listener port to 8950
 152 2011-09-25 01:46:02 <CIA-101> poolserverj:  - added commented out condition to stop manual block checks if native LP enabled and verification off.
 153 2011-09-25 01:46:02 <CIA-101> poolserverj: shadders * b39036b3e75a r122 /poolserverj-main/src/main/java/com/shadworld/poolserver/BlockChainTracker.java: - remove warning for native LP when a manual block check is fired. We want this occur in most circumstances.
 154 2011-09-25 01:46:02 <CIA-101> poolserverj: shadders * fc23df5f3296 r123 /bitcoin-jsonrpc/src/main/java/com/shadworld/jsonrpc/AbstractJsonRpcObject.java: - add meaningful toString() output for jsonrpc objects
 155 2011-09-25 01:50:37 surikator has quit (Quit: Scientific discovery is just maximal compression of strings. Nothing more, nothing less.)
 156 2011-09-25 01:52:23 huk has joined
 157 2011-09-25 01:53:32 Raccoon` has joined
 158 2011-09-25 01:55:46 mindphlux has joined
 159 2011-09-25 01:56:08 Raccoon has quit (Ping timeout: 252 seconds)
 160 2011-09-25 01:56:09 Raccoon` is now known as Raccoon
 161 2011-09-25 01:56:10 <mindphlux> hi, are there enough miners on testnet to do actual transactions?
 162 2011-09-25 01:56:58 Titeuf_87 has quit (Quit: Ex-Chat)
 163 2011-09-25 01:58:57 <nanotube> mindphlux: they come and go.
 164 2011-09-25 01:59:27 <mindphlux> nanotube: okay, so it can take hours to confirm a transaction
 165 2011-09-25 02:00:25 <nanotube> yes
 166 2011-09-25 02:00:29 <mindphlux> thanks
 167 2011-09-25 02:05:21 danbri has quit (Remote host closed the connection)
 168 2011-09-25 02:06:12 jgarzik has joined
 169 2011-09-25 02:06:25 jgarzik has quit (Changing host)
 170 2011-09-25 02:06:25 jgarzik has joined
 171 2011-09-25 02:08:35 <phantomcircuit> mindphlux, it can take days
 172 2011-09-25 02:08:48 <mindphlux> phantomcircuit: ok, I'll skip and test with real bitcoins then
 173 2011-09-25 02:10:44 Turingi has quit (Read error: Connection reset by peer)
 174 2011-09-25 02:16:17 <nanotube> mindphlux: whatcha testing?
 175 2011-09-25 02:16:25 <mindphlux> nanotube: gambling game
 176 2011-09-25 02:16:49 <luke-jr> mindphlux: lrn2mine
 177 2011-09-25 02:16:54 <nanotube> ah heh ic. you could consider using the 'testnet in a box' setup with really low difficulty
 178 2011-09-25 02:17:06 <mindphlux> luke-jr: I'm mining with 14ghash so I know how to mine.
 179 2011-09-25 02:17:15 <luke-jr> mindphlux: so use it for testnet
 180 2011-09-25 02:17:24 <mindphlux> luke-jr: and wait 1 week until the block matures?
 181 2011-09-25 02:17:34 <luke-jr> mindphlux: why would it take that long?
 182 2011-09-25 02:17:47 <mindphlux> luke-jr: someone told me it takes ages to get a confirmed block.. so I decided not to bother
 183 2011-09-25 02:18:06 <luke-jr> if you don't mine onyl
 184 2011-09-25 02:18:07 <nanotube> mindphlux: well, if you're the one mining, you can confirm your own tx, you know
 185 2011-09-25 02:18:41 <nanotube> ;;bc,calcd 14000000 170
 186 2011-09-25 02:18:41 <gribble> The average time to generate a block at 14000000 Khps, given the supplied difficulty of 170, is 52 seconds
 187 2011-09-25 02:18:58 <nanotube> mindphlux: ^ you can generate a testnet block with 14ghps on average in 52 seconds
 188 2011-09-25 02:19:03 <mindphlux> I seei t
 189 2011-09-25 02:19:14 <mindphlux> Thanks
 190 2011-09-25 02:20:13 <luke-jr> (but please don't drive up the difficulty)
 191 2011-09-25 02:20:21 <mindphlux> that kind of implies it
 192 2011-09-25 02:20:26 <mindphlux> Wouldn't want to do that
 193 2011-09-25 02:20:34 <luke-jr> ;;bc,calcd 1000000 170
 194 2011-09-25 02:20:35 <gribble> The average time to generate a block at 1000000 Khps, given the supplied difficulty of 170, is 12 minutes and 10 seconds
 195 2011-09-25 02:20:41 <luke-jr> 1 GH is ok :P
 196 2011-09-25 02:21:01 <mindphlux> Using bitcoins is fine for me. Nothing to loose
 197 2011-09-25 02:34:55 c_k has joined
 198 2011-09-25 02:40:03 normanrichards has quit (Quit: normanrichards)
 199 2011-09-25 02:40:34 <CIA-101> poolserverj: shadders * 19f36b75b327 r124 / (2 files in 2 dirs): - extra trace targets for longpoll empty and expired responses.
 200 2011-09-25 02:44:24 <mindphlux> Is it wise to allow 0 confirmations ? Just not paying out any winnings when the transaction in question is having less than 6 confirmations - ie he can play with his money, but cannot pay out unless it confirms properly
 201 2011-09-25 02:45:37 <luke-jr> no
 202 2011-09-25 02:45:54 <luke-jr> mindphlux: so he'll play, and let it confirm properly if he wins
 203 2011-09-25 02:46:32 <mindphlux> luke-jr: gotcha.
 204 2011-09-25 02:46:37 <mindphlux> thanks. Didn't think of that
 205 2011-09-25 02:47:13 <mindphlux> But what good does it do with loosing with double spent money?
 206 2011-09-25 02:47:17 <mindphlux> If he can never get it back
 207 2011-09-25 02:47:18 <mindphlux> lol
 208 2011-09-25 02:48:16 <phantomcircuit> he can play the game until he wins never losing anything
 209 2011-09-25 02:48:41 <luke-jr> mindphlux: double-spending usually means the original sender is the guy who gets it ;)
 210 2011-09-25 02:48:44 <mindphlux> I wouldn't pay out any winnings because his deposit has been never confirmed
 211 2011-09-25 02:49:01 <luke-jr> mindphlux: so he'll make new accounts every time
 212 2011-09-25 02:49:20 <phantomcircuit> i dont think he gets it
 213 2011-09-25 02:49:28 <mindphlux> Just trying to understand
 214 2011-09-25 02:49:31 <mindphlux> Bear with me.
 215 2011-09-25 02:51:17 <mindphlux> I'll just leave it at at least 3 confirmations
 216 2011-09-25 02:53:53 wardearia has quit (Ping timeout: 248 seconds)
 217 2011-09-25 02:55:30 [7] has quit (Disconnected by services)
 218 2011-09-25 02:55:40 TheSeven has joined
 219 2011-09-25 02:57:56 Raccoon has quit (Changing host)
 220 2011-09-25 02:57:57 Raccoon has joined
 221 2011-09-25 02:58:46 dorje has quit (Quit: dorje)
 222 2011-09-25 03:02:47 LightRider has quit (Read error: Connection reset by peer)
 223 2011-09-25 03:03:09 LightRider has joined
 224 2011-09-25 03:03:25 normanrichards has joined
 225 2011-09-25 03:10:20 wardearia has joined
 226 2011-09-25 03:10:35 LightRider has quit (Remote host closed the connection)
 227 2011-09-25 03:10:35 ThomasV has joined
 228 2011-09-25 03:12:34 Lopuz has quit (Ping timeout: 276 seconds)
 229 2011-09-25 03:14:15 t3a has quit (Ping timeout: 245 seconds)
 230 2011-09-25 03:16:50 Cusipzzz has quit (Ping timeout: 248 seconds)
 231 2011-09-25 03:19:00 huk has quit (Read error: Connection reset by peer)
 232 2011-09-25 03:27:14 <casascius> just got here and read regarding letting someone gamble with 0 confirmations.  it sounds like a novel idea.  if he loses, you most likely still got his money.  but more importantly, if you can wrap HIS tx into the payment of his winnings, then if he were to successfully doublespend, he would void the entire transaction paying him out
 233 2011-09-25 03:28:07 <mindphlux> casascius: I decided against it, until I let someone explain it to me in full detail
 234 2011-09-25 03:28:16 <soap> you say "if" - is this a hard problem (to wrap his tx in to the payment of his winnings)?
 235 2011-09-25 03:28:40 <casascius> in the current client it is... but not with the magic rpc calls i frequently ask for =)
 236 2011-09-25 03:28:43 <soap> won't using a separate wallet per player solve this?  Or is that needless?
 237 2011-09-25 03:28:47 TD[gone] is now known as TD
 238 2011-09-25 03:29:19 <casascius> if the client offered a "query all transactions benefiting these addresses", then when you go to pay out...
 239 2011-09-25 03:29:32 <soap> (or #2) am I missing something fundamental?
 240 2011-09-25 03:29:39 <casascius> you simply run the query to find the transaction for his recent unconfirmed payment.
 241 2011-09-25 03:30:06 <casascius> then in your own code, build a transaction that incorporates his txid along with your own money to total his winnings...
 242 2011-09-25 03:30:15 Cusipzzz has joined
 243 2011-09-25 03:30:18 Cusipzzz has quit (Client Quit)
 244 2011-09-25 03:30:18 <casascius> and then use my imaginary rpc call to send the transaction back to the p2p network
 245 2011-09-25 03:30:36 <casascius> "query all transactions benefiting these addresses" requires my pet index
 246 2011-09-25 03:31:14 <mindphlux> I agree it was a novel idea
 247 2011-09-25 03:31:17 <mindphlux> Had this earlier today
 248 2011-09-25 03:31:20 <casascius> so you would do this scheme instead of just "Sendtoaddress" which would virtually guarantee his winnings got paid out of YOUR money and that you'd be stuck with any doublespend
 249 2011-09-25 03:31:22 <mindphlux> but it turns out I'm playing with fire
 250 2011-09-25 03:31:43 <gmaxwell> casascius: you can always just delay payout when someone wins.
 251 2011-09-25 03:32:42 <gmaxwell> Ideally you want to keep a temporary balance internally— making the result of every gamble visible to the blockchain is an unreasonable load on the globally visible bitcoin network— and also doesn't do well for increasing the users privacy.
 252 2011-09-25 03:33:08 newsbad_com has quit (Ping timeout: 260 seconds)
 253 2011-09-25 03:33:19 <casascius> gmaxwell: agree, and probably gets expensive with transaction fees too
 254 2011-09-25 03:34:01 <gmaxwell> Espeically since that model mandates you are constantly short-roundtripping funds, which makes the txn objectively look like a dos attack.
 255 2011-09-25 03:34:32 <casascius> one can delay payout, but if one can wrap the original inputs of a "winner" into an output transaction, he can virtually guarantee immunity to all attacks of the "double-spend to rob the casino" nature regardless of the block height
 256 2011-09-25 03:35:30 <gmaxwell> Yes, you can, and thats a neat optimization regardless of how you groom or delay payouts. Still, it's terrible for privacy.
 257 2011-09-25 03:36:00 <gmaxwell> (and face it, a major use of casinos is to make flows of funds more confusing to trace)
 258 2011-09-25 03:36:05 Kolky has quit (Quit: Bye bye!)
 259 2011-09-25 03:37:04 TransistOrg has quit (Remote host closed the connection)
 260 2011-09-25 03:37:18 TransistOrg has joined
 261 2011-09-25 03:38:06 <casascius> I am thinking re: the mini private key thing - that it would probably be best not to officially support any kind of sha256 mini private keys in the client (which, yes, would eliminate my casascius coins from being redeemable directly in the client)
 262 2011-09-25 03:38:22 <casascius> Which might sound surprising coming from me
 263 2011-09-25 03:38:59 newsbad_com has joined
 264 2011-09-25 03:39:00 <gmaxwell> I was warming up pretty well to the idea once you indicated a willingness to stick to >128 bits of entropy.
 265 2011-09-25 03:39:02 <casascius> And also, for a mini private key that IS supported, completely eliminating the typo check.  (the typo check would become: if the address doesn't have bitcoins, the typo check failed.)
 266 2011-09-25 03:39:32 <casascius> So, anyway, here is WHY.
 267 2011-09-25 03:39:46 <casascius> I do think SHA256-based codes will exist.
 268 2011-09-25 03:39:55 <casascius> Because hopefully they will be trivial to redeem with a web redeemer.
 269 2011-09-25 03:40:04 <casascius> But official support in the client says something else.
 270 2011-09-25 03:40:32 <casascius> If the only minikey supported by the client were a strong one that had > 128 bits, it would successfully DISCOURAGE people from doing sha256 keys.
 271 2011-09-25 03:40:59 <casascius> Websites (mtgox, marketplace, etc.) could still accept sha256 keys if they wanted to - simply by doing the calculation in their website before passing it on to bitcoind.
 272 2011-09-25 03:41:14 <casascius> But if the strongest form of minikey were the one de-facto in the client, it would STRONGLY encourage people to use it.
 273 2011-09-25 03:41:23 <gmaxwell> Well, web-redeemer basically says that it's okay to deal with private key material with a webpage. Thats a bad message to send.
 274 2011-09-25 03:41:25 <casascius> On the other hand, I can see the problem with STRONGLY encouraging people to use sha256 codes.
 275 2011-09-25 03:41:36 <gmaxwell> casascius: you're making an argument for including it.
 276 2011-09-25 03:42:06 <casascius> Web-redeemer will be OK for my limited run of a few thousand BTC, only a few of which will be torn open.  Guarantee the next run will use the stronger algorithm.
 277 2011-09-25 03:42:25 <gmaxwell> If you're going to web-redeem then there is no reason to put a privatekey on the coin at all.
 278 2011-09-25 03:42:53 <gmaxwell> Just have a page that makes a payment to the users choice of address when they redeem an ID written on the coin.
 279 2011-09-25 03:43:03 <casascius> Other than if it's not the private key, they don't really have a bitcoin, all they have is a promise from me and that's not the same.  What if I disappear?
 280 2011-09-25 03:43:26 <gmaxwell> That situation already exists, because as far as anyone can tell you've kept the private keys.
 281 2011-09-25 03:43:41 <gmaxwell> If you get hacked or decide to disappear you might just take all of them with you.
 282 2011-09-25 03:44:06 <gmaxwell> Even if you haven't kept them, the webpage you provide could simply start stealing them when people use it.
 283 2011-09-25 03:44:06 <casascius> It does exist, but there is a decent difference between me actively stealing them (something that incurs a real life liability for me), versus me disappearing and making bagholders out of my customers
 284 2011-09-25 03:44:23 <gmaxwell> It can do that even if its been audited, because its a webpage and you can change it at any time.
 285 2011-09-25 03:44:42 <gmaxwell> You're correct, I'm just pointing out that the difference isn't as great as it might seem on first blush.
 286 2011-09-25 03:45:10 <casascius> It may not be a terrible idea to put in the client IF it can be discouraged...
 287 2011-09-25 03:45:28 <casascius> For example, if the client were to accept 22-char SHA256's as keys...
 288 2011-09-25 03:45:51 <casascius> then it may be worthwhile to simply drop the requirement for the leading 'S' and the 7 bit check, and simply say that it's any 22 characters and the check is, "if it has btc, it's valid"
 289 2011-09-25 03:45:56 <casascius> That would put it >128 bytes
 290 2011-09-25 03:45:58 <casascius> *bits
 291 2011-09-25 03:46:09 huk has joined
 292 2011-09-25 03:46:36 <casascius> that's 128 bits not encumbered by a crc scheme
 293 2011-09-25 03:47:01 <gmaxwell> But then people would use "Thisisabitcoin000000.000" which is pretty terrible.
 294 2011-09-25 03:47:14 <casascius> gmaxwell: 100% agreed...which sort of led me to say, forget SHA256.
 295 2011-09-25 03:47:24 <gmaxwell> (especially if there isn't an obnoxious amount of strenghtening)
 296 2011-09-25 03:47:55 <casascius> (of course, someone could also do "thisisabitcoin00000000q" even with the strongest derivation algorithm, nothing specific to sha256)
 297 2011-09-25 03:48:09 <casascius> i put the "q" to suggest that they probably need only set 1 character to make the crc pass
 298 2011-09-25 03:48:56 <gmaxwell> Yes, strong derivation just makes it harder to run a dictionary through it to look for addresses with coins. At least with the CRC they'd have to try (and remember a character that they didn't choose)
 299 2011-09-25 03:49:10 <gmaxwell> 'CRC' (of course)
 300 2011-09-25 03:50:05 <casascius> Hopefully no one will bother trying to generate "vanity" private keys.  They are not quite as useful as vanity addresses, because no one but their owner sees them...
 301 2011-09-25 03:50:37 <casascius> I couldn't see someone going out of their way to download a utility explicitly designed to help them make a weak password when they could just as well use a deterministic wallet with , say, a 30 character passphrase
 302 2011-09-25 03:50:38 <gmaxwell> Vanity is a bit less of an issue than "totally user memorized text".
 303 2011-09-25 03:51:16 <casascius> just curious, do you see the client as having any sort of future with respect to deterministically generated wallets?
 304 2011-09-25 03:52:08 <gmaxwell> Not purely passphrase based ones. But sure, I'd like to see it using that in the future. There are some counterarguments, but I feel they're outweighed by the benefits.
 305 2011-09-25 03:52:14 <casascius> I used a deterministic wallet to generate the addresses I'm using on my casascius bitcoin website.  I have the comfort of knowing that there's very little possibility that my bitcoins could get stolen because I know the passphrase
 306 2011-09-25 03:52:22 <casascius> *or lost too
 307 2011-09-25 03:52:26 Andrevan has joined
 308 2011-09-25 03:52:26 Andrevan has quit (Changing host)
 309 2011-09-25 03:52:26 Andrevan has joined
 310 2011-09-25 03:52:29 <casascius> and there are no private keys on the server
 311 2011-09-25 03:53:07 <gmaxwell> Thats false comfort. Your passphrases will almost certantly have terrible entropy, even if you used good practices (and the commonly advised practices aren't actually all that good)
 312 2011-09-25 03:53:21 <casascius> even at 40+ characters?
 313 2011-09-25 03:53:33 <gmaxwell> Even at 40+ characters.
 314 2011-09-25 03:53:56 <casascius> given enough characters, even plain text starts to have plenty of entropy assuming it still has enough nonsense in it that makes it non-dictionary
 315 2011-09-25 03:54:28 <phantomcircuit> http://www.fourmilab.ch/random/
 316 2011-09-25 03:54:30 <phantomcircuit> give it a try
 317 2011-09-25 03:54:40 <gmaxwell> The usual ways people add nonsense hardly increase the entropy at all. Almost always they'll meet that kind of requirement by adding a '!' to the end, or the like.
 318 2011-09-25 03:54:48 mindphlux has left ()
 319 2011-09-25 03:55:04 <casascius> i can certainly agree with that
 320 2011-09-25 03:55:18 <gmaxwell> casascius: In any case a good passphrase plus 128 bits of solid entropy gives you security that no one can argue with... and that even a moronic user can't screw up.
 321 2011-09-25 03:55:54 <casascius> so basically...deterministic wallets are a fantastic idea except for exactly one problem, the user
 322 2011-09-25 03:55:58 <casascius> =)
 323 2011-09-25 03:56:01 <gmaxwell> Not so.
 324 2011-09-25 03:56:20 <casascius> There's more than one problem?  Or less? =)
 325 2011-09-25 03:56:35 <gmaxwell> You can simply use a passphrase + random string with enough entropy. There you go, fully determinstic wallet.
 326 2011-09-25 03:57:18 <gmaxwell> Don't conflate determinstic wallet with passphrase based wallet. You can have the former without the latter.
 327 2011-09-25 03:57:19 <casascius> How does the user ideally persist the random string?
 328 2011-09-25 03:57:39 <casascius> gotcha
 329 2011-09-25 03:58:01 <gmaxwell> By storing it on disk, and backing it up on paper... they could just write down 16 short english words that encode it, or a base36 version if you like.
 330 2011-09-25 03:58:36 <gmaxwell> The passphrase protects it from theft even if the disk isn't protected.  The data protects it against dictionary attacks (and accidental duplication!)
 331 2011-09-25 03:58:36 <casascius> What do you think about the notion that storing it on disk puts it at risk?  (he'd need to encrypt it with yet another secure key.... a catch 22)
 332 2011-09-25 03:58:58 <gmaxwell> It's no more risky than a purely passphrase based system alone.
 333 2011-09-25 03:59:27 <gmaxwell> (at worst, in practice it's far more secure, since everyone has some security on their disk— it's not available to the general public)
 334 2011-09-25 03:59:41 <casascius> Tell me what you think of this idea (it's for average joe to securely generate a wallet even though we know average joe isn't security conscious).
 335 2011-09-25 04:00:09 <casascius> Imagine I run XYZ wallet protection service.  (eye rolling time)
 336 2011-09-25 04:00:16 <gmaxwell> (not just not security conscious, he also just doesn't know enough and also can't correctly assess the risks)
 337 2011-09-25 04:00:16 <casascius> But here is how my service works.
 338 2011-09-25 04:00:33 <casascius> My job is to ensure that the only person with the complete key to joe's bitcoins is joe.
 339 2011-09-25 04:00:44 <casascius> Not the guy who rooted his box, and certainly not me.
 340 2011-09-25 04:01:20 <casascius> As part of my wallet protection service, someone else maintains an open source bitcoin client that has built-in features to take advantage of my service.
 341 2011-09-25 04:01:41 Zarutian has quit (Remote host closed the connection)
 342 2011-09-25 04:01:43 <casascius> And here is how key generation works.
 343 2011-09-25 04:01:52 <casascius> I generate some private keys, and Joe generates some private keys.
 344 2011-09-25 04:02:00 <casascius> We share with one another the public keys.
 345 2011-09-25 04:02:26 <casascius> With both of those public keys, we hash them together with ripemd160(sha256()) to form bitcoin addresses.
 346 2011-09-25 04:03:08 <casascius> Given that the only thing that really defines what a bitcoin address is whatever comes right before OP_HASH160
 347 2011-09-25 04:03:16 <casascius> nothing says that the bitcoin address has to be the hash of a pubkey.
 348 2011-09-25 04:03:26 <casascius> It could be a hash of two pubkeys concatenated together.
 349 2011-09-25 04:03:36 <casascius> Anyway, for joe to spend his funds, he goes into this special client and whips up a transaction just like normal.
 350 2011-09-25 04:03:42 <casascius> But this transaction needs 2 signatures.
 351 2011-09-25 04:04:10 <casascius> The special client makes an api call to my XYZ wallet protection service, and basically says... Here is a transaction from Joe to asdfasdfasdf signed by Joe, just waiting for your signature.
 352 2011-09-25 04:04:20 <gmaxwell> I guess you're not aware that we have this functionality already to be merged, accept for the special address type — and thats mostly just delayed because there was some argument about how flexible it should be?
 353 2011-09-25 04:04:34 <casascius> As part of my services, I send joe an SMS and make sure it's legit...then I sign...then voila.
 354 2011-09-25 04:04:45 <casascius> I am aware the functionality has been discussed, but am not aware of a merged status.
 355 2011-09-25 04:04:58 <gmaxwell> https://github.com/groffer/bitcoin/commit/dc2dfbab6a0f75070fc3b962da4eb2967e9659df
 356 2011-09-25 04:05:00 <casascius> I am aware up to the extent that there is consideration being made to modify IsStandard
 357 2011-09-25 04:05:07 <gmaxwell> It's the secured funds usecase there.
 358 2011-09-25 04:05:30 <casascius> but the only problem is that all of those funds have to be "secured" before they become "secure"
 359 2011-09-25 04:06:04 <casascius> and any time new funds roll in, unless they're pre-secured by the sender, somebody has to go back and secure them or they're not secure...
 360 2011-09-25 04:06:13 <gmaxwell> The question is should the address type only allow 2of2 / 2of3 transactions, or should it allow the full RPN ruleset where someone can specify a full boolean logic statement about what mixtures of keys are allowed to spend from the escrow.
 361 2011-09-25 04:06:28 twmz has quit (Remote host closed the connection)
 362 2011-09-25 04:06:36 <casascius> when you say the address type, do you mean the bitcoin address?
 363 2011-09-25 04:06:37 <gmaxwell> Yes, thats all been discussed on the list, I wish I knew how to link to the archives.
 364 2011-09-25 04:07:13 <gmaxwell> casascius: yes, you'd need a new address type so that the sender knows to write the special requirements into the output they write.
 365 2011-09-25 04:07:19 <casascius> I am somewhat familiar with the discussion because gavin posted something in the forums a while back about inventing a new kind of bitcoin address that was twice as long and incorporated two privkeys and I said boo
 366 2011-09-25 04:07:21 <gmaxwell> And in that address you can encode the required rules.
 367 2011-09-25 04:08:19 <gmaxwell> It expanded abit because we realized you could easily encode arbitrary rules.  Like (A and B) or (C and D) (where the letters are addresses)
 368 2011-09-25 04:08:21 <phantomcircuit> it's my understanding that the movement related to n of m transactions has been mostly due to his involvement with trucoin
 369 2011-09-25 04:08:35 <casascius> by boo, i had the following to say... #1 that it was a very big expense in the minds of users...users would suddenly need to know why people had 2 addresses, a short one and a really long one
 370 2011-09-25 04:08:43 <phantomcircuit> ie they want to offer escrow services for bitcoin using n of m transactions and gavin has pushed those forward
 371 2011-09-25 04:08:48 <phantomcircuit> which seems kind of scummy
 372 2011-09-25 04:09:12 <casascius> and that #2 it made the addresses almost completely infeasible for any kind of printed medium.... to fit one of those addresses in a QR code you'd need it to be huge
 373 2011-09-25 04:09:42 <gmaxwell> well, better than the argument you could make in the past that gavin's prior escrow service was retarding N of M because those largely reduce the role of an escrow service.
 374 2011-09-25 04:10:15 <gmaxwell> "why people had 2 addresses" ugh! thinking that people 'have' a single address is a terrible thing.
 375 2011-09-25 04:10:18 <casascius> I had a proposal to make a modification to OP_CHECKSIG, in fact I pastebinned "pseudo code", the point of which was to enable n of m transactions in the form of bitcoin addresses that still remained well-formed base58 bitcoin addresses based on 160 bit ripemd hash
 376 2011-09-25 04:10:26 <gmaxwell> Generally bitcoin addresses should be single shotish.
 377 2011-09-25 04:10:53 <phantomcircuit> gmaxwell, he said he stopping running clearcoin specifically because he didn't feel comfortable holding all of those bitcoins himself
 378 2011-09-25 04:11:03 <gmaxwell> casascius: you'd still need to know you have to change your output script type, it sounds like you're describing something impossible there.
 379 2011-09-25 04:11:05 <phantomcircuit> gmaxwell, n of m would address that issue so he is no longer liable
 380 2011-09-25 04:11:16 <casascius> aha...and that's the meat of my proposal.
 381 2011-09-25 04:11:16 <gmaxwell> phantomcircuit: well, it's good functionality regardless.
 382 2011-09-25 04:11:31 <phantomcircuit> gmaxwell, true but it still seems scummy
 383 2011-09-25 04:11:36 <casascius> the meat of my proposal with respect to avoiding the need to change your output script type.
 384 2011-09-25 04:11:57 <gmaxwell> casascius: thou shall not break the blockchain by changing the validation logic, either.
 385 2011-09-25 04:12:34 clr_ has quit (Quit: Ex-Chat)
 386 2011-09-25 04:12:52 <casascius> I shall not break the block chain for me... but what I had essentially proposed was to make the change only for testnet.  (Since it will be a long time before XYZ wallet service ever exists).
 387 2011-09-25 04:13:17 <casascius> And to flip the switch only when some other unforeseen circumstance necessitated some forking change to the block chain (sort of what just got whopped on namecoin just recently)
 388 2011-09-25 04:14:00 <gmaxwell> as far as QR codes go, we're only talking about ~2x the size of normal addresses for the 2 of 2 case.
 389 2011-09-25 04:14:02 <casascius> Does that put it beyond the threshold of consideration?
 390 2011-09-25 04:14:07 <phantomcircuit> XYZ wallet service?
 391 2011-09-25 04:14:36 <casascius> I am thinking the ideal safety would be a 3-key deal.  With 2 private keys, if XYZ goes under, Joe's screwed out of all his BTC
 392 2011-09-25 04:15:22 <casascius> Ideally, it's (A AND B) OR C... key A is on joe's computer...key B is on my XYZ wallet service... and key C is a deterministically generated key, Joe has the seed in his safe, and it's his failsafe against my failure to exist
 393 2011-09-25 04:15:29 <gmaxwell> casascius: it's not clear to me how you'd do subsets with what you've described.
 394 2011-09-25 04:15:54 <casascius> I'm not sure I understood what you meant by subsets
 395 2011-09-25 04:16:21 <gmaxwell> okay I see a way to do it.
 396 2011-09-25 04:17:10 <gmaxwell> So you'd provide all three public keys when you spend that input, and then signatures for either A&B or C, and the software would just know (based on the address type) that this was okay.
 397 2011-09-25 04:17:53 <gmaxwell> It sounds okay, except it requires breaking the blockchain. Such a change is unlikely to happen any time soon, and when it does happen I wouldn't be surprised to see if it came with a cryptosystem change that made addresses longer than you think is viable in any case. :)
 398 2011-09-25 04:17:57 <casascius> exactly
 399 2011-09-25 04:18:15 <nanotube> afaik, problem with making funky addresses that are a combination of multiple keys is that currently the concat op is disabled in script
 400 2011-09-25 04:18:20 <casascius> No one saw the Namecoin change coming...and besides, we can wait a very long time with this.
 401 2011-09-25 04:18:25 <nanotube> so making those a reality would require forking the chain
 402 2011-09-25 04:18:37 <casascius> my proposal wouldn't depend on the concat op
 403 2011-09-25 04:18:39 <gmaxwell> It also makes the spend transactions unfortunately big, and also gives an attacker a very nice degree of freedom, though if the 'address' is big enough it doesn't matter.
 404 2011-09-25 04:19:07 <nanotube> casascius: didn't you mention something about the combination address being a hash of a concat of multiple keys/hashes?
 405 2011-09-25 04:19:07 <gmaxwell> casascius: if it doesn't depend on the concat op it still depends on the moral equivilent.
 406 2011-09-25 04:19:33 <casascius> nanotube: yep, but the way i see it, the concatenation would occur by the spend transaction emitting multiple pubkeys already pre-concatenated together
 407 2011-09-25 04:19:37 <casascius> in place of a single pubkey
 408 2011-09-25 04:19:48 <casascius> in other words...if a pubkey is a blob of bytes... I just mean a bigger blob of bytes.
 409 2011-09-25 04:19:57 <nanotube> but it all needs to be validated
 410 2011-09-25 04:20:00 <nanotube> at /some/ point
 411 2011-09-25 04:20:15 <casascius> nanotube: yep, let me find my pastebin link to the pseudo code where i describe how that validation takes place
 412 2011-09-25 04:20:20 <phantomcircuit> lol wow
 413 2011-09-25 04:20:41 <casascius> http://pastebin.com/5aR9EGcn
 414 2011-09-25 04:20:45 <phantomcircuit> gbp spread on intersango overlaps with the mtgox spread
 415 2011-09-25 04:20:53 <phantomcircuit> someone running arb could make decent money
 416 2011-09-25 04:21:16 <casascius> in this case, I have literally renamed OP_CHECKSIG to OP_CHECKSIGEX and called it check signature expression.  And redefined a blob containing one pubkey as an expression that evaluates, well, one pubkey.
 417 2011-09-25 04:21:40 <casascius> Caps are my additions (in the pastebin)
 418 2011-09-25 04:21:59 <gmaxwell> What I mean by 'degree of freedom' for an attacker is this, btw: you pay a zillion btc to one of those addresses. I generate a key, put it in the C role, and use it to sign a txn spending those coins, then I search for random numbers A/B to make the hash match. Since A+B >>160 bits I can be pretty sure a solution exits.  Though I'd need a quantum computer to do the search in practice, it's still a new vulnerablility we don't have today.
 419 2011-09-25 04:22:09 <nanotube> phantomcircuit: if they overlap, that means no arb. there's only arb if they don't overlap
 420 2011-09-25 04:22:29 <phantomcircuit> i guess i mean they're shifted?
 421 2011-09-25 04:22:33 <phantomcircuit> i dont know what i mean
 422 2011-09-25 04:22:44 <nanotube> phantomcircuit: you mean, the don't overlap, then :)
 423 2011-09-25 04:22:55 <casascius> gmaxwell: If you have the capability of finding x such that ripemd160(sha256(x)) = the value of your choice, you already can spend any bitcoin on the whole blockchain without any help.  How would this feature change anything?
 424 2011-09-25 04:23:32 <forrestv> i was thinking that addresses could be reimplemented as being the hash of the check script, rather than the hash of the pubkey
 425 2011-09-25 04:23:36 <gmaxwell> casascius: today X also must be a valid ecc public key for which you hold the private key.
 426 2011-09-25 04:24:17 <gmaxwell> forrestv: hard to know when someone has given you coins, because they might have used a script you weren't expecting.
 427 2011-09-25 04:24:48 <forrestv> ah, true
 428 2011-09-25 04:25:35 <casascius> gmaxwell: OK, I understand what you're saying by taking away the ecc... I suppose I would argue that in the process, it would take away a real problem we have today, and that's that the news is full of reports about how bitcoin is insecure and how everyone is getting their funds stolen...
 429 2011-09-25 04:26:07 <casascius> that the odds of joe losing his bitcoins due to malware is far more probable than the odds of a technology advance that breaks ripemd160(sha256(x)) wide open
 430 2011-09-25 04:26:20 <gmaxwell> casascius: one method I use for evaluating the security of proposals is that I ask myself "if we happened to pick the most, restospectively, unluckly design like this and happened to be using MD5 or MD4 algorithims, how screwed would be be right now"
 431 2011-09-25 04:27:11 <gmaxwell> And I think that design fails that test, we'd be totally screwed if they could put the junk bytes at the end for md5. But our current system would be completely fine at the moment, because the md5 attacks won't let you pick collissions that happen to be ecc public keys for which you know the private key.
 432 2011-09-25 04:27:58 <gmaxwell> And I think it's prudent design to assume that there _will_ be advances that make sha256 and perhaps the composition bitcoin uses for addresses just as weak as md5 is today.
 433 2011-09-25 04:29:17 <casascius> If you did this brute forcing, wouldn't A and B have to at least be valid points on the elliptic curve, not just junk bytes you generated incrementally?
 434 2011-09-25 04:29:40 clr__ has joined
 435 2011-09-25 04:30:00 <gmaxwell> Only if you stipulated that the validation check that A/B look like valid public keys even if you're only spending with C.  But hey, thats a good point. :)
 436 2011-09-25 04:30:00 <casascius> (not in my pseudo code, but not something that couldn't be added)
 437 2011-09-25 04:30:41 <gmaxwell> (and thats the kind of good thinking that comes out of this style of paranoid design)
 438 2011-09-25 04:31:19 <gmaxwell> If we were to break bitcoin to add a validation type we really should add key recovery.
 439 2011-09-25 04:31:21 <casascius> I am not sure how hard it is to generate points-on-a-curve, but i suppose it's better than nothin'
 440 2011-09-25 04:31:39 <gmaxwell> (by key recovery I mean recovering the ecc public key from the address and the signature)
 441 2011-09-25 04:31:58 <gmaxwell> casascius: yea, it's really trivial, but even that little would probably break the current md5 attacks.
 442 2011-09-25 04:32:21 <casascius> what is your idea of key recovery?
 443 2011-09-25 04:33:20 <gmaxwell> oh, it's possible if you have data+signature to decode the public key from it. Then you make sure the decoded public key matches the addresses you were expecting. It would reduce the size of normal bitcoin txn by 1/3rd and two sign txn by halfish.
 444 2011-09-25 04:33:56 <gmaxwell> (Satoshi probably didn't know that this was possible)
 445 2011-09-25 04:34:22 <gmaxwell> It's also possible that certicom has patented it, but I don't believe so. Someone would do well to search to get more confidence on that point.
 446 2011-09-25 04:34:36 peck has quit (Read error: Connection reset by peer)
 447 2011-09-25 04:34:55 Diablo-D3 has quit (Ping timeout: 252 seconds)
 448 2011-09-25 04:34:57 peck has joined
 449 2011-09-25 04:35:08 <casascius> That's interesting, that would be a cool way to chop down the resource requirements
 450 2011-09-25 04:35:16 <casascius> is it slow?
 451 2011-09-25 04:35:28 <casascius> (compared to say, validating the signature)
 452 2011-09-25 04:35:37 <gmaxwell> A little bit. Figure it doubles the validation cost.
 453 2011-09-25 04:36:22 <gmaxwell> Though our ecc implementation is far from the fastest possible one in any case. Openssl's code is generic and somewhat speed optimized but not excessively so.
 454 2011-09-25 04:37:18 <gmaxwell> The space savings gets important if you're talking about having three keys (or more) on transactions.
 455 2011-09-25 04:38:05 <casascius> definitely agree, however, it probably wouldn't work in situations where you don't need all three signatures.  You need all 3 pubkeys to validate the hash, but won't be having all 3 signing the transactions
 456 2011-09-25 04:38:19 <gmaxwell> also, in your design I'd avoid providing the keys for anything but the ones being used. The unused keys should be provided as addresses and the hash should be over the addresses not the keys.
 457 2011-09-25 04:38:29 <gmaxwell> casascius: you provide the addresses of the keys you aren't using.
 458 2011-09-25 04:38:46 <gmaxwell> or rather you provide all addresses, and you recover the public keys of the ones you use.
 459 2011-09-25 04:38:54 <casascius> that'd work
 460 2011-09-25 04:39:00 <casascius> i suppose it would be a completely different script output type
 461 2011-09-25 04:39:07 <casascius> a different op_checksig
 462 2011-09-25 04:39:56 <gmaxwell> Yep. but that sort of thing is no big deal if you're already committed to breaking the chain.
 463 2011-09-25 04:41:06 <casascius> hashing over the addresses instead of the keys would probably be a pretty great idea...i suppose it would need a different script output
 464 2011-09-25 04:41:18 <casascius> (but one that would be compatible with making all normal transactions use it)
 465 2011-09-25 04:42:32 <casascius> just thinking here...
 466 2011-09-25 04:42:52 <casascius> if instead of scriptsig being signature then pubkey...
 467 2011-09-25 04:42:59 <casascius> there would just be signature_blob
 468 2011-09-25 04:43:24 <casascius> if it was an (A AND B) OR C transaction, signature blob would contain three things
 469 2011-09-25 04:43:36 <casascius> those three things could either be a signature, or a bitcoin address.
 470 2011-09-25 04:44:14 WakiMiko has quit (Ping timeout: 276 seconds)
 471 2011-09-25 04:44:28 <casascius> There would have to be some hash op that turned those into a new blob.
 472 2011-09-25 04:44:47 <casascius> so, first OP_DUP the blob so we have two copies of it, one for signature checking, one for comparing it with the hash.
 473 2011-09-25 04:45:06 gjs278 has quit (Remote host closed the connection)
 474 2011-09-25 04:45:21 WakiMiko has joined
 475 2011-09-25 04:45:33 <casascius> Imagine OP_HASH160GROUP turned that blob of 3 things into a new blob of 3 things: hashes left unchanged, but signatures turned into ripemd160(sha256(pubkey)).
 476 2011-09-25 04:45:59 <casascius> then OP_HASH160 would produce a single 160 bit hash on the three bitcoin addresses.
 477 2011-09-25 04:47:02 <casascius> so, OP_DUP OP_HASH160GROUP OP_HASH160 (bitcoinaddress) OP_EQUALVERIFY OP_CHECKSIGEX
 478 2011-09-25 04:47:02 SomeoneWeird is now known as SomeoneWeirdAFK
 479 2011-09-25 04:48:15 <casascius> the question is, does this eliminate the opportunity for somebody to bruteforce A and B... it almost seems it would.
 480 2011-09-25 04:48:28 <casascius> Or would not, rather, the problem would still exist.
 481 2011-09-25 04:49:11 <casascius> You provide all the addresses, but there's no constraints on what A and B are.
 482 2011-09-25 04:49:45 <casascius> You could provide your own C and a signature for it, and bruteforce random bytes in place of A and B and get away with it, couldn't you?
 483 2011-09-25 04:50:56 <casascius> The OP_CHECKSIG(EX) is going to pass based on your C, the only thing in your way is OP_EQUALVERIFY on the hash160, and you have a spot where you can put junk input into the hash that doesn't need to satisfy any constraint
 484 2011-09-25 04:53:06 <gmaxwell> Yep, alas, but we made the txn much smaller. Looks like a tradeoff.
 485 2011-09-25 05:06:59 clr__ has quit (Ping timeout: 276 seconds)
 486 2011-09-25 05:07:07 imsaguy has joined
 487 2011-09-25 05:13:58 t3a has joined
 488 2011-09-25 05:14:20 <casascius> OP_SIGTOKEY
 489 2011-09-25 05:15:47 <casascius> pop a signature off the stack and replaces it with the private key that would have produced that signature
 490 2011-09-25 05:16:19 <gmaxwell> casascius: public key,  such an op needs to also know the address you're expecting that key to have.
 491 2011-09-25 05:16:40 <gmaxwell> (because the procedure has one bit of ambiguity, there are two possible keys, and you'll use the address to disambiguate them)
 492 2011-09-25 05:16:47 <gmaxwell> (well, sometimes two possible keys)
 493 2011-09-25 05:16:49 <casascius> yep... OP_DUP OP_SIGTOKEY OP_HASH160 (constant) OP_EQUALVERIFY
 494 2011-09-25 05:17:06 <casascius> hmm
 495 2011-09-25 05:18:22 <casascius> for each OP_SIGTOKEY run the script twice, each iteration doing "this" versus "that" key?
 496 2011-09-25 05:18:35 <casascius> and accepting it if any of them passes?
 497 2011-09-25 05:19:20 <casascius> e.g. if there's three OP_SIGTOKEY, script would run up to 8 times, each with a different combination of OP_SIGTOKEY outputs
 498 2011-09-25 05:20:17 <gmaxwell> Thats ugly. Just make it take a list of acceptable addresses and have it reorder the list based on what was used.
 499 2011-09-25 05:20:28 Daniel0108 has quit (Ping timeout: 260 seconds)
 500 2011-09-25 05:21:41 <casascius> The way I described it is ugly... it would merely be a recursive algorithm where the code for OP_SIGTOKEY recursively calls someting to process the remainder of the script, but does so twice, first with a parameter of 0, second with a parameter of 1
 501 2011-09-25 05:21:48 <casascius> and it saves valuable transaction space
 502 2011-09-25 05:22:44 <gmaxwell> Hiding that detail from the script is better.
 503 2011-09-25 05:23:45 <casascius> not sure I understood what would be hidden
 504 2011-09-25 05:24:24 <casascius> if we're trying to save space, wouldn't giving a list of acceptable addresses be undoing that quite a bit?
 505 2011-09-25 05:24:30 <gmaxwell> figuring out which signatures match to witch keys.
 506 2011-09-25 05:25:43 <gmaxwell> I see what you're saying, I'll have to think about that some.
 507 2011-09-25 05:25:47 <copumpkin> I prefer wizard keys
 508 2011-09-25 05:25:51 <gmaxwell> hehe
 509 2011-09-25 05:26:00 <copumpkin> or maybe warlock keys, since they sound badass
 510 2011-09-25 05:26:08 * copumpkin disappears again
 511 2011-09-25 05:26:20 <casascius> We already know what address we're expecting anyway, it should appear later in the script
 512 2011-09-25 05:26:48 <casascius> (at least in the case of a 1-address transaction, not m of n)
 513 2011-09-25 05:30:17 ByronJohnson has quit (Remote host closed the connection)
 514 2011-09-25 05:33:54 magn3ts has quit (Ping timeout: 248 seconds)
 515 2011-09-25 05:35:09 magn3ts has joined
 516 2011-09-25 05:38:38 Stellar has joined
 517 2011-09-25 05:41:16 ByronJohnson has joined
 518 2011-09-25 05:44:27 <casascius> random question...I know i could find this if I look...can anyone tell me off the top of their head what bitcoind sits and does for about two minutes each time you start it?
 519 2011-09-25 05:44:38 <casascius> (before it becomes responsive to RPC commands, even help)
 520 2011-09-25 05:46:32 <neofutur> updating the blockchain
 521 2011-09-25 05:47:25 <casascius> against peers?
 522 2011-09-25 05:48:09 <luke-jr> s/updating/loading
 523 2011-09-25 05:48:23 <gmaxwell> Loading the addresses most likely.  Look at the logs.
 524 2011-09-25 05:49:46 coblee has quit (Quit: coblee)
 525 2011-09-25 05:49:55 <casascius> oh yep.... Loaded 241349 addresses 69510ms
 526 2011-09-25 05:50:30 <casascius> this means bitcoin addresses? or peer addresses?  (241349 seems like too many peers but not enough addresses)
 527 2011-09-25 05:50:45 coblee has joined
 528 2011-09-25 05:52:38 <gmaxwell> Peer addresses.
 529 2011-09-25 05:53:04 <casascius> are there really 240,000+ peers on the bitcoin network?
 530 2011-09-25 05:53:05 <gmaxwell> It's too many because it never forgets them and it rumors them, and various nodes have been running on dynamic IPs for a long time, so...
 531 2011-09-25 05:53:22 <casascius> so i could delete this file and get a better startup time each time i compile
 532 2011-09-25 05:55:05 magn3ts has quit (Ping timeout: 276 seconds)
 533 2011-09-25 05:55:40 <casascius> blkindex.dat.... this is simply a mapping of block hashes to their respective offsets in blk0001.dat?
 534 2011-09-25 05:56:01 <gmaxwell> casascius: no, transaction ids to offsets too.
 535 2011-09-25 05:56:12 <gmaxwell> and yes, feel free to delete addr.dat.
 536 2011-09-25 05:56:33 <casascius> if i delete blkindex.dat but not blk0001.dat does it rebuild the index?
 537 2011-09-25 05:56:33 <gmaxwell> If you delete blkindex.dat you'll need to fetch the blockchain again, I don't think it can rebuild it from the blk0001.da
 538 2011-09-25 05:57:25 Toawa has joined
 539 2011-09-25 05:58:55 <casascius> does blkindex.dat also keep flags on which txids are spent vs unspent?
 540 2011-09-25 05:59:35 <Toawa> I don't know if anyone is awake... I had an idea for something to add to the protocol and figured this would be a good place to air it...  Ok, I guess at least one person is awake...
 541 2011-09-25 06:04:44 <ThomasV> casascius: I have a question concerning your deterministic wallet. if I own a set of addresses generated from a seed, can I infer the seed, or can I generate other addresses that would be generated with the seed ?
 542 2011-09-25 06:05:14 <casascius> thomasv: mine as implemented in Casascius Bitcoin Utility? or just in the abstract?
 543 2011-09-25 06:05:27 <casascius> You should not be able to infer the seed
 544 2011-09-25 06:05:53 <Toawa> Essentially, it would be a "return address", incorporated as some recognizable bit of info in the signatureScript, (guarded by an OP_DROP like any other arbitrary data), which could be used to inform the destination of a return address to send funds, if necessary.  It would be useful in situations where there might be change/refunds forthcoming to the payer, but having them provide a...
 545 2011-09-25 06:05:55 <ThomasV> did not know there are several versions of it
 546 2011-09-25 06:05:55 <Toawa> ...separate address manually would be difficult, such as when paying a bill at a location with a mobile phone.
 547 2011-09-25 06:06:04 Tracker- has joined
 548 2011-09-25 06:06:28 <Toawa> The user could incorporate the return address, which would then be available if it should be needed.
 549 2011-09-25 06:06:54 <casascius> toawa: the protocol already would support such a thing, nothing to add
 550 2011-09-25 06:07:06 <Toawa> Perhaps protocol wasn't the correct word
 551 2011-09-25 06:07:50 Tracker has quit (Ping timeout: 258 seconds)
 552 2011-09-25 06:07:51 <ThomasV> casascius: and my second question?
 553 2011-09-25 06:08:11 <Toawa> Protocol in the sense that it's something available in the main client, or the docs, and by its presence make it more likely that others will pick up on it.
 554 2011-09-25 06:08:17 <casascius> You would not be able to generate more addresses without knowing the seed
 555 2011-09-25 06:08:24 <ThomasV> ok thanks
 556 2011-09-25 06:08:59 <Toawa> (So, protocol in the academic sense rather than the technical sense)
 557 2011-09-25 06:09:10 <Toawa> (er, sociological sense?)
 558 2011-09-25 06:09:16 <casascius> i think most people are against allowing arbitrary data in the blockchain
 559 2011-09-25 06:09:33 <Toawa> It's not arbitrary data; it's data with a specific purpose.
 560 2011-09-25 06:10:06 <casascius> what would the purpose be? one click return to sender?
 561 2011-09-25 06:10:11 <Toawa> Exactly.
 562 2011-09-25 06:10:15 <ThomasV> the blockchain is not a communication medium
 563 2011-09-25 06:10:33 magn3ts has joined
 564 2011-09-25 06:10:46 <Toawa> Of course it is; it's communicating all sorts of transaction information.
 565 2011-09-25 06:10:56 <casascius> You could vanity-generate your sending addresses to include some sort of flag that "this address accepts returns"...
 566 2011-09-25 06:11:46 <Toawa> That's another possibility, certainly, but not as preferable for at least two reasons...
 567 2011-09-25 06:11:50 <gmaxwell> casascius: then people who didn't care about that functionality would randomly end up with it.
 568 2011-09-25 06:12:02 <Toawa> That's #1
 569 2011-09-25 06:12:03 <gmaxwell> If you care about that just define some allowable suffix on addresses.
 570 2011-09-25 06:13:07 <casascius> of course you are kind of blowing your anonymity at the same time
 571 2011-09-25 06:13:33 <Toawa> The other is vanity address generation is adding more complexity on the user side that should really be necessary...  I don't see how incorporating information into signatureScript is so bad.  And of course, it would be completely optional.
 572 2011-09-25 06:13:54 <casascius> it's bad because it takes up my hard disk space and yours and bandwidth and everyone else's just to (maybe) save you a click
 573 2011-09-25 06:14:17 <Toawa> It's not a matter of saving a click
 574 2011-09-25 06:14:33 <Toawa> This is aimed more at non-Internet usage.
 575 2011-09-25 06:14:47 <ThomasV> non-internet bitcoins?
 576 2011-09-25 06:14:50 <gmaxwell> Every byte in bitcoin takes up >40,000 bytes, potentially forever.
 577 2011-09-25 06:15:26 <casascius> what purpose would it serve?  you mention paying a bill with a mobile phone...under what circumstances would the bill want to pay you back?
 578 2011-09-25 06:16:22 <Toawa> Say, gas or hotel.. Something which, using current credit cards, require holds to be placed on the card.  That's obviously not possible with Bitcoin, so you'd have to pay more than you expect to use, and then recieve the rest later.
 579 2011-09-25 06:16:55 <Toawa> I'd also like to know how you come up with 1 byte taking 40k.
 580 2011-09-25 06:17:21 <Toawa> If you mean in terms of storage duplication, I don't think that's a fair comparison.
 581 2011-09-25 06:17:35 <gmaxwell> Toawa: because its stored by every full validating node. There are 40,000 today. There will hopefully be more than that in the future and forever.
 582 2011-09-25 06:17:53 <gmaxwell> And of course, it's transmission duplication as well, since the data has to get to them somehow.
 583 2011-09-25 06:18:14 <ThomasV> and there are offline clients
 584 2011-09-25 06:18:33 <gmaxwell> Well, offline clients don't need to learn the bodies of txn that don't involve them.
 585 2011-09-25 06:18:50 <Toawa> It's unlikely to be used for every transaction.  Storage is cheap, and it's already been said that full block chain storage won't be a requirement forever, for everyone.
 586 2011-09-25 06:18:57 <casascius> How would that work?  You pay for gas... and then you have to wait for 6 confirmations anyway before you can pump it?
 587 2011-09-25 06:19:13 <Toawa> It's a hypothetical.
 588 2011-09-25 06:19:32 <gmaxwell> Toawa: It's not a requirement for everyone, but its still a requirement for a great number of nodes. If we don't have a great number of full validation nodes then bitcoin is not decenteralized anymore.
 589 2011-09-25 06:19:48 <ThomasV> gmaxwell: I mean full nodes that are currently offline, and that will catch up with the whole chain when they go online. there's a lot of them
 590 2011-09-25 06:20:00 <gmaxwell> ThomasV: ah, okay.
 591 2011-09-25 06:20:03 <casascius> (otherwise... you'd prepay 10BTC for gas, pump 1 mL, get 9.99 BTC back, and then execute a doublespend and steal the 9.99 BTC)
 592 2011-09-25 06:20:26 <gmaxwell> casascius: tisk tisk, you already solved that one.
 593 2011-09-25 06:20:37 <casascius> lol
 594 2011-09-25 06:20:50 <Toawa> As I said, storage is cheap.  Bandwidth is getting there.
 595 2011-09-25 06:21:17 <casascius> but I didn't solve the pay 10 BTC for gas, pump it all, and then double spend and steal the gas!
 596 2011-09-25 06:21:53 <gmaxwell> Toawa: cheap is relative. For a given amount of cheapness I'd rather bitcoin supports more users and mode full validating nodes, than to have a flag which could be sent in some other manner.
 597 2011-09-25 06:22:18 <gmaxwell> casascius: you did solve that too.. or rather other people did and you were talking about the same tool earlier.
 598 2011-09-25 06:22:44 <casascius> yeah, I'm just being difficult =)
 599 2011-09-25 06:22:48 <Toawa> And decentralization doesn't mean everyone has to have everything, just that enough need to have enough.  If bitcoin is ever to get to as lofty a height that some seem to envision it, it'll have to overcome much bigger problems than storage issues.
 600 2011-09-25 06:22:57 <gmaxwell> casascius: replace your XYZ wallet securirty with VISA double-spending prevention: "We promise to sign things only once!"
 601 2011-09-25 06:23:29 <Toawa> And the people to whom storage really is cheap, will be able to keep everything.
 602 2011-09-25 06:23:59 <casascius> yep, it would...assuming the gas pump owner could somehow be assured that I was using XYZ security
 603 2011-09-25 06:24:11 <gmaxwell> Toawa: of the technical concerns fast storage is one one of the most difficult, Satioshi was quite concerned that it needed too much as is.
 604 2011-09-25 06:24:39 <gmaxwell> casascius: presumably he'd require it, not one particular brand but any of hundreds of fundlocking services.
 605 2011-09-25 06:24:58 <casascius> i suppose that would work, interesting application I hadn't thought of
 606 2011-09-25 06:25:23 <gmaxwell> It's one of the multisig usecases listed in the readme for that pull request.
 607 2011-09-25 06:25:28 <Toawa> He might have done a better job of it, then..  The protocol could easily have incorporated ways to reliably store old unfilled outputs and drop earlier blocks...
 608 2011-09-25 06:25:53 <casascius> What's an unfilled output?
 609 2011-09-25 06:25:54 <gmaxwell> Toawa: er, it does.
 610 2011-09-25 06:26:13 <Toawa> In principle, an old block is no longer needed in full once all outputs are used.
 611 2011-09-25 06:26:22 <casascius> not true
 612 2011-09-25 06:26:25 <gmaxwell> Toawa: you can drop all spent outputs, and only store the merlek root fragements needed to connected it to the chain.
 613 2011-09-25 06:26:36 <Toawa> Exactly.  Hence the "in full"
 614 2011-09-25 06:27:01 <casascius> toawa: if you drop a block, the transactions that were inputs to the transactions you dropped suddenly look unspent
 615 2011-09-25 06:27:05 <gmaxwell> Sure, but thats some serious reduction at that point.
 616 2011-09-25 06:27:09 <gmaxwell> No, it could be done.
 617 2011-09-25 06:27:16 <ThomasV> could the invisible hand of the market solve storage issues? if storage becomes too expensive, some miners might decide to not include transactions involving very old blocks, and those who include them may charge more
 618 2011-09-25 06:27:18 <gmaxwell> By including a hash of a tree of all open txn in every block.
 619 2011-09-25 06:27:23 <Toawa> You'd drop those too, obviously.
 620 2011-09-25 06:27:28 <gmaxwell> I proposed to to namecoin so that lite namecoins could exist and be secure.
 621 2011-09-25 06:27:36 <Toawa> No, I take that back...
 622 2011-09-25 06:28:27 <Toawa> Even so, if you're maintaining your block database, you can make provisions for remembering which outputs go to used-but-dropped blocks.
 623 2011-09-25 06:28:42 <gmaxwell> I think Satioshi just didn't think of that, plus it would require more cpu to maintain... and doesn't provide much benefit for bitcoin's usage (though the lack of it in namecoin makes lite nodes impossible to make secure)
 624 2011-09-25 06:29:06 <Toawa> CPU isn't the big barrier, though... GPU is.
 625 2011-09-25 06:29:15 <gmaxwell> 0_o
 626 2011-09-25 06:29:24 <casascius> let's suppose you include a hash of a tree of all open transactions in every block.  You still sort of have to download all of the transactions (including the spent ones) to validate that hash
 627 2011-09-25 06:29:29 <gmaxwell> okay, I'm out, no use wasting time to people spouting gibberish.
 628 2011-09-25 06:29:29 <Toawa> In the amount of computation per block, the vast majority is going to be in the final sign.
 629 2011-09-25 06:29:46 <gmaxwell> Toawa: there is absolutely zero interaction between transactions and block validation.
 630 2011-09-25 06:29:59 <gmaxwell> 1 txn, 10,000 txn.. same work for the gpu.
 631 2011-09-25 06:30:12 <gmaxwell> Why not go actually read up on how bitcoin works before musing on how it could have been better.
 632 2011-09-25 06:30:20 <Toawa> I have.
 633 2011-09-25 06:30:25 <casascius> I have thought that a hash would be a good way to keep track of which transactions are spent and unspent, but that would make it very difficult to reliably download the whole block chain
 634 2011-09-25 06:30:59 <casascius> suppose block 10000 has 20 transactions.  and as of block 140000, 10 of them are spent.
 635 2011-09-25 06:31:08 <Toawa> It doesn't take 10 minutes of CPU to validate a new block.
 636 2011-09-25 06:31:10 <casascius> but as of block 139999, only 9 of them are spent.
 637 2011-09-25 06:31:55 <casascius> If teh current block is about 140000, some peers might send you the one with 11 transactions left, some might send you the 10.
 638 2011-09-25 06:32:19 wardearia has quit (Read error: Operation timed out)
 639 2011-09-25 06:32:55 <casascius> bottom line is you might have a very difficult time validating that "open transactions" hash if even one block isn't consistent due to something being spent off of it while you were downloading the block chain
 640 2011-09-25 06:33:05 <Toawa> That's already the case... It would depend on whether the winning block had the new transaction in it or not.
 641 2011-09-25 06:33:19 <casascius> does this sound like a bogus concern?  If your hash doesn't match, you have no way of knowing which of your blocks needs something new pruned off of it.
 642 2011-09-25 06:33:38 <Toawa> I don't envision downloading pre-pruned blocks
 643 2011-09-25 06:33:48 SomeoneWeirdAFK is now known as SomeoneWeird
 644 2011-09-25 06:33:51 <casascius> toawa: so then pruning blocks helps save your hard disk but not your internet bandwidth?
 645 2011-09-25 06:33:52 <Toawa> I envision it as you download whole ones, and then decide yourself what can be pruned.
 646 2011-09-25 06:34:06 <Toawa> You were concerned about storage...
 647 2011-09-25 06:34:08 <Toawa> Er
 648 2011-09-25 06:34:11 <Toawa> gmaxwell was
 649 2011-09-25 06:34:16 <gmaxwell> Yes, thats how it has to work.
 650 2011-09-25 06:34:18 <gmaxwell> Sadly.
 651 2011-09-25 06:34:19 <casascius> Not just storage, but resources in general
 652 2011-09-25 06:35:07 <gmaxwell> It could be improved— e.g. hash commitments to a tree of open txn, but that would mean that every full node would need to also maintain a particular hash tree structure of open txn.
 653 2011-09-25 06:35:14 Clipse has quit (Ping timeout: 248 seconds)
 654 2011-09-25 06:36:15 wolfspra1l has quit (Quit: leaving)
 655 2011-09-25 06:36:33 <casascius> This may not be the best proposal, but I also thought that every 2016 blocks, a "superblock" could be written that contains all of the open transactions.  Once such a block gained sufficient age (due to being confirmed by miners comparing it against the real blockchain), all of the blocks coming before it could be stripped to their 80 byte headers
 656 2011-09-25 06:36:40 <Toawa> Ultimately, as long as you're the one deciding what can be pruned, and you trust yourself, and you're not telling anyone else what to prune or not to prune, then it shouldn't matter to others what you do with your pruning...
 657 2011-09-25 06:36:54 <gmaxwell> if the system had this, this you could do full validation starting at any block— simply trusting that bad open txn hashes wouldn't get many confirmations.
 658 2011-09-25 06:36:55 <Toawa> That's basically what I thought of, too.
 659 2011-09-25 06:37:28 <gmaxwell> casascius: you don't have to do that, see the hash tree thing I was just describing, every block could confirm the open txn set.
 660 2011-09-25 06:37:29 <Toawa> I didn't envision it as a superblock; I was thinking more, if an open txn is older than X, put in an update.
 661 2011-09-25 06:37:37 <gmaxwell> for only the cost of a single extra hash.
 662 2011-09-25 06:37:46 <gmaxwell> (storage/network wise)
 663 2011-09-25 06:38:32 <gmaxwell> but ~log2(open txn) per txn extra sha256 operations on the cpu for all full nodes in order to update the structure.
 664 2011-09-25 06:38:37 <casascius> gmaxwell: that would work fantastically...i'm just not sure how the tree thing would help the case where someone received a wrongly pruned block during their blockchain download that made it impossible to arrive at that same hash
 665 2011-09-25 06:39:16 <casascius> the tree would certainly help you confirm that if you have the right set, that it really is right...
 666 2011-09-25 06:39:26 <casascius> but if you end up with the wrong set, what to do about it to make it right
 667 2011-09-25 06:39:29 <gmaxwell> because you can walk the tree a segement at a time to find out where a disagreement is.
 668 2011-09-25 06:39:45 <gmaxwell> e.g. it the root disagrees, you ask for the left and right hashes. And so on.
 669 2011-09-25 06:40:00 <casascius> so this would be some sort of message between the peers
 670 2011-09-25 06:40:30 <gmaxwell> You also wouldn't bother asking for pruned blocks. You'd ask for all the headers, and all the open txn _now_. Then you'd validate the hash, and trust your opentxn set once its been burried a bit.
 671 2011-09-25 06:40:56 <gmaxwell> so now you have a full validating node which only knows the headers and open txn... bootstrapped interactively from its peers.
 672 2011-09-25 06:41:11 EPiSKiNG has joined
 673 2011-09-25 06:41:12 <casascius> i always considered "pruned blocks" to be functionally equivalent to "block headers + open transactions"
 674 2011-09-25 06:41:39 <gmaxwell> For bitcoin this isn't so important, but for namecoin its critical, because the most interesting naming attack is creating false negative answers, whereas false negative answers in bitcoin is only a bit annoying.
 675 2011-09-25 06:42:01 * Toawa is not familiar with Namecoin...
 676 2011-09-25 06:42:14 <casascius> wouldn't a false negative be an opportunity for someone to send  you a payment you won't know is fake?
 677 2011-09-25 06:42:21 EPiSKiNG- has quit (Ping timeout: 256 seconds)
 678 2011-09-25 06:42:28 <gmaxwell> Toawa: uses the bitcoin distributed consensus algorithim to maintain a name/value mapping. Distributed DNS.
 679 2011-09-25 06:42:59 <Toawa> Wouldn't that always a risk when receiving low-confirmation coins, anyway?
 680 2011-09-25 06:43:23 <gmaxwell> casascius: nope! if your peers tell you an input doesn't exist, then you don't think you were paid. For lite clients you only want your peers to prove to your your payments were mined.
 681 2011-09-25 06:43:42 <gmaxwell> er prove to you.
 682 2011-09-25 06:44:09 <gmaxwell> E.g. someone says I paid you in txid 12345. You then keep asking your peers "tell me when 12345 is mined, and give me the fragement connecting it to the root of the block its in"
 683 2011-09-25 06:44:20 zapnap has quit (Remote host closed the connection)
 684 2011-09-25 06:45:08 <gmaxwell> apply the same model to namecoin and malicious peers can cause nxdomain, and they can force nodes to see old values for domains that have moved... and there is no way to detect that anything funny is going on.
 685 2011-09-25 06:46:56 <casascius> OK, so you have the headers and all of the open transactions.  What happens if you are given an extra transaction as open that really isn't, and you have no way to tell?  (because you won't have been given the transaction that spent it).... and this particular transaction grossly distorts your assembly of the tree?
 686 2011-09-25 06:47:04 wardearia has joined
 687 2011-09-25 06:48:04 <gmaxwell> It's a binary tree, you can uniquely identify it in log2(opentxn) operations.
 688 2011-09-25 06:48:06 <casascius> i am assuming the tree is pre-arranged based on some sort of pre-determinable sequence so everybody builds it the same way...
 689 2011-09-25 06:48:12 <gmaxwell> Right.
 690 2011-09-25 06:49:23 <gmaxwell> Obviously if you only have malicious peers there is nothing you can do — heck they could just refuse to reply to you at all.
 691 2011-09-25 06:49:42 <gmaxwell> The key point is that if your peers are NOT malicious, they actually have a way of proving this to you.
 692 2011-09-25 06:49:48 <casascius> so let's assume in an example that there are 9 open transactions, numbered, 1,3,4,5,6,7,8,9,10.  Except someone told me about transaction number 2 and I think it's open and it's really not.
 693 2011-09-25 06:50:19 <casascius> I go to build my tree.  At the top is 1, next row is 2,3, next row is 4,5,6,7, next row is 8,9,10,x,x,x,x,x...
 694 2011-09-25 06:50:37 <casascius> But everyone else's tree is 1, then 3,4, then 5,6,7,8, then 9,10,11,x,x,x,x,x.
 695 2011-09-25 06:50:42 <gmaxwell> thats not how a binary hash tree tree is structured.
 696 2011-09-25 06:50:59 <gmaxwell> the txn are only the leaves at the very end, everything else is pseudonodes in the middle.
 697 2011-09-25 06:51:28 <casascius> OK, I was thinking you were describing more like a merkle tree.
 698 2011-09-25 06:52:28 <gmaxwell> so you'd have the root which has everything under it, the left and right, the left has (1,3,4,5,6) right (7,8,9,10)  (obviously you don't use numbers, they're attached on the basis of their txids so the tree isn't perfectly balanced)
 699 2011-09-25 06:52:45 <gmaxwell> so you'd see left was wrong, and you'd keep subdividing.
 700 2011-09-25 06:53:05 <casascius> I follow you, but the more you subdivided, you'd never arrive at anything that was right.
 701 2011-09-25 06:53:26 <gmaxwell> Sure you would. Right would be correct there, because it doesn't contain 2 in either version.
 702 2011-09-25 06:53:44 <casascius> My left has (1,2,3,4,5) and my right has (6,7,8,9,10).  Your left has (1,3,4,5,6) and your right has (7,8,9,10).  At what point will we ever find a match, unless we exchange information about every single node on the tree?
 703 2011-09-25 06:53:49 <gmaxwell> No.
 704 2011-09-25 06:53:56 <gmaxwell> The split is determinstic based on the tx id.
 705 2011-09-25 06:54:16 <casascius> so all on the left starting with 00-7F and on the right 80-FF?
 706 2011-09-25 06:54:22 <gmaxwell> Right.
 707 2011-09-25 06:54:36 <gmaxwell> then you just shift a bit at each level.
 708 2011-09-25 06:55:21 <gmaxwell> But hold on a second. Even if repairing this way weren't possible that would still be okay.
 709 2011-09-25 06:55:40 <casascius> I can easily see how this would work to find and fix one error, but what about many errors?
 710 2011-09-25 06:55:48 <gmaxwell> You'd ask a peer for the complete open set. They'd give it to you. You'd validate it against the chain committment.. if it fails, you mark that peer as a loser and try again.
 711 2011-09-25 06:56:02 <casascius> with many errors, would you not simply be encountering overwhelmingly large numbers of non-matching hashes as you walk the tree?
 712 2011-09-25 06:56:28 <gmaxwell> Yes, there are ways to make this work for more errors but they become more costly quicky. What you then need is multiple trees.
 713 2011-09-25 06:56:31 <casascius> because any error is going to make all its parents up thru the root wrong.  And you have no way to know which peer is "bad"
 714 2011-09-25 06:57:05 <gmaxwell> (and you can design the multiple trees so they have a complementary layout, and for up to M errors at least one tree will be right at the root)
 715 2011-09-25 06:57:20 <gmaxwell> but thats silly, in the case of multiple errors you do what I suggested about going from peer to peer. :)
 716 2011-09-25 06:58:14 <casascius> I am not sure how you would know which peer gave you an open transaction that wasn't really open.  The tree is how you'd know if it was open, and while you're trying to piece together your tree, it won't help you
 717 2011-09-25 06:58:41 <casascius> Once you got your tree done, you would immediately know which peer was lying, but then it wouldn't matter any more, you're up to date.
 718 2011-09-25 06:59:17 <gmaxwell> casascius: just do your whole bringup from a single peer.
 719 2011-09-25 06:59:36 <casascius> is that how bitcoin does it now?
 720 2011-09-25 06:59:45 <gmaxwell> Pretty much.
 721 2011-09-25 07:00:03 <gmaxwell> Because of how it works its single threaded in pulling blocks.
 722 2011-09-25 07:00:04 <casascius> so it connects to 8 peers but picks one and only takes blocks from them?
 723 2011-09-25 07:00:55 <gmaxwell> the connectivity to 8 peers is more about the ongoing forwarding. Once it's up it'll fetch new blocks from the peer that first tells it about them.
 724 2011-09-25 07:01:10 <casascius> good to know
 725 2011-09-25 07:01:24 <Toawa> What about when it's building its initial chain? Can it get blocks from more than one?
 726 2011-09-25 07:01:34 <Toawa> Er, does it? Of course it can
 727 2011-09-25 07:01:42 <casascius> so if the block my client picks has sucky uplink, my block chain will take a while for him to push?  (i don't experience it first hand, i have enough computers with bitcoin that i would just connect to one on my lan...)
 728 2011-09-25 07:01:57 <gmaxwell> It can't really. I mean, it can, but it can't. It doesn't know the blockids yet.
 729 2011-09-25 07:02:32 <Toawa> You'd always have their position in the chain...  The nodes should know that much...
 730 2011-09-25 07:02:38 <gmaxwell> So what it does is it picks a node and basically says tell me blocks starting from $mycurrenttop to forever. (which gets clamped to 500)
 731 2011-09-25 07:03:11 <gmaxwell> Toawa: you learn the chain from the start on up— you have to in order to run the validation logic.
 732 2011-09-25 07:03:32 <Toawa> I get that, but that doesn't mean you can't get future blocks; it just means you might have to discard them
 733 2011-09-25 07:03:36 <gmaxwell> (well I suppose you could validate and fetch in different orders, but then you wouldn't catch a peer feeding you rubbish until very late)
 734 2011-09-25 07:03:50 <bd_> Toawa: block chain fetching tends to be CPU bound
 735 2011-09-25 07:03:59 <Toawa> And if you're the one asking, you can control when you ask for more blocks to add
 736 2011-09-25 07:04:01 <gmaxwell> bd_: disk bound actually. Try it on a SSD.
 737 2011-09-25 07:04:23 <bd_> well, disk bound primarily, cpu bound secondarily :)
 738 2011-09-25 07:04:27 <gmaxwell> Toawa: but you don't know what to ask for, you only know your current tip.
 739 2011-09-25 07:04:30 <bd_> and network bound at a distant third
 740 2011-09-25 07:04:40 <gmaxwell> and indeed, network bound is a distant third.
 741 2011-09-25 07:04:43 <Toawa> Ask by position in the chain.. #1, #2, #3, etc.
 742 2011-09-25 07:04:57 <gmaxwell> Toawa: but your peers may not have the same chain.
 743 2011-09-25 07:05:17 <Toawa> If they don't have the same chain that far down, something's very wrong...
 744 2011-09-25 07:05:40 <gmaxwell> Indeed. Though there are broken nodes out there.
 745 2011-09-25 07:05:54 <bd_> gmaxwell: well, that's fixable. Ask peer A for its tip, ask peer B for its tip, check that they match. If so, you know you can use matching block indices
 746 2011-09-25 07:06:02 <casascius> This little open transactions hash sounds like something that could be added to the client now, like in the coinbase transaction
 747 2011-09-25 07:06:02 <bd_> You just need to have a fallback for mismatched chains
 748 2011-09-25 07:06:10 <gmaxwell> Once that due to memory biterrors are stuck back in the chain and can't take another block (I assume! I've never actually gotten my hands on them, I've just seen them on the network)
 749 2011-09-25 07:06:11 <bd_> but really, go for the disk or CPU bound issues first
 750 2011-09-25 07:06:20 <Toawa> Anyway, since block #0 should always be known (built into the software) you can figure out right away if there's a mismatch..
 751 2011-09-25 07:06:37 <gmaxwell> Toawa: er, no, they can be mismatched any place in the middle.
 752 2011-09-25 07:07:06 <Toawa> You mean orphaned chains?
 753 2011-09-25 07:07:19 <gmaxwell> I wouldn't be surprised if there weren't some node out there .. that back on block 20,000 got a bit error that made it think a particular txn didn't exist.
 754 2011-09-25 07:07:30 <gmaxwell> then block 20,001 on the network spent that txn, and that node ignored the block.
 755 2011-09-25 07:07:38 <Toawa> Oh.. I think we might be talking about two different things...
 756 2011-09-25 07:07:46 <gmaxwell> The node is mining and is now up to block 150,000ish like hte rest of the network.. but it's all on its own. :)
 757 2011-09-25 07:08:05 <casascius> wasn't someone in the forums just describing how he had a bit error in his blockchain file?  are you familiar with that
 758 2011-09-25 07:08:09 <Toawa> Another reason not to ask for all the nodes from one peer
 759 2011-09-25 07:08:21 <bd_> Toawa: you can detect if they have an error like that
 760 2011-09-25 07:08:22 <bd_> easily
 761 2011-09-25 07:08:28 <bd_> and then switch to a different peer at that moment
 762 2011-09-25 07:08:36 <gmaxwell> it's chain is much shorter (since chain length includes difficulty) but it can never hop onto the main chain because of the error.
 763 2011-09-25 07:09:05 <casascius> somehow i think there ought to be a database rebuild function that verifies the integrity of blk0001.dat and rebuilds blkindex.dat from scratch
 764 2011-09-25 07:09:10 <Toawa> I mean, if you have 8 peers, you ask for #1 from peer 1, #2 from peer 2, etc.
 765 2011-09-25 07:09:15 <gmaxwell> casascius: ah, hadn't seen that. It's not uncommon though.. for non-ecc ram a desktop with 4g is taking a couple bit errors per day....
 766 2011-09-25 07:09:38 <Toawa> unless they're all identically wrong (in which case you're going to get bad data in any case) you'd figure out quickly that someone's wrong.
 767 2011-09-25 07:09:39 <gmaxwell> casascius: blk0001.dat has all kinds of orphan junk in it.
 768 2011-09-25 07:10:17 <casascius> he was a developer trying to parse his block file into his client and pulling hair out as to why exactly one of his blocks failed, and there was a 1-bit difference for some reason: his block had 0x00000400 in the nLockTime field
 769 2011-09-25 07:10:58 <Toawa> But again, I wonder if I'm talking about the same thing; I'm talking about bootstrapping a new node (something I know about, having done it a week or so ago) and how bloody long it took...  And wondering if that couldn't be improved...
 770 2011-09-25 07:11:02 <gmaxwell> heh. man, it will be really funny if someday someone shows up on IRC who checked into an old node and found he had a zillion btc.. because it got itself irrepariably orphaned and kept on mining.
 771 2011-09-25 07:11:06 Joric has joined
 772 2011-09-25 07:11:29 <gmaxwell> Toawa: well, as I mentioned its diskbound mostly due to doing sync writes to the index.
 773 2011-09-25 07:11:46 <gmaxwell> and if you remove that by using a ssd, you're cpu bound doing the validation.
 774 2011-09-25 07:11:57 <Toawa> I'd think if it were so orphaned, it wouldn't be in the peer bootstrap IRC..  I wasn't looking at disk stats, so I'll take your word for it.
 775 2011-09-25 07:12:17 <gmaxwell> gavin was suggesting turning off ecdsa before the last checkpoint, but I'm really skeptical that doing so should speed it up much.
 776 2011-09-25 07:13:02 <gmaxwell> Toawa: sure it will. if it's orphaned due to some data corruption gltich it'll still run like normal, but just reject all the network's good blocks.
 777 2011-09-25 07:13:25 <Toawa> but as I said, if you got each block from a different peer, you'll know quickly that one of them is going down the wrong path...
 778 2011-09-25 07:14:02 <gmaxwell> sure sure. that could be done, but its irrelevant. the network doesn't really have anything to do with the speed of syncup.
 779 2011-09-25 07:14:16 <Toawa> I know that now...
 780 2011-09-25 07:14:23 <Toawa> Well, understand
 781 2011-09-25 07:14:47 <gmaxwell> I syncup at ~the same speed across gigabit ethernet to an unloded -connect node as I do against the network.. though ssd or tmpfs makes a huge difference.
 782 2011-09-25 07:14:57 <gmaxwell> (like 30 minutes vs hours)
 783 2011-09-25 07:14:59 <Toawa> (But it'd have quite a big effect if that network were feeding you blocks from the one wrong node...)
 784 2011-09-25 07:15:08 <Toawa> were only feeding
 785 2011-09-25 07:16:14 <gmaxwell> another thing that makes syncup old is the number of pre .24 peers...
 786 2011-09-25 07:16:28 <gmaxwell> which will start randomly hanging up on nodes fetching the chain from them.
 787 2011-09-25 07:16:42 <Toawa> That certainly wouldn't help...
 788 2011-09-25 07:17:09 <gmaxwell> so you can end up losing all your peers during syncup... they come back up fast if you're on code past .21 but if you end up with more <.24 peers you'll just get disconnected again quickly.
 789 2011-09-25 07:17:48 <gmaxwell> (thus the /topic in here)
 790 2011-09-25 07:19:25 <Toawa> That reminds me... I suppose I should update...
 791 2011-09-25 07:20:15 <Toawa> Which reminds me... I wish the regular client incorporated some sort of key import ala pywallet...
 792 2011-09-25 07:21:03 cenuij has joined
 793 2011-09-25 07:21:05 <gmaxwell> import/export should be merged soon.
 794 2011-09-25 07:21:14 <Toawa> Glad to hear it.
 795 2011-09-25 07:22:05 Andrevan has quit ()
 796 2011-09-25 07:24:28 marf_away has joined
 797 2011-09-25 07:25:18 karnac has quit (Quit: karnac)
 798 2011-09-25 07:26:26 karnac has joined
 799 2011-09-25 07:27:12 KArmitt has quit ()
 800 2011-09-25 07:28:34 <Toawa> As a parting thought, another argument against the idea of a return address being "unnecessary data".  The system is set up (in theory) for all sorts of contracts; it says as much in the completeness of the op set available.  Those contracts are going to take up far more data space then return addresses ever will.. Return address is, say, 40 bytes.  That's less than an extra sig in two-sig...
 801 2011-09-25 07:28:36 <Toawa> ...setups.  If the system didn't want transactions deviating from the "official" type, it wouldn't provide for it.  That and we've just spent an hour+ talking about how to reduce space requirements.  This is the kind of thing that would add value to hybrid (not exclusively online) use, and isn't that the goal?  I must be going; goodnight.
 802 2011-09-25 07:31:07 <Toawa> (If you've ever returned something you bought with a credit card; you don't have to re-present the card to get the refund.  This kind of thing matters to brick & mortar businesses, who do occasionally have to give refunds.  This adds that possibility to Bitcoin.)
 803 2011-09-25 07:31:12 <gmaxwell> Toawa: I was being a bit more negative than justified. In 99.999% of the cases where someone might want a refund what you're suggesting is completely pointless.  A flag in the TXN might make sense in some, I agree.
 804 2011-09-25 07:31:35 abragin has joined
 805 2011-09-25 07:31:36 abragin has quit (Changing host)
 806 2011-09-25 07:31:36 abragin has joined
 807 2011-09-25 07:32:06 <Toawa> Indeed... But it's those .001% cases that you have to consider, and businesses will consider them.
 808 2011-09-25 07:32:43 <Toawa> But now I really must go.. Goodnight.
 809 2011-09-25 07:32:57 <gmaxwell> You can address what you're describing by asking for a refund address with the initial transaction.
 810 2011-09-25 07:33:00 <gmaxwell> night!
 811 2011-09-25 07:33:06 Toawa has left ()
 812 2011-09-25 07:35:30 Backburn has quit (Ping timeout: 248 seconds)
 813 2011-09-25 07:37:08 peck has quit (Ping timeout: 276 seconds)
 814 2011-09-25 07:37:24 Backburn has joined
 815 2011-09-25 07:40:13 peck has joined
 816 2011-09-25 07:44:40 <Lolcust> hello jgarzik ! Could you kindly help me out a bit ? I'm going to use (a mod of) your ref. CPU miner in a little side project, compiling from fedora succeeds, but on win the app crashes wtih error in pthreadGC2.dll. The downloaded "native" miner from your link dies the same fate (tested on : WinXP 32, WinXP64, Win 7 64). Could you please kindly take a look into this issue ?
 817 2011-09-25 07:45:41 Burgundy has joined
 818 2011-09-25 07:49:22 ThomasV has quit (Ping timeout: 248 seconds)
 819 2011-09-25 07:52:33 minimoose has quit (Quit: minimoose)
 820 2011-09-25 08:11:11 <Lolcust> oh, figured it out - jgarzik, that was a false alarm. Nice miner btw :-)
 821 2011-09-25 08:13:01 abragin has quit (Read error: Connection reset by peer)
 822 2011-09-25 08:13:09 dsg has quit (Ping timeout: 244 seconds)
 823 2011-09-25 08:13:20 abragin has joined
 824 2011-09-25 08:13:21 abragin has quit (Changing host)
 825 2011-09-25 08:13:21 abragin has joined
 826 2011-09-25 08:14:05 Joric has quit ()
 827 2011-09-25 08:15:16 dsg has joined
 828 2011-09-25 08:15:16 dsg has quit (Changing host)
 829 2011-09-25 08:15:16 dsg has joined
 830 2011-09-25 08:17:38 MrTiggrZzzz is now known as MrTiggrAFK
 831 2011-09-25 08:17:59 <dikidera> well, its obvious you need that dll lol
 832 2011-09-25 08:22:27 jimb0 has quit (Ping timeout: 244 seconds)
 833 2011-09-25 08:29:32 jimb0 has joined
 834 2011-09-25 08:31:22 `Jaka has quit ()
 835 2011-09-25 08:34:20 glitch-mod has quit (Read error: Connection reset by peer)
 836 2011-09-25 08:36:17 glitch-mod has joined
 837 2011-09-25 08:36:48 TransistOrg has quit (Remote host closed the connection)
 838 2011-09-25 08:37:03 TransistOrg has joined
 839 2011-09-25 08:37:14 Clipse has joined
 840 2011-09-25 08:50:06 abragin has quit (Read error: Connection reset by peer)
 841 2011-09-25 08:51:03 abragin has joined
 842 2011-09-25 08:51:03 abragin has quit (Changing host)
 843 2011-09-25 08:51:03 abragin has joined
 844 2011-09-25 08:54:56 cenuij has quit (Remote host closed the connection)
 845 2011-09-25 08:54:59 abragin has quit (Read error: No route to host)
 846 2011-09-25 08:55:07 ThomasV has joined
 847 2011-09-25 08:55:37 abragin has joined
 848 2011-09-25 08:55:37 abragin has quit (Changing host)
 849 2011-09-25 08:55:37 abragin has joined
 850 2011-09-25 08:55:38 Turingi has joined
 851 2011-09-25 08:56:56 Cokein has quit (Ping timeout: 240 seconds)
 852 2011-09-25 09:05:46 gjs278 has joined
 853 2011-09-25 09:06:21 <sipa> wow long conversation you guys had, gmaxwell
 854 2011-09-25 09:06:43 <[Tycho]> Hello.
 855 2011-09-25 09:08:46 maikmerten has joined
 856 2011-09-25 09:14:47 peck has quit (Ping timeout: 256 seconds)
 857 2011-09-25 09:19:06 <dikidera> hello tycho
 858 2011-09-25 09:19:52 peck has joined
 859 2011-09-25 09:30:06 mosi has joined
 860 2011-09-25 09:30:17 <dikidera> ugh..compiling bitcoin takes forever
 861 2011-09-25 09:30:55 cenuij has joined
 862 2011-09-25 09:30:55 cenuij has quit (Changing host)
 863 2011-09-25 09:30:55 cenuij has joined
 864 2011-09-25 09:36:36 cenuij has quit (Remote host closed the connection)
 865 2011-09-25 09:43:15 abragin has quit (Ping timeout: 276 seconds)
 866 2011-09-25 09:46:47 pecket has joined
 867 2011-09-25 09:46:56 peck has quit (Read error: Connection reset by peer)
 868 2011-09-25 09:47:09 Daniel0108 has joined
 869 2011-09-25 09:48:44 Cokein has joined
 870 2011-09-25 09:50:59 pecket has quit (Ping timeout: 248 seconds)
 871 2011-09-25 09:54:08 abragin has joined
 872 2011-09-25 09:54:08 abragin has quit (Changing host)
 873 2011-09-25 09:54:08 abragin has joined
 874 2011-09-25 09:56:07 peck has joined
 875 2011-09-25 09:57:34 larsivi has quit (Ping timeout: 260 seconds)
 876 2011-09-25 10:00:46 TD is now known as TD[gone]
 877 2011-09-25 10:08:51 kish is now known as putin
 878 2011-09-25 10:09:02 wolfspraul has joined
 879 2011-09-25 10:10:55 putin is now known as kish
 880 2011-09-25 10:17:26 AStove has joined
 881 2011-09-25 10:18:32 da2ce7 has quit (Ping timeout: 240 seconds)
 882 2011-09-25 10:18:48 da2ce7 has joined
 883 2011-09-25 10:19:16 peck has quit (Ping timeout: 245 seconds)
 884 2011-09-25 10:24:34 peck has joined
 885 2011-09-25 10:27:52 peck has quit (Read error: Connection reset by peer)
 886 2011-09-25 10:27:58 pecket has joined
 887 2011-09-25 10:39:16 shawn-p has quit ()
 888 2011-09-25 10:41:07 piotrp has joined
 889 2011-09-25 10:41:32 kish has quit (Quit: leaving)
 890 2011-09-25 10:43:58 datagutt has joined
 891 2011-09-25 10:45:47 asuk has joined
 892 2011-09-25 10:55:44 piotrp has quit (Quit: piotrp)
 893 2011-09-25 10:56:07 huk has quit ()
 894 2011-09-25 10:57:39 makomk has quit (Ping timeout: 258 seconds)
 895 2011-09-25 11:01:15 AnniGONE is now known as AnnihilaT
 896 2011-09-25 11:02:27 piotrp has joined
 897 2011-09-25 11:02:53 abragin has quit (Read error: No route to host)
 898 2011-09-25 11:03:13 abragin has joined
 899 2011-09-25 11:03:14 abragin has quit (Changing host)
 900 2011-09-25 11:03:14 abragin has joined
 901 2011-09-25 11:03:29  has quit (xerox!bnc@mythos.bot.nu|Ping timeout: 260 seconds)
 902 2011-09-25 11:15:59 piotrp has quit (Quit: piotrp)
 903 2011-09-25 11:16:51 copumpkin has quit (Ping timeout: 248 seconds)
 904 2011-09-25 11:17:18 copumpkin has joined
 905 2011-09-25 11:17:55 dikidera has quit (Ping timeout: 248 seconds)
 906 2011-09-25 11:18:05 diki has joined
 907 2011-09-25 11:18:31 diki is now known as Guest54240
 908 2011-09-25 11:20:17 TheAncientGoat has joined
 909 2011-09-25 11:22:18 wolfspraul has quit (Ping timeout: 256 seconds)
 910 2011-09-25 11:22:29 piotrp has joined
 911 2011-09-25 11:22:52 da2ce7 has quit (Read error: Connection reset by peer)
 912 2011-09-25 11:23:12 da2ce7 has joined
 913 2011-09-25 11:23:20 wolfspraul has joined
 914 2011-09-25 11:27:55 Sthebig has quit (Quit: /quit)
 915 2011-09-25 11:27:56 piotrp has quit (Quit: piotrp)
 916 2011-09-25 11:28:16 ThomasV has quit (Ping timeout: 255 seconds)
 917 2011-09-25 11:29:24 TheAncientGoat has quit (Quit: No Ping reply in 180 seconds.)
 918 2011-09-25 11:29:48 TheAncientGoat has joined
 919 2011-09-25 11:29:50 Sthebig has joined
 920 2011-09-25 11:31:43 TheAncientGoat has quit (Client Quit)
 921 2011-09-25 11:33:08 AnnihilaT is now known as AnniGONE
 922 2011-09-25 11:33:54 basti has joined
 923 2011-09-25 11:34:34 <basti> hey people
 924 2011-09-25 11:35:02 <basti> i'm getting an error like this: http://gcc.gnu.org/ml/gcc-help/2006-09/msg00322.html when I'm trying to compile the bitcoin client.
 925 2011-09-25 11:35:29 <basti> it's not obvious to me what to do now, I'd appreciate any help
 926 2011-09-25 11:38:28 <basti> it appears to have to do with conflicting "const" declarations
 927 2011-09-25 11:40:35 abragin has quit (Read error: Connection reset by peer)
 928 2011-09-25 11:41:12 abragin has joined
 929 2011-09-25 11:41:12 abragin has quit (Changing host)
 930 2011-09-25 11:41:12 abragin has joined
 931 2011-09-25 11:41:18 ThomasV has joined
 932 2011-09-25 11:42:29 <sipa> basti: could you put the actual error message somewhat?
 933 2011-09-25 11:42:53 <basti> sure
 934 2011-09-25 11:43:25 <basti> http://pastebin.com/y6UfS7BW sipa there you go :)
 935 2011-09-25 11:44:33 <sipa> which version wx are you using?
 936 2011-09-25 11:48:01 rdponticelli has joined
 937 2011-09-25 11:48:08 abragin has quit (Read error: Connection reset by peer)
 938 2011-09-25 11:48:16 abragin has joined
 939 2011-09-25 11:49:38 <basti> sipa: hmm, wx-config says 2.8.10
 940 2011-09-25 11:49:52 <sipa> bitcoin's UI requires wx 2.9
 941 2011-09-25 11:50:37 <basti> oh okay.
 942 2011-09-25 11:50:47 <basti> can i leave out the UI somehow?
 943 2011-09-25 11:50:51 <basti> it's on a server anyway
 944 2011-09-25 11:50:56 da2ce7 has quit (Ping timeout: 240 seconds)
 945 2011-09-25 11:50:57 <sipa> if you just compile bitcoind, tes
 946 2011-09-25 11:51:01 <sipa> *yes
 947 2011-09-25 11:51:07 <basti> how do i do that make ... bitcoind?
 948 2011-09-25 11:51:17 <sipa> make -f makefile.unix bitcoind
 949 2011-09-25 11:51:17 da2ce7 has joined
 950 2011-09-25 11:51:32 <basti> okay.
 951 2011-09-25 11:51:35 <basti> that appears to work ;)
 952 2011-09-25 11:51:43 <Guest54240> compiling takes time
 953 2011-09-25 11:51:51 <Guest54240> for me sometimes around 10 for a full rebuild
 954 2011-09-25 11:51:56 <Guest54240> 10 minutes*
 955 2011-09-25 11:53:04 <basti> apparently i triggered some anti-spam device on blockexplorer.com with a foolish script
 956 2011-09-25 11:54:42 abragin has quit (Read error: No route to host)
 957 2011-09-25 11:55:24 abragin has joined
 958 2011-09-25 11:55:24 abragin has quit (Changing host)
 959 2011-09-25 11:55:24 abragin has joined
 960 2011-09-25 11:58:48 <Guest54240> what was the message?
 961 2011-09-25 11:59:11 <Guest54240> last time i used the site i looped over 10,000 public keys and had no problems
 962 2011-09-25 11:59:26 <Guest54240> though i did stop the script at some point as it was slow
 963 2011-09-25 12:04:06 abragin has quit ()
 964 2011-09-25 12:04:17 larsivi has joined
 965 2011-09-25 12:04:18 larsivi has quit (Read error: Connection reset by peer)
 966 2011-09-25 12:05:49 makomk has joined
 967 2011-09-25 12:06:26 Guest54240 is now known as diki
 968 2011-09-25 12:10:02 bobke_ is now known as bobke
 969 2011-09-25 12:13:12 <basti> ok i got it :)
 970 2011-09-25 12:13:20 <basti> diki: let me look it up
 971 2011-09-25 12:14:25 <basti> diki: "failed to open stream: Connection refused"
 972 2011-09-25 12:20:23 iocor has joined
 973 2011-09-25 12:21:45 DrHaribo has joined
 974 2011-09-25 12:23:22 <diki> this on the browser or?
 975 2011-09-25 12:25:51 samthetechie has left ()
 976 2011-09-25 12:33:42 EvanR has quit (Ping timeout: 256 seconds)
 977 2011-09-25 12:35:42 EvanR has joined
 978 2011-09-25 12:36:08 EvanR is now known as Guest32657
 979 2011-09-25 12:39:32 Lopuz has joined
 980 2011-09-25 12:50:59 sytse has joined
 981 2011-09-25 12:52:20 [Tycho] has quit (Ping timeout: 248 seconds)
 982 2011-09-25 13:04:57 [Tycho] has joined
 983 2011-09-25 13:05:32 abragin has joined
 984 2011-09-25 13:05:32 abragin has quit (Changing host)
 985 2011-09-25 13:05:32 abragin has joined
 986 2011-09-25 13:06:14 [Tycho] has quit (Changing host)
 987 2011-09-25 13:06:14 [Tycho] has joined
 988 2011-09-25 13:08:18 SomeoneWeird is now known as SomeoneWeirdAFK
 989 2011-09-25 13:15:50 [Tycho] has quit (Ping timeout: 255 seconds)
 990 2011-09-25 13:23:50 Diablo-D3 has joined
 991 2011-09-25 13:34:36 amtal has quit (Quit: segfault)
 992 2011-09-25 13:36:10 zeiris has joined
 993 2011-09-25 13:40:02 p0s has joined
 994 2011-09-25 13:44:11 t3a has quit (Ping timeout: 255 seconds)
 995 2011-09-25 13:45:12 enquirer_ has joined
 996 2011-09-25 13:48:00 enquirer has quit (Ping timeout: 260 seconds)
 997 2011-09-25 13:48:02 enquirer_ is now known as enquirer
 998 2011-09-25 13:48:03 p0s has quit (Read error: No route to host)
 999 2011-09-25 13:50:12 Turingi has quit (Read error: Connection reset by peer)
1000 2011-09-25 13:50:12 ThomasV has quit (Ping timeout: 256 seconds)
1001 2011-09-25 13:50:23 p0s has joined
1002 2011-09-25 13:50:34 normanrichards has quit (Quit: normanrichards)
1003 2011-09-25 13:53:31 Turingi has joined
1004 2011-09-25 13:59:13 normanrichards has joined
1005 2011-09-25 13:59:26 abragin has quit (Read error: No route to host)
1006 2011-09-25 13:59:52 abragin has joined
1007 2011-09-25 13:59:52 abragin has quit (Changing host)
1008 2011-09-25 13:59:52 abragin has joined
1009 2011-09-25 14:03:05 Cokein has quit (Quit: ChatZilla 0.9.87 [Firefox 6.0.1/20110830092941])
1010 2011-09-25 14:04:00 Kardos_ has joined
1011 2011-09-25 14:05:08 E-sense has quit (Quit: System.exit(0);)
1012 2011-09-25 14:05:10 abragin has quit (Read error: Connection reset by peer)
1013 2011-09-25 14:06:22 Kardos__ has quit (Ping timeout: 245 seconds)
1014 2011-09-25 14:06:29 b4epoche_ has quit (Read error: Connection reset by peer)
1015 2011-09-25 14:07:03 abragin has joined
1016 2011-09-25 14:07:04 abragin has quit (Changing host)
1017 2011-09-25 14:07:04 abragin has joined
1018 2011-09-25 14:09:03 rdponticelli has quit (Read error: Connection reset by peer)
1019 2011-09-25 14:11:46 abragin has quit (Read error: Connection reset by peer)
1020 2011-09-25 14:12:57 abragin has joined
1021 2011-09-25 14:14:15 b4epoche_ has joined
1022 2011-09-25 14:14:20 abragin has quit (Read error: Connection reset by peer)
1023 2011-09-25 14:15:18 abragin has joined
1024 2011-09-25 14:15:19 abragin has quit (Changing host)
1025 2011-09-25 14:15:19 abragin has joined
1026 2011-09-25 14:15:26 rdponticelli has joined
1027 2011-09-25 14:18:10 b4epoche_ has quit (Client Quit)
1028 2011-09-25 14:18:13 normanrichards has quit (Ping timeout: 276 seconds)
1029 2011-09-25 14:18:25 melvster has joined
1030 2011-09-25 14:22:42 normanrichards has joined
1031 2011-09-25 14:23:14 erus` has joined
1032 2011-09-25 14:25:33 Fuehrer has joined
1033 2011-09-25 14:25:33 Fuehrer has quit (Changing host)
1034 2011-09-25 14:25:33 Fuehrer has joined
1035 2011-09-25 14:25:53 abragin has quit (Read error: No route to host)
1036 2011-09-25 14:30:00 Cokein has joined
1037 2011-09-25 14:33:50 normanrichards has quit (Ping timeout: 256 seconds)
1038 2011-09-25 14:42:37 Fuehrer has quit (Read error: Connection reset by peer)
1039 2011-09-25 14:42:42 wboy1 has joined
1040 2011-09-25 14:42:45 SomeoneWeirdAFK is now known as SomeoneWeird
1041 2011-09-25 14:43:07 Cokein has quit (Quit: Sto andando via)
1042 2011-09-25 14:43:44 abragin has joined
1043 2011-09-25 14:43:45 abragin has quit (Changing host)
1044 2011-09-25 14:43:45 abragin has joined
1045 2011-09-25 14:43:56 iocor has quit (Quit: Computer has gone to sleep.)
1046 2011-09-25 14:44:33 RazielZ has joined
1047 2011-09-25 14:44:34 Kolky has joined
1048 2011-09-25 14:45:06 Cokein has joined
1049 2011-09-25 14:53:04 twmz has joined
1050 2011-09-25 14:58:03 Guest32657 is now known as EvanR
1051 2011-09-25 14:58:08 EvanR has quit (Changing host)
1052 2011-09-25 14:58:08 EvanR has joined
1053 2011-09-25 15:00:29 manifold has joined
1054 2011-09-25 15:04:36 Lopuz has quit (Ping timeout: 248 seconds)
1055 2011-09-25 15:05:25 p0s has quit (Remote host closed the connection)
1056 2011-09-25 15:07:27 karnac has quit (Quit: karnac)
1057 2011-09-25 15:10:11 karnac has joined
1058 2011-09-25 15:14:49 manifold has quit (Remote host closed the connection)
1059 2011-09-25 15:24:30 Fuehrer has joined
1060 2011-09-25 15:24:31 Fuehrer has quit (Changing host)
1061 2011-09-25 15:24:31 Fuehrer has joined
1062 2011-09-25 15:25:09 abragin has quit (Read error: No route to host)
1063 2011-09-25 15:25:22 Fuehrer is now known as abragin
1064 2011-09-25 15:30:15 abragin has quit ()
1065 2011-09-25 15:33:30 chinaskibit has quit (Remote host closed the connection)
1066 2011-09-25 15:35:10 Nightblade has joined
1067 2011-09-25 15:42:21 karnac has quit (Quit: karnac)
1068 2011-09-25 15:50:19 minimoose has joined
1069 2011-09-25 15:51:38 SomeoneWeird is now known as SomeoneWeirdzzzz
1070 2011-09-25 15:51:41 Zarutian has joined
1071 2011-09-25 15:53:19 t3a has joined
1072 2011-09-25 15:53:25 wpl has quit (Ping timeout: 260 seconds)
1073 2011-09-25 15:54:19 chinaskibit has joined
1074 2011-09-25 15:54:24 AStove has quit ()
1075 2011-09-25 15:55:21 wpl has joined
1076 2011-09-25 15:57:55 MrTiggrAFK is now known as MrTiggr
1077 2011-09-25 16:02:10 Veladon has joined
1078 2011-09-25 16:02:48 Veladon has quit (Client Quit)
1079 2011-09-25 16:09:21 karnac has joined
1080 2011-09-25 16:11:29 Cusipzzz has joined
1081 2011-09-25 16:13:31 sgornick has joined
1082 2011-09-25 16:36:20 kish has joined
1083 2011-09-25 16:41:51 zeiris has quit (Ping timeout: 260 seconds)
1084 2011-09-25 16:53:40 minimoose has quit (Quit: minimoose)
1085 2011-09-25 16:54:22 normanrichards has joined
1086 2011-09-25 16:58:58 cjdelisl1 is now known as cjdelisle
1087 2011-09-25 17:04:38 abragin has joined
1088 2011-09-25 17:05:07 minimoose has joined
1089 2011-09-25 17:05:27 MrTiggr is now known as MrTiggrZZZzzz
1090 2011-09-25 17:05:43 maikmerten has quit (Ping timeout: 256 seconds)
1091 2011-09-25 17:06:18 mosi has quit (bed!~mos@hooooooooooooooooooooooooooooooge.dongs.dtegaming.com|Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
1092 2011-09-25 17:09:06 TheAncientGoat has joined
1093 2011-09-25 17:12:00 normanrichards has quit (Quit: normanrichards)
1094 2011-09-25 17:12:21 Titeuf_87 has joined
1095 2011-09-25 17:18:39 iocor has joined
1096 2011-09-25 17:20:12 zeiris has joined
1097 2011-09-25 17:20:56 Clipse has quit (Ping timeout: 260 seconds)
1098 2011-09-25 17:24:33 tower has quit (Disconnected by services)
1099 2011-09-25 17:24:49 tower has joined
1100 2011-09-25 17:29:23 ThomasV has joined
1101 2011-09-25 17:33:15 d33tah has quit (Ping timeout: 255 seconds)
1102 2011-09-25 17:34:38 TD[gone] is now known as TD
1103 2011-09-25 17:35:05 d33tah has joined
1104 2011-09-25 17:35:19 jimb0 has quit (Ping timeout: 244 seconds)
1105 2011-09-25 17:38:38 MC1984 has quit (Read error: Connection reset by peer)
1106 2011-09-25 17:38:55 MC1984 has joined
1107 2011-09-25 17:41:22 clr_ has joined
1108 2011-09-25 17:42:02 piotrp has joined
1109 2011-09-25 17:42:25 jimb0 has joined
1110 2011-09-25 17:46:29 AStove has joined
1111 2011-09-25 17:48:17 <casascius> Toawa's refund proposal could be implemented with a single bit flag or an extra pseudo-op in the transaction that simply means: "Transaction output #0 is the refund address".  And then re-sort the transaction so the change address (which will probably already be there taking up space anyway) is in spot #0 (adding a 0.00 output there if it's not)
1112 2011-09-25 17:49:50 Tracker- has quit (Read error: Connection reset by peer)
1113 2011-09-25 17:49:56 <casascius> Another way to accomplish the flagging without actually needing to take up flag space, would be to pay a transaction fee (to a miner) with a very unusual prefix that is unlikely to be duplicated by accident.
1114 2011-09-25 17:50:00 Tracker has joined
1115 2011-09-25 17:50:20 <casascius> e.g. a fee like 0.01002842 or 0.00502842 or any fee with 2842 as its least significant digits
1116 2011-09-25 17:50:36 <casascius> *prefix -> suffix
1117 2011-09-25 17:51:50 <luke-jr> casascius: and how about when the refund address doesn't have any coins to send?
1118 2011-09-25 17:52:17 <luke-jr> oh, output, nm
1119 2011-09-25 17:52:26 <casascius> luke-jr: the refund address would be one output not input
1120 2011-09-25 17:52:31 <casascius> the change output
1121 2011-09-25 17:52:39 <luke-jr> still
1122 2011-09-25 17:52:50 <luke-jr> kinda abuse of the block chain
1123 2011-09-25 17:52:55 <luke-jr> like embedded messages
1124 2011-09-25 17:53:08 <luke-jr> no reason you can't provide refund address out of band
1125 2011-09-25 17:53:11 Moonies has joined
1126 2011-09-25 17:53:20 <casascius> how would it be abuse?  if it has a zero resource cost and a legitimate business use then why would that be abuse?
1127 2011-09-25 17:53:34 <casascius> there will already be a change address
1128 2011-09-25 17:53:43 <luke-jr> it does have resource cost; an extra output
1129 2011-09-25 17:53:48 <luke-jr> sometimes
1130 2011-09-25 17:54:00 <luke-jr> other times, it might not be needed
1131 2011-09-25 17:54:56 <casascius> For a legitimate business purpose, I wouldn't object.... (I would be more bothered by, say, coinbase transaction that split the block reward into bitcent fragments =) ) only because they are larger in size and are a cascading resource burden when those fragments are spent
1132 2011-09-25 17:55:30 <casascius> I don't know if you saw my comment on the forums, but I thought it funny to point out that:
1133 2011-09-25 17:55:39 <luke-jr> out-of-band has much more potential IMO
1134 2011-09-25 17:55:59 <casascius> for a block chain that repeatedly tells you "god does not exist", the block chain sure contains the word "G0D" a lot (byte sequence 0x47 0x30 0x44)
1135 2011-09-25 17:56:36 <casascius> (it appears anytime a scriptsig starts with 0x30 0x44)
1136 2011-09-25 17:56:57 <casascius> out-of-band has unlimited potential by definition
1137 2011-09-25 18:05:30 <forrestv> casascius, it's difficult to do secure decentralized bitcoin transactions out of band :p
1138 2011-09-25 18:06:08 <casascius> lol agreed
1139 2011-09-25 18:09:04 Lopuz has joined
1140 2011-09-25 18:10:03 da2ce7 has quit (Remote host closed the connection)
1141 2011-09-25 18:11:07 danbri has joined
1142 2011-09-25 18:13:02 piotrp has quit (Quit: piotrp)
1143 2011-09-25 18:14:07 da2ce7 has joined
1144 2011-09-25 18:15:51 danbri has quit (Remote host closed the connection)
1145 2011-09-25 18:19:06 WildSoil has quit ()
1146 2011-09-25 18:22:37 E-sense has joined
1147 2011-09-25 18:24:22 caedes has joined
1148 2011-09-25 18:24:22 caedes has quit (Changing host)
1149 2011-09-25 18:24:22 caedes has joined
1150 2011-09-25 18:27:12 tyn has joined
1151 2011-09-25 18:27:38 TheAncientGoat has quit (Ping timeout: 245 seconds)
1152 2011-09-25 18:35:35 piotrp has joined
1153 2011-09-25 18:44:43 p0s has joined
1154 2011-09-25 18:44:50 p0s has quit (Changing host)
1155 2011-09-25 18:44:50 p0s has joined
1156 2011-09-25 18:46:53 tyn has quit (Quit: Leaving)
1157 2011-09-25 18:48:26 Etlase has quit (Ping timeout: 260 seconds)
1158 2011-09-25 18:48:32 Etlase has joined
1159 2011-09-25 18:49:32 huk has joined
1160 2011-09-25 18:51:09 TD is now known as TD[gone]
1161 2011-09-25 18:53:57 rdponticelli has quit (Ping timeout: 248 seconds)
1162 2011-09-25 18:55:05 realazthat has quit (Quit: Ex-Chat)
1163 2011-09-25 18:57:44 larsivi has joined
1164 2011-09-25 18:57:52 RazielZ has quit (Quit: Leaving)
1165 2011-09-25 18:58:02 rdponticelli has joined
1166 2011-09-25 19:08:34 da2ce7 has quit (Ping timeout: 240 seconds)
1167 2011-09-25 19:09:12 iocor has quit (Quit: Computer has gone to sleep.)
1168 2011-09-25 19:11:23 Zarutian has quit (Ping timeout: 276 seconds)
1169 2011-09-25 19:16:42 Zarutian has joined
1170 2011-09-25 19:20:46 melvster1 has joined
1171 2011-09-25 19:24:01 melvster has quit (Ping timeout: 260 seconds)
1172 2011-09-25 19:34:14 clr_ is now known as c00w
1173 2011-09-25 19:39:41 normanrichards has joined
1174 2011-09-25 19:39:56 dbosk has joined
1175 2011-09-25 19:40:01 Lolcust has quit (Quit: Oh shi...)
1176 2011-09-25 19:41:37 Kohree has joined
1177 2011-09-25 19:41:54 Cory has quit (Disconnected by services)
1178 2011-09-25 19:42:00 Kohree is now known as Cory
1179 2011-09-25 19:42:08 mercora has quit (Read error: Operation timed out)
1180 2011-09-25 19:42:11 Cory has quit (Changing host)
1181 2011-09-25 19:42:11 Cory has joined
1182 2011-09-25 19:42:14 mercora has joined
1183 2011-09-25 19:42:45 Kardos_ has quit (Read error: Operation timed out)
1184 2011-09-25 19:43:19 Kardos_ has joined
1185 2011-09-25 19:47:16 dbosk has quit (Quit: leaving)
1186 2011-09-25 19:50:07 EPiSKiNG has quit ()
1187 2011-09-25 19:50:39 Lolcust has joined
1188 2011-09-25 19:53:41 normanrichards has quit (Ping timeout: 248 seconds)
1189 2011-09-25 20:00:06 <topi`> if the just recently found block did not include my payment, does it mean my txfee was too low?
1190 2011-09-25 20:00:28 sipa has quit (Ping timeout: 260 seconds)
1191 2011-09-25 20:00:51 <nanotube> topi`: depends on the timing, and whether the tx was 'standard'
1192 2011-09-25 20:01:20 <nanotube> (i.e., it could have just not made it into the block because you sent very shortly before it was found, or could have failed to relay across the network because it failed the isStandard check)
1193 2011-09-25 20:01:24 <topi`> i guess it depends on the individual or pool who found the block?
1194 2011-09-25 20:01:50 <topi`> what's the isStandard check?
1195 2011-09-25 20:02:18 <gmaxwell> The bitcoin software shouldn't allow you send a txn with a txfee which is too low to actually work.
1196 2011-09-25 20:02:26 <gmaxwell> So unless you modified it, thats not your issue.
1197 2011-09-25 20:02:51 <gmaxwell> topi`: some miners have randomish rules.  Your txn also might no thave made it to that miner by the time they prepared that block for solving.
1198 2011-09-25 20:04:10 <topi`> so, should I resend or wait?
1199 2011-09-25 20:06:10 datagutt has quit (Quit: kthxbai)
1200 2011-09-25 20:10:37 <gmaxwell> Are you running a current unmodified version of bitcoin?
1201 2011-09-25 20:10:47 <gmaxwell> If so, just leave it running and wait. Your txn will go through.
1202 2011-09-25 20:12:26 c00w has quit (Ping timeout: 260 seconds)
1203 2011-09-25 20:12:55 asuk has quit (Quit: Lost terminal)
1204 2011-09-25 20:16:37 <topi`> yes, unmodified. now I can see it on the newest block.
1205 2011-09-25 20:16:42 <topi`> it took 3 blocks to show up.
1206 2011-09-25 20:17:03 <topi`> I wonder who minted that block
1207 2011-09-25 20:18:39 manveru has quit (Quit: ZNC - http://znc.sourceforge.net)
1208 2011-09-25 20:19:20 <diki> it was me
1209 2011-09-25 20:20:09 pwrcycle has quit (Ping timeout: 245 seconds)
1210 2011-09-25 20:21:10 pwrcycle has joined
1211 2011-09-25 20:25:20 <CIA-101> bitcoinj: hearn@google.com * r223 /wiki/UsingMaven.wiki: Edited wiki page UsingMaven through web user interface.
1212 2011-09-25 20:25:29 manveru has joined
1213 2011-09-25 20:25:38 normanrichards has joined
1214 2011-09-25 20:33:08 c00w has joined
1215 2011-09-25 20:34:43 magn3ts has quit (Read error: Connection reset by peer)
1216 2011-09-25 20:35:12 sacarlson has quit (Ping timeout: 260 seconds)
1217 2011-09-25 20:39:32 Clipse has joined
1218 2011-09-25 20:40:55 ThomasV has quit (Ping timeout: 255 seconds)
1219 2011-09-25 20:42:24 <CIA-101> bitcoinj: hearn@google.com * r224 /trunk/pom.xml:
1220 2011-09-25 20:42:24 <CIA-101> bitcoinj: Patch from Gary and Jonny to switch the Maven config to a new Nexus-based build
1221 2011-09-25 20:42:24 <CIA-101> bitcoinj: server. Changes how SLF44J is imported to avoid forcing a particular
1222 2011-09-25 20:42:24 <CIA-101> bitcoinj: implementation on the user. Remove redundant or unnecessary parts of the POM.
1223 2011-09-25 20:45:05 Nightblade has quit (Quit: Computer has gone to sleep.)
1224 2011-09-25 20:45:12 piotrp has quit (Quit: piotrp)
1225 2011-09-25 20:49:36 sacarlson has joined
1226 2011-09-25 20:53:45 Titeuf_87 has quit (Quit: Ex-Chat)
1227 2011-09-25 20:58:26 b4epoche_ has joined
1228 2011-09-25 20:59:25 c00w has quit (Ping timeout: 244 seconds)
1229 2011-09-25 21:01:24 b4epoch__ has joined
1230 2011-09-25 21:02:10 TD[gone] is now known as TD
1231 2011-09-25 21:02:49 devrandom has joined
1232 2011-09-25 21:03:02 b4epoche_ has quit (Ping timeout: 248 seconds)
1233 2011-09-25 21:03:16 Daniel0108 has quit (Read error: Operation timed out)
1234 2011-09-25 21:04:19 Etlase has quit (Ping timeout: 255 seconds)
1235 2011-09-25 21:05:41 Etlase has joined
1236 2011-09-25 21:07:52 normanrichards has quit (Ping timeout: 260 seconds)
1237 2011-09-25 21:10:09 Etlase has quit (Ping timeout: 245 seconds)
1238 2011-09-25 21:10:15 Etlase has joined
1239 2011-09-25 21:13:53 _Burgundy has joined
1240 2011-09-25 21:14:20 erle- has joined
1241 2011-09-25 21:14:34 Etlase has quit (Read error: Connection reset by peer)
1242 2011-09-25 21:15:00 Blitzboom_ has joined
1243 2011-09-25 21:15:00 Etlase has joined
1244 2011-09-25 21:15:34 Burgundy has quit (Ping timeout: 255 seconds)
1245 2011-09-25 21:16:01 AlonzoTG has quit (Ping timeout: 255 seconds)
1246 2011-09-25 21:16:28 newsbad_com has quit (Ping timeout: 255 seconds)
1247 2011-09-25 21:16:50 _W_ has quit (Excess Flood)
1248 2011-09-25 21:17:22 AlonzoTG has joined
1249 2011-09-25 21:17:22 Blitzboom has quit (Ping timeout: 255 seconds)
1250 2011-09-25 21:17:30 newsbad_com has joined
1251 2011-09-25 21:17:41 _W has joined
1252 2011-09-25 21:18:06 casascius has quit (Ping timeout: 252 seconds)
1253 2011-09-25 21:20:42 vsrinivas has quit (Ping timeout: 260 seconds)
1254 2011-09-25 21:25:08 AStove has quit ()
1255 2011-09-25 21:25:36 Gonzago has joined
1256 2011-09-25 21:26:04 Gonzago has left ()
1257 2011-09-25 21:29:25 _W is now known as _W_
1258 2011-09-25 21:30:32 Beremat has quit (Read error: Connection reset by peer)
1259 2011-09-25 21:30:49 Andrevan has joined
1260 2011-09-25 21:30:49 Andrevan has quit (Changing host)
1261 2011-09-25 21:30:49 Andrevan has joined
1262 2011-09-25 21:31:10 gjs278 has quit (Read error: Connection reset by peer)
1263 2011-09-25 21:31:54 Beremat has joined
1264 2011-09-25 21:35:49 sipa1024 has joined
1265 2011-09-25 21:37:42 marf_away has quit (Ping timeout: 248 seconds)
1266 2011-09-25 21:38:36 sipa1024 is now known as sipa
1267 2011-09-25 21:40:41 wood has quit (Quit: Leave me alone. kthx)
1268 2011-09-25 21:41:09 wood has joined
1269 2011-09-25 21:41:16 [Tycho] has joined
1270 2011-09-25 21:42:41 [Tycho] has quit (Changing host)
1271 2011-09-25 21:42:41 [Tycho] has joined
1272 2011-09-25 21:46:06 da2ce7 has joined
1273 2011-09-25 21:46:13 slds has joined
1274 2011-09-25 21:47:07 c00w has joined
1275 2011-09-25 21:47:35 BigTimeCoin has quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
1276 2011-09-25 21:47:36 Andrevan has quit ()
1277 2011-09-25 21:48:05 SomeoneWeirdzzzz is now known as SomeoneWeird
1278 2011-09-25 21:50:15 drewn has quit (Read error: Connection reset by peer)
1279 2011-09-25 22:08:04 iocor has joined
1280 2011-09-25 22:09:39 b4epoch__ has quit (Quit: Computer has gone to sleep.)
1281 2011-09-25 22:12:58 b4epoche_ has joined
1282 2011-09-25 22:13:06 pickett has quit (Remote host closed the connection)
1283 2011-09-25 22:13:15 num1 has joined
1284 2011-09-25 22:17:23 AStove has joined
1285 2011-09-25 22:17:49 pickett has joined
1286 2011-09-25 22:22:06 TD is now known as TD[gone]
1287 2011-09-25 22:25:02 mosi has joined
1288 2011-09-25 22:26:11 mosi is now known as bed!~mos@hooooooooooooooooooooooooooooooge.dongs.dtegaming.com|mosimo
1289 2011-09-25 22:26:51 slds has quit (Read error: Connection reset by peer)
1290 2011-09-25 22:27:20 slds has joined
1291 2011-09-25 22:28:08 slds has quit (Client Quit)
1292 2011-09-25 22:28:46 abragin has quit ()
1293 2011-09-25 22:29:58 sgornick has quit (Ping timeout: 248 seconds)
1294 2011-09-25 22:31:07 Andrevan has joined
1295 2011-09-25 22:45:01 wolfspraul has quit (Quit: leaving)
1296 2011-09-25 22:48:32 Moonies has quit (Quit: quack)
1297 2011-09-25 22:48:38 sshc has quit (Ping timeout: 248 seconds)
1298 2011-09-25 22:49:23 Moonies has joined
1299 2011-09-25 22:51:50 c00w has quit (Ping timeout: 248 seconds)
1300 2011-09-25 22:55:11 vsrinivas has joined
1301 2011-09-25 23:07:35 Nebuluz has joined
1302 2011-09-25 23:15:23 AStove has quit ()
1303 2011-09-25 23:21:38 erus` has quit (Remote host closed the connection)
1304 2011-09-25 23:23:01 iocor has quit (Quit: Computer has gone to sleep.)
1305 2011-09-25 23:25:29 caedes has quit (Remote host closed the connection)
1306 2011-09-25 23:26:33 Toawa has joined
1307 2011-09-25 23:28:03 osmosis has joined
1308 2011-09-25 23:28:43 mosimo has quit (Read error: Connection reset by peer)
1309 2011-09-25 23:28:46 <Toawa> Actually, OOB was the first thing I thought of; I thought of the refund mechanism specifically for cases where OOB was infeasible or costly (not just in terms of money, but time and customer interaction.  I had brick-and-mortar transactions in mind when I thought of it.  Casacius's flag idea is functionally identical and better from a space perspective, though.
1310 2011-09-25 23:29:36 <gmaxwell> Toawa: you need some way of transfering information about the transaction in order to identify it it.
1311 2011-09-25 23:29:52 <Toawa> Hmm?
1312 2011-09-25 23:30:14 <sipa> Toawa:, g
1313 2011-09-25 23:30:20 <gmaxwell> You have to tell me where to send my payment, this means we already have a communications channel.
1314 2011-09-25 23:31:04 <sipa> Toawa, gmaxwell: have you seen my proposal for a payment protocol?
1315 2011-09-25 23:31:19 <gmaxwell> I saw that you had one, didn't look into to the protocol itself.
1316 2011-09-25 23:31:29 <Toawa> Indeed.  However, (semi-)automatically including a single bit in your transaction to them is much less costly in terms of time and customer interaction than having to ask for a refund address manually.
1317 2011-09-25 23:31:41 <Toawa> No, I haven't.. Link?
1318 2011-09-25 23:31:44 <gmaxwell> There isn't anything manual required.
1319 2011-09-25 23:32:25 <Toawa> How wouldn't there be anything manual required?
1320 2011-09-25 23:32:55 c00w has joined
1321 2011-09-25 23:34:07 <gmaxwell> How would anything manual be required?  The seller asks you to make a payment. Your humdinger pops up a dialog asking if you want to pay (hopefully asking for a password too), and then it responds to the vendor with a copy of the relevant transaction paying the vendor.  It's utterly trivial to completely automatically tag on "and my refund address is X" to that response.
1322 2011-09-25 23:34:24 <sipa> https://gist.github.com/1237788
1323 2011-09-25 23:34:27 iocor has joined
1324 2011-09-25 23:34:30 erle- has quit (Quit: CETERVM•AVTEM•CENSEO•FDP•ESSE•DELENDVM)
1325 2011-09-25 23:34:41 basti has quit (Quit: und kein schwein hängt am kreuz...)
1326 2011-09-25 23:34:49 <Toawa> That assumes a direct communications channel between your device and the seller.
1327 2011-09-25 23:34:59 <gmaxwell> Toawa: there already _must_ be one.
1328 2011-09-25 23:35:04 gjs278 has joined
1329 2011-09-25 23:35:08 <Toawa> Not a bidirectional one.
1330 2011-09-25 23:35:32 <gmaxwell> A unidirectional one isn't very useful, how would he ever know that you paid him.
1331 2011-09-25 23:35:40 <Toawa> Transaction monitoring.
1332 2011-09-25 23:35:48 <gmaxwell> Then you have bidirectional communication.
1333 2011-09-25 23:35:50 <Toawa> W/ unique payment address
1334 2011-09-25 23:35:55 <Toawa> Not directly.
1335 2011-09-25 23:36:14 <Toawa> And such systems are already being used, FWIH.
1336 2011-09-25 23:36:43 <Toawa> The channel is Seller -> Your Device -> Transaction cloud -> Seller
1337 2011-09-25 23:36:47 <gmaxwell> You're stipulating a weird situation where both parties have internet access but can't actually communicate except by spamming the blockchain with more immortal data. Thats broken, don't do that.
1338 2011-09-25 23:37:16 <gmaxwell> Thats a bad design because the seller has no control over the transaction propagation at all. It'll result in bad user expirence.
1339 2011-09-25 23:37:21 <Toawa> Right now, the only spamming into the block chain that's happening as I describe, is the addition of a new transaction.
1340 2011-09-25 23:37:37 <Toawa> I'm not the one that designed it; I'm only describing what I've heard is actually how it's being used.
1341 2011-09-25 23:37:51 <gmaxwell> The transmission of the target address _can not_ be done reliably without two way communication, otherwise how would you know to resend if the communication was corrupted?
1342 2011-09-25 23:38:10 <sipa> Toawa: read my proposal :)
1343 2011-09-25 23:38:16 <gmaxwell> I think you've misunderstood what is being done, and/or those things are broken. :)
1344 2011-09-25 23:38:18 <Toawa> Your device has a camera, scans in a QR code with the target address.
1345 2011-09-25 23:38:37 irf has joined
1346 2011-09-25 23:38:42 <lfm> what device doesnt have a camera these days?
1347 2011-09-25 23:38:58 <sipa> and internet access
1348 2011-09-25 23:38:58 <Toawa> My iPad; but I've never used it for a transaction...
1349 2011-09-25 23:39:03 <gmaxwell> Toawa: a printed QR code is not a unique payment address
1350 2011-09-25 23:39:34 <lfm> your ipad is obsolete. I said these days
1351 2011-09-25 23:39:40 <Toawa> There's no reason it can't be.  QR codes aren't hard to print, and they're going to be printing receipts, anyway
1352 2011-09-25 23:39:50 <Toawa> I got it two months before the new one came out :|
1353 2011-09-25 23:40:41 osmosis has quit (Quit: Leaving)
1354 2011-09-25 23:40:56 <Toawa> This is specifically the model I had in mind when I came up with the idea: https://bit-pay.com/aboutMobile.html
1355 2011-09-25 23:41:57 <gmaxwell> "Both mobile phones must be able to access the internet." < meaning they have two way communication, via some way or another. There is no reason to use immortal storage for their two way dialog.
1356 2011-09-25 23:42:05 <Toawa> I admit I've never used them in a B&M setting; I was working hypothetically.
1357 2011-09-25 23:42:21 <Toawa> They have two way communication with the internet, not necessarily with eachother.
1358 2011-09-25 23:43:07 <Toawa> Indeed, it's rather unlikely that they would have direct comms as you imagine; it would mean handing out your phone# to every merchant you do business with.
1359 2011-09-25 23:43:21 <sipa> you have a very corrupted view of the internet then
1360 2011-09-25 23:43:32 <gmaxwell> Toawa: if you have communication with the internet you have communication with each other. Communication doesn't mean direct. You're willing to accept indirection via the globally visible non-private blockchain, why not accept indirection via something else.
1361 2011-09-25 23:44:19 c00w has quit (Ping timeout: 245 seconds)
1362 2011-09-25 23:44:40 <Toawa> Because the block chain is already there.  That infrastructure has been built; why not use it?  Especially since, as has been pointed out, my original proposal can be simplified to as low as a single bit.
1363 2011-09-25 23:45:11 <sipa> and the block chain is massive thing to maintain
1364 2011-09-25 23:45:14 <gmaxwell> It can't actually be a single bit.
1365 2011-09-25 23:45:34 <Toawa> Well, a byte might be more realistic, but a bit is technically possible.
1366 2011-09-25 23:45:41 <sipa> there is absolutely no reason to use it for more than transaction ladger
1367 2011-09-25 23:45:46 <sipa> ledger
1368 2011-09-25 23:46:03 <gmaxwell> The blockchain is not an efficient mechenism for ephemerial private communication, which is what you need.  The block chain creates near immortal highly public communication, it's the least efficient communications channel ever realized.
1369 2011-09-25 23:46:16 <lfm> Toawa: because the block chain is not really a communication channel. it is a permenant store. using it as a comm channel is sub optimal
1370 2011-09-25 23:46:26 c00w has joined
1371 2011-09-25 23:46:35 <gmaxwell> Toawa: a bit is not technically possible without a lot of insane considerations.
1372 2011-09-25 23:46:57 <sipa> Toawa: would you please read my proposal?
1373 2011-09-25 23:47:05 <gmaxwell> e.g. requring all address generation to iterate until it generates the kind of address that it wants.
1374 2011-09-25 23:47:22 <Toawa> Ah, sorry, didn't see the link.
1375 2011-09-25 23:47:31 <lfm> one bit? use the least significant bit of the ammount. round the amount up to the next even or odd satoshi. they are essensially worthless anyway
1376 2011-09-25 23:47:55 <sipa> there is still no need
1377 2011-09-25 23:48:35 <sipa> once you accept there is going to be bidirectional communication, there are tons of possibilities
1378 2011-09-25 23:49:43 <Toawa> I'm not convinced that there will be bi-directional direct communication.  That's the whole point of my proposal; to have something that works in the absence of bi-directional direct communication.
1379 2011-09-25 23:49:57 <sipa> like tracking transactions direct
1380 2011-09-25 23:50:18 <sipa> there is no need for direct communication
1381 2011-09-25 23:50:28 <sipa> just bidirectional
1382 2011-09-25 23:50:41 <sipa> like the blickchain, indirectly
1383 2011-09-25 23:50:41 <gmaxwell> lfm: it would still require everyone to not use the wrong value, and would frequently result in additional change generation that we avoid now from round transactions.
1384 2011-09-25 23:50:49 <sipa> but a lot easier
1385 2011-09-25 23:51:43 <Toawa> Hell, I've just thought of a way to do it with as little as zero bits..
1386 2011-09-25 23:51:47 c00w has quit (Ping timeout: 260 seconds)
1387 2011-09-25 23:52:01 <lfm> telepathy?
1388 2011-09-25 23:52:19 <Toawa> No.. Transmitting information based on destination address selection.
1389 2011-09-25 23:52:35 <sipa> it'll always be less convenient than just negotating the tx outside of bitcoin
1390 2011-09-25 23:52:54 <lfm> yup, like the tv idol voting by phoneing different phone numbers?
1391 2011-09-25 23:52:59 <Toawa> exactly
1392 2011-09-25 23:53:12 c00w has joined
1393 2011-09-25 23:53:26 <Toawa> However, it potentially brings up a corner case when the inputs match the output exactly.
1394 2011-09-25 23:53:28 <lfm> that would be an acceptable technique
1395 2011-09-25 23:53:34 <sipa> you're hscking information in things it wasn't designed for
1396 2011-09-25 23:53:51 <Toawa> That's the whole point of hscking, is it not?
1397 2011-09-25 23:53:58 <Toawa> Finding new ways to use things
1398 2011-09-25 23:54:18 <lfm> the address already identifies the buyer in some ways
1399 2011-09-25 23:54:33 <sipa> you can do so much more by accepting that the block chain is not the best medium for what you need
1400 2011-09-25 23:54:46 rdponticelli has quit (Ping timeout: 248 seconds)
1401 2011-09-25 23:54:57 <Toawa> I'm trying to think in cases where it's potentially the only medium.
1402 2011-09-25 23:55:00 <gmaxwell> Toawa: lets assume for a moment that we decided that it would be okay to modify the bitcoin software to do what you want. Why not instead modify it so that you could create riders on transactions that don't get left in the blockchain but are ephemerial. Wouldn't that be superior?
1403 2011-09-25 23:55:27 <Toawa> It would.
1404 2011-09-25 23:55:45 <gmaxwell> And if we're going to go that far, why bother multiplexing it on the bitcoin protcol at all, where random bitcoin users have to pay the price when you decide that you want to use it to broadcast porno videos?
1405 2011-09-25 23:55:45 <sipa> how can it be the only medium? it requires a tcp connection already
1406 2011-09-25 23:55:54 <lfm> should be no need to modify bitcoin. its just another transaction shell that would use existing interfaces
1407 2011-09-25 23:56:41 <lfm> but ya, hard to immagine having enuf internet for bitcoin and not enuf for any other internet functions
1408 2011-09-25 23:56:45 <gmaxwell> or hell, as lfm points out... just pick which target address you use based on if you accept refunds or not, simple enough.
1409 2011-09-25 23:56:49 <Toawa> Because no sane person is going to try and incorporate that much data into a block, and the insane ones are easily detected.
1410 2011-09-25 23:56:56 p0s has quit (Remote host closed the connection)
1411 2011-09-25 23:57:13 <sipa> but there is no difference
1412 2011-09-25 23:57:15 <Toawa> That was my idea at 18:41
1413 2011-09-25 23:57:20 <Toawa> er, 23:41
1414 2011-09-25 23:57:26 <gmaxwell> Detected via magical mystery what?
1415 2011-09-25 23:57:27 <lfm> use UTC
1416 2011-09-25 23:57:45 <Toawa> Of course there's a difference.
1417 2011-09-25 23:58:25 <lfm> (insane ones? you mean like putting payers to one' diety in a block?) never mind, we don't need that sidetrack right now.
1418 2011-09-25 23:58:34 <Toawa> By the fact that suddenly you have a gargantuan transaction which, in all likelyhood, will never be incorporated without a huge fee attached.  Thinking of that, I've always wondered what happens to transactions that no one will use...
1419 2011-09-25 23:58:42 <gmaxwell> In any case, it doesn't really matter how much data it is. The amount of this data that belongs in the blocks is zero because it's not information the whole of bitcoin needs to know in order to validate that the transaction is consistent with the global rules.
1420 2011-09-25 23:59:34 <gmaxwell> gargantuan? no it wouldn't you'd use a great many free transactions to do it.