1 2013-06-24 00:55:08 <shesek> a type-2 deterministic key generation for javascript/nodejs, if anyone's interested: https://gist.github.com/shesek/5847473
  2 2013-06-24 01:39:59 <alusion> Is there a wiki?
  3 2013-06-24 01:40:10 <alusion> I'm putting together a dev team in my area for summer coding projects
  4 2013-06-24 01:40:50 <fanquake> alusion https://bitcoin.it/???
  5 2013-06-24 04:58:31 <tgs3> how is it going, fellow terrorists?
  6 2013-06-24 04:58:35 <tgs3> California criminalizes bitcoin use - goes after bitcoin foundation
  7 2013-06-24 05:01:45 <gmaxwell> tgs3: uh. Can you please keep the misinformation in your own home?
  8 2013-06-24 05:04:02 <tgs3> gmaxwell: the articles is http://arstechnica.com/tech-policy/2013/06/california-sends-a-cease-and-desist-order-to-the-bitcoin-foundation/   which part of what I said differs? or this is article not correct?
  9 2013-06-24 05:04:27 <gmaxwell> tgs3: the first four words of it.
 10 2013-06-24 05:06:10 <Diablo-D3> california sends a cease?
 11 2013-06-24 05:06:24 <gmaxwell> tgs3: The article makes no such claim, and the letter is really braindead and boring: http://www.scribd.com/doc/149335233/CA-State-Cease-and-Desist-May-30#page=1
 12 2013-06-24 05:07:34 <gmaxwell> 'Aaron Greenspan is suing everyone and accusing us if not equally enforcing our money transmitter laws, to cover our asses, since he accused you too??? we're sending out this letter that carefully alleges nothing but tells you if you're doing something you shouldn't be doing, that you should stop.'
 13 2013-06-24 05:08:32 <tgs3> wouldnt small trader like local bitcoin users also be "doing money exchange business"? Ofc. some targets are bigger and targeted frist
 14 2013-06-24 05:09:08 <gmaxwell> some targets are bigger? also? what are you talking about?
 15 2013-06-24 05:10:09 <gmaxwell> Bitcoin foundation is a professional org that does promotion and lobbying for bitcoin enthusiasts and companies. They only thing it does with money is accept dues from members and spend them, like any other professional org.
 16 2013-06-24 05:19:29 <Diablo-D3> gmaxwell: hey
 17 2013-06-24 05:19:37 <Diablo-D3> gmaxwell: whats the best eventually consistent db
 18 2013-06-24 05:19:55 <Diablo-D3> composable ops, the whole 9 yards
 19 2013-06-24 06:04:01 <gjs278> clearly it is couchdb
 20 2013-06-24 06:04:11 <matjeh> it is webscale
 21 2013-06-24 06:06:26 <Scrat> Diablo-D3: cassandra
 22 2013-06-24 06:07:12 <Diablo-D3> its not for a webapp, and Im not using java
 23 2013-06-24 06:08:38 <gjs278> I wish I could do something one day that wasn't a web app but somehow needed multiple dbs
 24 2013-06-24 06:08:43 <Scrat> you don't need to use java
 25 2013-06-24 06:09:30 <Scrat> but anyway what's the point of such a db on a program that you distribute?
 26 2013-06-24 06:09:58 <Diablo-D3> because its not distributed in a cluster
 27 2013-06-24 06:11:39 <sipa> shesek: bip32
 28 2013-06-24 06:11:46 <sipa> shesek: ?
 29 2013-06-24 06:12:13 <phantomcircuit> Diablo-D3, most of the nosql things are eventual consistency
 30 2013-06-24 06:12:21 <phantomcircuit> mongodb being the one people go apeshit for
 31 2013-06-24 06:13:12 <Diablo-D3> mongodb is a) shit, b) does not have composable ops
 32 2013-06-24 06:13:28 <Scrat> c) no distributed writes
 33 2013-06-24 06:13:44 <Diablo-D3> Scrat: not an issue, this isnt a cluster
 34 2013-06-24 06:14:19 <TD> why would you use a bigtable-like db with no cluster?
 35 2013-06-24 06:14:30 <gjs278> scale horizontally bro
 36 2013-06-24 06:14:47 <Diablo-D3> TD: I didnt say bigtable either
 37 2013-06-24 06:14:51 <Scrat> it is an issue when only 1 node is a designated master. cassandra and riak are truly shared nothing
 38 2013-06-24 06:15:15 <Diablo-D3> basically, I want to keep a data store synchronized when machines are not networked to each other during long periods
 39 2013-06-24 06:15:27 <Scrat> rsync
 40 2013-06-24 06:15:28 <TD> mysql can't do that?
 41 2013-06-24 06:15:29 <Scrat> lol
 42 2013-06-24 06:15:52 <Diablo-D3> Scrat: hurr no
 43 2013-06-24 06:15:58 <gjs278> multiple masters
 44 2013-06-24 06:17:31 <Diablo-D3> TD: why would I use mysql?
 45 2013-06-24 06:17:39 <Diablo-D3> that makes zero sense
 46 2013-06-24 06:18:00 <TD> why would you not? it does replication. if network connectivity goes away the replication log will build up, but any system would have that property
 47 2013-06-24 06:18:22 <Diablo-D3> because this isnt a webapp
 48 2013-06-24 06:18:28 <Diablo-D3> and mysql is inappropriate
 49 2013-06-24 06:19:39 <gjs278> if it has to be multiple masters I dont know how well mysql will merge those two when it reconnects
 50 2013-06-24 06:20:27 <TD> you can't do a correct arbitrary merge of two complicated divergent datasets unless you're using something like an operational transform algorithm. of course if your dataset is simple enough some ad hoc logic can work
 51 2013-06-24 06:20:56 <gjs278> there are certain datatypes that can be merged
 52 2013-06-24 06:21:08 <Diablo-D3> TD: well its why I asked for one with composable ops
 53 2013-06-24 06:25:55 <gjs278> http://code.google.com/p/orient/wiki/Replication best I could find
 54 2013-06-24 06:26:40 <gjs278> https://github.com/nuvolabase/orientdb/wiki/Replication for their new host
 55 2013-06-24 06:30:02 <Diablo-D3> almost tempted to just write something myself
 56 2013-06-24 07:28:38 <bitnumus> dont suppose anyone has a public mtgox websocket class?
 57 2013-06-24 09:32:34 <matjeh> is stratum protocol supposed to be wrapped inside HTTP?
 58 2013-06-24 09:49:15 <b0n1> hey guys, quick question: I just did a transaction to my address 135Bgfrjbt4yFHKcVK8w7HkdmELAjXgW3D. The address has never been used before and there was only this funding of 30 BTC to this address! When I check the blockchain, I see also an outgoing transaction, how can this be?
 59 2013-06-24 09:49:25 <b0n1> https://blockchain.info/address/135Bgfrjbt4yFHKcVK8w7HkdmELAjXgW3D
 60 2013-06-24 09:50:55 <b0n1> my wallet says that the payment never arrived at this address
 61 2013-06-24 09:52:06 <sturles> What client do you use?
 62 2013-06-24 09:52:34 <b0n1> its an online wallet
 63 2013-06-24 09:52:57 <b0n1> from localbitcoins
 64 2013-06-24 09:53:01 <sturles> Ask support.
 65 2013-06-24 09:53:24 <sturles> Online wallets work differently.
 66 2013-06-24 09:53:25 <b0n1> does this outgoing transaction mean, that the btc were transferred further?
 67 2013-06-24 09:53:30 <sturles> Yes.
 68 2013-06-24 09:53:37 <b0n1> hm
 69 2013-06-24 09:53:42 <b0n1> wtf
 70 2013-06-24 09:53:57 <sturles> The BTC arrived and were transferred further.
 71 2013-06-24 09:54:19 <sturles> If your online wallet didn't credit the coins to your account, you should contact support.
 72 2013-06-24 09:54:27 <sturles> Which online wallet, btw?
 73 2013-06-24 09:54:41 <b0n1> the localbitcoins.com wallet
 74 2013-06-24 09:54:49 <sturles> OK
 75 2013-06-24 09:55:04 <sturles> Contact support there then.
 76 2013-06-24 09:55:13 <b0n1> Yes, I will! thx!
 77 2013-06-24 10:16:17 <Luke-Jr> b0n1: no, it doesn't, and it's probably pretty normal
 78 2013-06-24 10:17:18 <Luke-Jr> b0n1: blockchain.info is terrible at its attempts to de-cloak private Bitcoin info; I'd suggest ignoring it by default
 79 2013-06-24 10:17:35 <Luke-Jr> if your wallet shows you have the money, there's not much to worry about usually
 80 2013-06-24 10:20:07 <b0n1> yes, but unfortunately it doesnt :(
 81 2013-06-24 10:20:54 <b0n1> localbtc needs 3 confirmations, these happend an hour ago, nothing happened so far
 82 2013-06-24 10:21:03 <Luke-Jr> hmm
 83 2013-06-24 10:21:32 <b0n1> i wrote a support ticket, hope things will clear up
 84 2013-06-24 10:21:36 <Luke-Jr> b0n1: you didn't do anything crazy like import/export a private key, by any chance?
 85 2013-06-24 10:21:45 <b0n1> no, nothing
 86 2013-06-24 10:22:14 <b0n1> just created this address completely new and did one transfer to it
 87 2013-06-24 10:22:18 <b0n1> thats all
 88 2013-06-24 10:22:18 <Luke-Jr> do you have any reason to assume localbitcoins.com isn't just a scam?
 89 2013-06-24 10:22:49 <b0n1> lol no
 90 2013-06-24 10:23:03 <b0n1> i am happy with the service so far
 91 2013-06-24 10:23:15 <b0n1> cant complain actually
 92 2013-06-24 10:23:18 <Luke-Jr> well, I guess all you can do is hope it isn't at this point
 93 2013-06-24 10:23:35 <Luke-Jr> I suppose 30 BTC shouldn't be enough someone risks trying to steal it
 94 2013-06-24 10:23:55 <b0n1> yes, me too
 95 2013-06-24 10:24:22 <b0n1> there are bigger transactions they could use for fraud
 96 2013-06-24 10:24:23 <Luke-Jr> if you can't run a full Bitcoin-Qt node, you might want to consider a SPV client like Electrum
 97 2013-06-24 10:24:50 <Luke-Jr> it can run without downloading the blockchain
 98 2013-06-24 11:38:25 <jgarzik> mornin'
 99 2013-06-24 11:38:51 <BlueMatt> morning jgarzik
100 2013-06-24 11:41:04 <shesek> sipa, nope, a much simpler solution based on gmaxwell type-2 thingy
101 2013-06-24 11:41:28 <shesek> (<sipa> shesek: bip32?)
102 2013-06-24 11:43:56 <sipa> shesek: bip32 is also based on type-2
103 2013-06-24 11:44:09 <shesek> yeah, but added much more on top of that
104 2013-06-24 11:44:34 <shesek> that library just takes a public/private key and a string, and returns keys
105 2013-06-24 12:20:28 <helo> 
ACTION grumbles about the reference client's offline wallet support

106 2013-06-24 12:24:23 <jgarzik> sipa, seems like the peers.dat fix might be appropriate for 0.8.3
107 2013-06-24 12:24:30 <jgarzik> gmaxwell, ^
108 2013-06-24 12:34:36 <sipa> jgarzik: ack
109 2013-06-24 12:40:01 <michagogo> helo: What support?
110 2013-06-24 12:41:28 <diki> Is it possible in future versions of Bitcoin to be able to natively specify a custom message(as most pools) as part of the coinbase?
111 2013-06-24 12:41:46 <helo> michagogo: dingding ;)
112 2013-06-24 12:41:59 <michagogo> :-P
113 2013-06-24 12:46:01 <jgarzik> sipa, did you see my email to bitcoin-development about C++ namespaces?  Any opinion on wrapping our stuff in a bitcoin namespace, as a small beginning step?
114 2013-06-24 12:46:16 <jgarzik> It's easy to bikeshed and over-namespace at the beginning.  Would prefer to start minimal.
115 2013-06-24 12:47:23 <helo> requiring (i.e. removing fat-finger protection unless) the offline machine validates the chain up to the last output you want to send arguably provides pretty good protection against full compromise of all online machines, at least
116 2013-06-24 12:47:31 <jgarzik> BlueMatt, is the pull tester alive again, for bitcoin.git HEAD?
117 2013-06-24 12:48:15 <BlueMatt> jgarzik: no, not yet
118 2013-06-24 12:48:18 <BlueMatt> (feel free to fix it)
119 2013-06-24 12:48:35 <BlueMatt> https://github.com/TheBlueMatt/test-scripts
120 2013-06-24 12:52:45 <helo> an spv offline wallet using bitcoinj that transfers utxo chains and headers would be pretty nice
121 2013-06-24 12:53:27 <helo> or not bitcoinj, i guess
122 2013-06-24 12:53:41 <BlueMatt> hmm?
123 2013-06-24 12:54:28 <helo> re: ideal offline wallet
124 2013-06-24 12:55:44 <helo> mostly processing the minimum amount of data to sufficiently protect against full compromise of all online machines, instead of processing the full blockchain as with an offline bitcoind
125 2013-06-24 12:56:10 <helo> s/instead of/in some other way than/
126 2013-06-24 12:59:03 <helo> i guess a simple non-verifying signing device that makes it easy to verify that outputs match is probably good enough
127 2013-06-24 13:02:14 <jgarzik> 
ACTION does a CodeShark summoning dance

128 2013-06-24 13:03:11 <jgarzik> sipa, gmaxwell, what do we think about https://github.com/bitcoin/bitcoin/pull/1889 ?  "let user select wallet file with -wallet=foo.dat"   Any movement or thoughts beyond those included in the pull req ?
129 2013-06-24 13:03:15 <jgarzik> 
ACTION leans towards closing

130 2013-06-24 13:03:48 <jgarzik> 
ACTION is trying to close pull reqs that have been hanging out for a while, and don't seem to be making much progress in months

131 2013-06-24 13:04:25 <jgarzik> down to 2 pages of pull reqs
132 2013-06-24 13:08:13 <TD> helo: like trezor?
133 2013-06-24 13:10:56 <warren> hmm, I need to get a trezor.  I hope it's capable of simultaneously holding multiple types of keys, both Bitcoin and otherversion=48 type.
134 2013-06-24 13:11:46 <enigmuriatic> transaction timestamps in bitcoind are just the timestamp of the block, right?
135 2013-06-24 13:12:16 <helo> TD: yep :)
136 2013-06-24 13:12:39 <sipa> jgarzik: as i've commented on the pull: if the db dir moves along with the wallet
137 2013-06-24 13:21:22 <jgarzik> As much as Sergio occasionally can be annoying, firmcoin (firmcoin.com) does look interesting
138 2013-06-24 13:21:31 <jgarzik> (RE Trezor)
139 2013-06-24 13:59:16 <jgarzik> 
ACTION spies a CodeShark 

140 2013-06-24 14:00:27 <jgarzik> CodeShark, would you update #2174?  should be easy
141 2013-06-24 15:05:08 <HaltingState> what other security models are there to proof of work, besides POS? any new suggestions?
142 2013-06-24 15:09:25 <HaltingState> gmaxwell, that cease and desist is stupist thing i have ever seen; i live in CA and half a mile from my house they raided a organic vegan food coop with a swat team because they were selling raw milk; there are youtube videos on it
143 2013-06-24 15:09:31 <HaltingState> california is out of control
144 2013-06-24 15:12:08 <pierce> HaltingState: I think that was more of a FDA (federal) thing than a state thing
145 2013-06-24 15:12:27 <HaltingState> like why can i eat the food i want
146 2013-06-24 15:12:28 <pierce> though it sounds like state police were happy to come along for the ride
147 2013-06-24 15:12:39 <HaltingState> is the government going to come and take my organic chia seeds next!?
148 2013-06-24 15:12:57 <HaltingState> i cant order coffee online in california either because its a "restricted item" if its from out of state
149 2013-06-24 15:13:05 <pierce> it's more about selling than eating, but ya, those laws are pretty archaic
150 2013-06-24 15:14:35 <HaltingState> I wonder if it will get better, i doubt it
151 2013-06-24 15:15:00 <HaltingState> regulatory capture, expansion of powers, etc.. there is no process for reversal
152 2013-06-24 15:15:08 <pierce> the problem is so many companies have terrible hygine standards, so rather than saying that animals shouldn't be raised in shit, just pasturize everything that comes out
153 2013-06-24 15:15:18 <HaltingState> complete lack of common sense in deciding who to raid, lack of discretion
154 2013-06-24 15:15:23 <pierce> HaltingState: old people die
155 2013-06-24 15:15:49 <HaltingState> oh ya in 20 years they will all be dead
156 2013-06-24 15:16:03 <helo> reversal process is "they mess up, people get aware, mad"
157 2013-06-24 15:16:12 <HaltingState> do you think the new old people will have a greater sense of the importance of liberty and common sense
158 2013-06-24 15:16:34 <Shockzz_> I personally don't.
159 2013-06-24 15:17:10 <Shockzz_> There are quite a lot of people that don't have common sense, and a smaller portion that know what's wrong with this planet and DO have common sense.
160 2013-06-24 15:18:04 <pierce> HaltingState: I don't even think it is as much about liberty as it is about common sense.  Pro-biotics are getting a better and better reputation, and soon the benefits will be undeniable, and when the stubborn people die off, better informed people will take their place.
161 2013-06-24 15:24:12 <warren> sipa: <forrestv> warren, do you know whether the "standard" is to have OP_RETURN at the start or at the end of the scriptPubkey?
162 2013-06-24 15:24:19 <warren> petertodd: ^^
163 2013-06-24 15:24:42 <kinlo> it isn't standard afaik
164 2013-06-24 15:26:00 <jgarzik> warren, note my patch gets it backwards
165 2013-06-24 15:26:10 <jgarzik> warren, the "standard" is what is correctly evaluated
166 2013-06-24 15:26:25 <warren> forrestv: ^^
167 2013-06-24 15:26:47 <sipa> i thought the idea was OP_RETURN at the start of the script
168 2013-06-24 15:26:56 <sipa> no point in trying to evaluate anything before
169 2013-06-24 15:28:03 <jgarzik> sipa, petertodd's criticism was that my pull req defined the stack order in the reverse of what was required to achieve OP_RETURN at start of script
170 2013-06-24 15:28:09 <Luke-Jr> yeah, OP_RETURN at the start is the most obviously prunable
171 2013-06-24 15:28:24 <jgarzik> 
ACTION intentionally left the code as-is to let other people evaluate for themselves

172 2013-06-24 15:28:33 <warren> forrestv: the goal is to make this prunable, so I guess start is best.
173 2013-06-24 15:28:54 <warren> forrestv: let's wait for petertodd though, since he's the one that asked for it
174 2013-06-24 15:29:14 <jgarzik> I'm rusty on script, notably whether we want OP_RETURN on top-of-stack and thus listed last(?) in the source code
175 2013-06-24 15:29:17 <warren> forrestv: did you miss messages here?
176 2013-06-24 15:29:37 <forrestv> warren, no, i just tried to say "alright" and couldn't
177 2013-06-24 15:29:53 <forrestv> (so i auth'd)
178 2013-06-24 15:29:56 <jgarzik> clearly you want it evaluated first
179 2013-06-24 15:29:56 <warren> ah
180 2013-06-24 15:30:31 <warren> jgarzik: btw, how's the pruning code?  did anyone actually write it yet?  we want to test it in the next litecoin.
181 2013-06-24 15:30:34 <jgarzik> forrestv, Yeah, after reams of spam we had to turn on register-to-talk
182 2013-06-24 15:31:04 <jgarzik> warren, real pruning?  not written yet AFAIK.  You have to think through how pruned nodes present themselves on the P2P network
183 2013-06-24 15:31:14 <warren> jgarzik: we have 13M UTXO, 12M of which are 1-satoshi spam.  We will have a 95% miner vote that declares all 1-satoshi UTXO unspendable.  After that point we can prune it.
184 2013-06-24 15:31:38 <warren> jgarzik: UTXO pruning? we talking about different things?
185 2013-06-24 15:32:26 <jgarzik> warren, apparently.  Not sure what you mean, then.  UTXO is auto-pruning from the standpoint of spent coins.
186 2013-06-24 15:32:30 <Luke-Jr> jgarzik: OP_RETURN first would also be top-of-stack, I'm pretty sure
187 2013-06-24 15:33:40 <jgarzik> i.e. given CScript() << CBigNum(4) << OP_RETURN ? or ? CScript() << OP_RETURN << CBigNum(4)
188 2013-06-24 15:33:46 <jgarzik> in the C++ source code
189 2013-06-24 15:33:54 <Luke-Jr> either
190 2013-06-24 15:33:56 <jgarzik> which has OP_RETURN as first evaluated opcode?
191 2013-06-24 15:34:11 <Luke-Jr> the latter, IIRC
192 2013-06-24 15:42:35 <warren> jgarzik: in our case, after 95% miner vote, no 1-satoshi txo will be spendable ever again.  That alone doesn't reduce the UTXO set.  We would need something else that removes unspendable utxo.
193 2013-06-24 15:46:39 <petertodd> sipa, warrne: definitely at the start, so we don't make the assumption that scripts can't exist part way
194 2013-06-24 15:47:14 <petertodd> OP_RETURN after all used to be defined as "return true"
195 2013-06-24 15:48:16 <petertodd> there is the edge case where it's slightly better at the end if you want to *prove* that the txout is unspendable, because you can provide a sha256 midstate, but that's only useful if the txout is the last one right now - seems like a marginal use-case
196 2013-06-24 15:52:09 <warren> forrestv: ^^
197 2013-06-24 16:01:39 <petertodd> *make the assumptions that scripts can't exit
198 2013-06-24 16:23:58 <sipa> jgarzik: CScript() << OP_RETURN << anything
199 2013-06-24 16:24:05 <sipa> jgarzik: the code is in the order of the script
200 2013-06-24 16:39:48 <dugo> process transactions that netto reduce the UTXO set for free
201 2013-06-24 16:46:03 <grau> dugo: the preference of miner decides on block inclusion. A transaction that aggregates a lot of inputs is huge, taking up block space and might hurt their revenue. Unlikely that they would go with this.
202 2013-06-24 16:56:09 <dugo> grau: ah well, then it probably doesn't hurt bad enough in expenses to keep the utxos around
203 2013-06-24 17:09:17 <fluffypony> I have a question
204 2013-06-24 17:09:25 <fluffypony> if I call getinfo
205 2013-06-24 17:09:33 <fluffypony> paytxfee is 0 by default
206 2013-06-24 17:09:43 <fluffypony> does that mean that if I call sendtoaddress
207 2013-06-24 17:09:48 <fluffypony> that it's sent without a fee?
208 2013-06-24 17:12:56 <sipa> fluffypony: if possible
209 2013-06-24 17:14:05 <fluffypony> well that's bad
210 2013-06-24 17:14:23 <fluffypony> I've sent most of my transactions straight from the CLI without realising
211 2013-06-24 17:14:25 <fluffypony> O.o
212 2013-06-24 17:14:28 <fluffypony> 
ACTION feels bad

213 2013-06-24 17:16:57 <michagogo> fluffypony: Why?
214 2013-06-24 17:17:13 <michagogo> I mean, transaction fees are good, but at this point in time it's not a significant amount
215 2013-06-24 17:17:17 <fluffypony> true
216 2013-06-24 17:17:45 <michagogo> Does anyone have statistics on average coinbase outputs?
217 2013-06-24 17:18:02 <michagogo> (i.e. average fees per block)
218 2013-06-24 17:31:40 <gmaxwell> BlueMatt: I don't think that payment protocol is sufficient to prevent bad uses of txout data. Payment protocol works for those who are willing to not use the p2p network.
219 2013-06-24 17:31:55 <BlueMatt> what did I say?
220 2013-06-24 17:32:09 <gmaxwell> "Concept/Code skim ACK, after payment protocol gets merged - too much ability to take the path of least resistance and just use OP_RETURN for adding data to a txn because there is no alternative."
221 2013-06-24 17:32:21 <BlueMatt> sufficient? no
222 2013-06-24 17:32:27 <BlueMatt> provides a better path, yes
223 2013-06-24 17:32:44 <gmaxwell> I'm not arguing with you, I'm adding to your comments. :)
224 2013-06-24 17:32:51 <BlueMatt> hopefully most people are willing to not use p2p, its a pretty shitty method to broadcast
225 2013-06-24 17:32:53 <BlueMatt> ok
226 2013-06-24 17:33:19 <gmaxwell> I don't think anyone is working on anything that lets you use p2p but doesn't put junk in the blockchain.
227 2013-06-24 17:33:38 <petertodd> The audience who would make use of OP_RETURN can't use P2P for their goals
228 2013-06-24 17:34:08 <BlueMatt> the intended audience, yes
229 2013-06-24 17:35:14 <petertodd> and the audience who would use P2P, well they're going to use P2P because they're nice people
230 2013-06-24 17:35:28 <petertodd> OP_RETURN is meant to give bad people a way to do bad things in a less bad way
231 2013-06-24 17:36:09 <gmaxwell> petertodd: there is no way to use the p2p right now that doesn't result in forever-storage.
232 2013-06-24 17:36:24 <gmaxwell> OP_RETURN doesn't change that, it just makes the forever storage less costly.
233 2013-06-24 17:36:36 <gmaxwell> There should be an option that doesn't result in forever storage.
234 2013-06-24 17:36:55 <petertodd> Do you mean P2P flood fill? because we can enable that pretty easily
235 2013-06-24 17:37:07 <gmaxwell> Without it being a DOS vector.
236 2013-06-24 17:37:43 <petertodd> Sure, lots of nice proof-of-sacrifice/stake/work techniques there.
237 2013-06-24 17:38:15 <petertodd> People have been talking about using bitmessage too for that purpose.
238 2013-06-24 17:38:58 <petertodd> re: OP_RETURN, frankly I think requiring such txouts to follow the dust rules is a good thing, just make it half as expensive so that doing the less-wrong thing is always cheaper
239 2013-06-24 17:39:33 <petertodd> Or just add it to a min relay fee, and make that min relay fee very large.
240 2013-06-24 17:39:47 <petertodd> (dust rules represent about 6x min relay fee)
241 2013-06-24 18:26:01 <sipa> ;;blocks
242 2013-06-24 18:26:02 <altgribble> 243144
243 2013-06-24 19:18:46 <skinnkavaj> So many people are talking about "off chain" transacations which can be used in the "future"
244 2013-06-24 19:18:54 <skinnkavaj> excatly how could that work? give me some examples
245 2013-06-24 19:19:22 <skinnkavaj> with security in mind ofc
246 2013-06-24 19:22:03 <Diablo-D3> it cant be used
247 2013-06-24 19:22:27 <gmaxwell> skinnkavaj: they're used all the time now.
248 2013-06-24 19:22:46 <skinnkavaj> gmaxwell: Where and how?
249 2013-06-24 19:22:47 <gmaxwell> E.g. transactions that happen between two mtgox users by default happen with no blockchain activity.
250 2013-06-24 19:23:03 <gmaxwell> Same for many other services that hold accounts.
251 2013-06-24 19:23:44 <gmaxwell> There is no particular technical reason why that couldn't be federated over a wider area
252 2013-06-24 19:23:57 <Diablo-D3> gmaxwell: thats different though
253 2013-06-24 19:24:03 <Diablo-D3> thats not a BITCOIN transaction
254 2013-06-24 19:24:10 <Diablo-D3> thats a transaction involving bitcoins that go nowhere.
255 2013-06-24 19:24:12 <Luke-Jr> yes it is
256 2013-06-24 19:24:23 <Diablo-D3> if the bitcoin chain cant see it, its not a bitcoin transaction
257 2013-06-24 19:25:54 <sipa> it's not a bitcoin-the-protocol transaction
258 2013-06-24 19:26:00 <sipa> but it is a bitcoin-the-currency transaction
259 2013-06-24 19:26:37 <Diablo-D3> sipa: but those are the same thing
260 2013-06-24 19:26:44 <sipa> i disagree completely
261 2013-06-24 19:26:46 <Diablo-D3> if its not done by the protocol, it doesnt exist
262 2013-06-24 19:27:03 <sipa> you can have multiple bitcoin-the-currency transactions per bitcoin-the-protocol transactions even
263 2013-06-24 19:27:16 <sipa> i can pay multiple people in one transaction
264 2013-06-24 19:27:45 <Diablo-D3> thats not what Im talking about and you know it
265 2013-06-24 19:27:59 <sipa> maybe not, but it is what we are talking about
266 2013-06-24 19:36:35 <iddo> skinnkavaj: the basic idea is for example at https://en.bitcoin.it/w/index.php?title=Myths&oldid=27737#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation (option 3, not sure why it was deleted from the wiki), and improvements were discussed too, e.g. https://bitcointalk.org/index.php?topic=91732.0
267 2013-06-24 19:37:59 <jgarzik> skinnkavaj, this talks about micropayment channels too, \t https://docs.google.com/presentation/d/1E4Aglf1sW6EMpNSjjWQ13GoZVPYljnydbghEV7w13nI/edit#slide=id.gf256a77_0_35
268 2013-06-24 19:38:12 <jgarzik> skinnkavaj, http://en.bitcoin.it/ has some other examples
269 2013-06-24 19:38:55 <jgarzik> skinnkavaj, petertodd did some thinking.  Though not directly related, this is worth reading, https://en.bitcoin.it/wiki/Fidelity_bonds
270 2013-06-24 19:39:36 <jgarzik> skinnkavaj, and as gmaxwell noted?  transfers between two MtGox or Silk Road users are off-chain
271 2013-06-24 19:49:21 <helo> 
ACTION imagines interface where user selects amount to send, where to send, and in within what timeframe tx/rx is acceptable

272 2013-06-24 19:49:48 <helo> so it might collect a day or longer's worth of transactions into one
273 2013-06-24 19:50:13 <helo> how much space does combining two typical transactions into one really save?
274 2013-06-24 19:51:22 <sipa> helo: a lot, i think
275 2013-06-24 19:51:42 <sipa> depends on the inputs available, i guess
276 2013-06-24 19:52:01 <helo> "Thank you for using the Bitcoin Super Saver Wallet! You have saved _.____ in fees!"
277 2013-06-24 19:52:23 <sipa> if all inputs are the same amount, below what is being sent, you need a proportional number of inputs and you won't save much
278 2013-06-24 19:53:01 <sipa> if you have a variety of inputs, above what is being sent, you'll typically only need one regardless of your payment amounts
279 2013-06-24 19:55:40 <iddo> elliptic curves have the property that you can aggregate many signatures into one signature that verifies all of them, see http://crypto.biu.ac.il/winterschool2013/Boneh-school-overview.pdf (page 9, or search "bitcoin")
280 2013-06-24 19:56:19 <iddo> but i'm a little confused on what exactly would be the use case for this with bitcoin, anyone knows?
281 2013-06-24 19:56:23 <gmaxwell> iddo: many signatures with the same public key is easy. And also useless.
282 2013-06-24 19:56:45 <sipa> iddo: is that batch verification?
283 2013-06-24 19:57:15 <gmaxwell> The general batch case is interesting for block validation.
284 2013-06-24 19:57:36 <sipa> it's a known technique, but it requires (for ECDSA) that the full R point is known, not just the x coordinate
285 2013-06-24 19:57:46 <gmaxwell> But ^
286 2013-06-24 19:57:58 <sipa> and you get an exponential blowup in the number of signatures if you don't have that information
287 2013-06-24 19:58:11 <sipa> which makes it pretty much useless, as the gains are never over a factor ~2
288 2013-06-24 19:58:31 <iddo> what is batch verification? one single signature that verifies all the transactions in the block?
289 2013-06-24 19:58:52 <sipa> batch verification is the procedure where you get a list of (signature,pubkey) tuples and verify them all
290 2013-06-24 19:58:59 <sipa> Ed25519 does it well
291 2013-06-24 19:59:15 <sipa> ECDSA (with just r's X coordinate, the standard way) doesn't
292 2013-06-24 19:59:51 <sipa> i believe that Ed25519 gets a factor 2 speedup when verifying 64 signatures at once
293 2013-06-24 20:00:11 <sipa> which is nice, but not worth so much hassle
294 2013-06-24 20:00:12 <iddo> i thought the the idea is to get rid of all the signatures and replace them with a single signature? is there a use case for that?
295 2013-06-24 20:00:21 <sipa> oooh
296 2013-06-24 20:00:34 <sipa> you're talking about split signatures
297 2013-06-24 20:01:00 <sipa> where you can have multiple parties sign, and have them combine the signatures into one
298 2013-06-24 20:01:17 <sipa> implementing N-of-N signatures at the crypto level rather than the script level
299 2013-06-24 20:01:48 <iddo> right, i see
300 2013-06-24 20:02:13 <iddo> so this is the only use case for aggregating signatures at the crypto level, for bitcoin?
301 2013-06-24 20:12:39 <iddo> maybe you could compress a block by stripping all the signatures and having just one aggregated signature, but you must keep the pubkeys of all the transactions
302 2013-06-24 20:13:31 <sipa> iddo: let me ask you this: why do you store a block at all?
303 2013-06-24 20:13:59 <iddo> so everyone can verify the ledger history?
304 2013-06-24 20:14:20 <sipa> bingo
305 2013-06-24 20:14:28 <sipa> would that work, if you change it?
306 2013-06-24 20:14:38 <sipa> *if you change the contents of transaction
307 2013-06-24 20:15:14 <iddo> you could still verify that the pubkeys are valid for the individual transactions, and just verify one single signature at the end?
308 2013-06-24 20:16:15 <sipa> but you won't be able to prove that the transaction's hashes are correct
309 2013-06-24 20:16:16 <sipa> so you can't prove the set of unspent transaction outputs (which are indexed by txid) is correct
310 2013-06-24 20:17:45 <iddo> op_checksig checks that the implicit message which is the entire transaction fits the signature? so just have op_checksig now verify the single aggregated signature?
311 2013-06-24 20:18:45 <sipa> yes, that allows verification of a transaction
312 2013-06-24 20:18:49 <sipa> but that's worthless
313 2013-06-24 20:19:02 <sipa> you need to know the transaction is valid, and what its txid is
314 2013-06-24 20:19:20 <sipa> and you cannot prove that txid if you change a signature
315 2013-06-24 20:20:19 <iddo> is that an inherent problem? or just the particular behavior of the protocol?
316 2013-06-24 20:21:30 <sipa> well since a block's hash is computed from its header, and the header contains the merkle root of the transactions's hashes in it, yes that is an inherent problem: you can't prove a block is correct if you can't prove which transactions are part of it
317 2013-06-24 20:21:41 <sipa> that's just one problem, there are probably others
318 2013-06-24 20:23:18 <iddo> the problem is that the signature must be hashed into txid ?
319 2013-06-24 20:23:25 <sipa> yes
320 2013-06-24 20:23:41 <iddo> ok i see
321 2013-06-24 20:23:42 <sipa> that's the essense of the problem, indeed
322 2013-06-24 20:33:26 <BlueMatt> devrandom: ping
323 2013-06-24 20:35:42 <devrandom> hey BlueMatt
324 2013-06-24 20:36:05 <BlueMatt> devrandom: did the email asking about license for gitian ever get forwarded to you?
325 2013-06-24 20:36:17 <devrandom> I don't think so
326 2013-06-24 20:36:20 <devrandom> let me double check
327 2013-06-24 20:36:33 <BlueMatt> well, to sum it up, there is no license file, please add one
328 2013-06-24 20:36:57 <devrandom> sure.  what do you recommend?
329 2013-06-24 20:37:41 <BlueMatt> 
ACTION doesnt really care, Id assume either mit or gpl depending on your personal leanings

330 2013-06-24 20:38:02 <devrandom> okey dokey
331 2013-06-24 20:38:09 <BlueMatt> 
ACTION gladly licenses his contributions under anything that doesnt result in any liability for me

332 2013-06-24 20:38:11 <maaku> are there any unit tests for CScriptCompressor?
333 2013-06-24 20:38:39 <sipa> maaku: don't think so
334 2013-06-24 20:38:44 <maaku> ok
335 2013-06-24 20:39:08 <sipa> there are for the amount compression, iirc
336 2013-06-24 20:39:15 <maaku> yeah i saw those
337 2013-06-24 20:39:25 <BlueMatt> devrandom: though its not a huge deal, technically you need to ping all the people who have contributed and get them to agree to the new license :(
338 2013-06-24 20:39:36 <sipa> maaku: i'm not sure i'd recommend using that in something that is intended to be normative, though
339 2013-06-24 20:39:53 <sipa> maaku: it's probably overly complex for what it's worth, and people will need to reimplement it exactly
340 2013-06-24 20:40:31 <maaku> sipa: it's for the txid:n index
341 2013-06-24 20:40:42 <sipa> ok?
342 2013-06-24 20:41:07 <maaku> ok i mean: what alternative is there?
343 2013-06-24 20:41:32 <sipa> something similar, for simpler
344 2013-06-24 20:41:35 <sipa> *but
345 2013-06-24 20:42:16 <sipa> ultraprune started as an experiment to know how small the UTXO set could be stored
346 2013-06-24 20:42:27 <sipa> and it turned into an actual database layout that uses it
347 2013-06-24 20:43:42 <maaku> i don't think it is overly complex
348 2013-06-24 20:43:59 <maaku> or rather i think the complexity is necessary and inherent
349 2013-06-24 20:44:16 <maaku> i'm reimplementing it in Python for the utxo index tests I'm running
350 2013-06-24 20:44:38 <maaku> so there'd be at least two interoperable implementations if/when we use it for the normative indexes
351 2013-06-24 20:44:39 <sipa> for example the varint scheme (which i'm quite proud of...) has ridiculously low benefit over a much more trivial scheme
352 2013-06-24 20:45:41 <sipa> though it has the nice property of being 1:1
353 2013-06-24 20:46:40 <gmaxwell> maaku: necessary? hm? you can just serialize the whole transaction. (not saying this is a grand scheme, but necessary is too big a claim)
354 2013-06-24 20:47:22 <BlueMatt> I assume putting an empty commit on top of the license commit and pushing that will make someone happy
355 2013-06-24 20:47:22 <BlueMatt> sipa, wumpus, Luke-Jr: after devrandom pushes a license file to gitian's repo, can y'all do something to release your contributions under that license?
356 2013-06-24 20:47:24 <maaku> gmaxwell: my definition of necessary is different than yours
357 2013-06-24 20:48:55 <gmaxwell> There are different considerations, however, for a normative data structure. People struggle to get endianness correct in their implementations.
358 2013-06-24 20:49:06 <Luke-Jr> BlueMatt: merely asking each of us in advance is the correct route I think
359 2013-06-24 20:49:38 <gmaxwell> And at the same time??? there is still space being left on the floor. I can give you a nice range coder if you'd like one.  Sipa's current stuff strikes one particular complexy / performance / storage trade-off.
360 2013-06-24 20:50:13 <gmaxwell> But that set of tradeoffs was for a non-normative thing so I wouldn't automatically assume a normative encoding justified the same tradeoff.
361 2013-06-24 20:51:00 <maaku> gmaxwell: i can't range-code more than a single transaction. would you expect double-digit or better compression from that?
362 2013-06-24 20:51:50 <sipa> no, but i expect less than 0.01% from my varint encoder :p
363 2013-06-24 20:52:16 <gmaxwell> maaku: One of the considerations that come up with normative encodings vs non-normative is that when the prior probablities change??? different transactions are common??? you can just change a non-normative encoding.
364 2013-06-24 20:53:04 <gmaxwell> maaku: Single transaction at a time actually doesn't matter??? assuming that you would expect it to handle the transactions in any order the only gain from statefulness would be knowing the prior probablities, which could be baked in?????but I think doing that in a normative datastructure is bad.
365 2013-06-24 20:54:19 <maaku> gmaxwell: more to the point, in an authenticated datastructure it has to be stateless, ... unless you have some way of prepending necessary state to a proof
366 2013-06-24 20:56:16 <devrandom> Luke-Jr: GPL3 okay?
367 2013-06-24 20:56:46 <gmaxwell> maaku: I'm not actually clear what you think you're telling me there that I don't know already.
368 2013-06-24 20:56:59 <Luke-Jr> devrandom: personally, I'd prefer MIT; but GPLv3 is okay iff it's clear that it doesn't "infect" the software itself or binaries
369 2013-06-24 20:57:11 <Luke-Jr> devrandom: by default, the GPLv3 would likely infect the binaries output
370 2013-06-24 20:57:37 <Luke-Jr> which would make Bitcoin non-distributable
371 2013-06-24 20:57:45 <gmaxwell> and certantly the current transactions could be made much smaller by further compressing them. a standard script could be reduced to a tiny fraction of a bit plus its high entropy arguments.
372 2013-06-24 20:58:12 <sipa> gmaxwell: ehm, we do that (well, one byte instead of one bit)
373 2013-06-24 20:58:45 <sipa> in the UTXO set at least
374 2013-06-24 21:00:10 <gmaxwell> sipa: Not even 1 bit. I assume right now it would be about 1.4427e-05 bits. so.. vs 1 byte thats a factor of 1.8e6 space savings! :P
375 2013-06-24 21:00:18 <gmaxwell> I think this would be a poor idea. But if you're going to take one comple encoding which embeds assumptions about what transactions look like, why not another?
376 2013-06-24 21:01:30 <gmaxwell> (Answer: because it's slow??? and because no one wants to put 400 LOC of complicated packing code in a normative structure. I totally agree, but by that same token I don't think it's automatically obvious that its right to copy the one used in bitcoin today)
377 2013-06-24 21:07:49 <devrandom> Luke-Jr, sipa, BlueMatt: OK to do GPLv3 for Gitian, with clarification that outputs are not affected by license?
378 2013-06-24 21:09:11 <BlueMatt> I hereby license my contributions to gitian-builder under GPLv3 and do not claim any copyright or license requirements on any derivatives or outputs generated by the software therein
379 2013-06-24 21:09:29 <BlueMatt> wumpus too
380 2013-06-24 21:09:50 <BlueMatt> (needs to, that is, he is laanjw on github)
381 2013-06-24 21:12:14 <BlueMatt> 
ACTION -> sleep

382 2013-06-24 21:12:46 <devrandom> later BlueMatt
383 2013-06-24 21:25:37 <md2k7> the most common transaction uses 4 OPs and a 20-byte hash of a public key
384 2013-06-24 21:25:51 <md2k7> so why is the VI for the script length usually 25 (I count 24 above)?
385 2013-06-24 21:26:38 <md2k7> (txout script)
386 2013-06-24 21:28:09 <md2k7> oh crap, figured it out, it's the <bytes to push> for the hash. as in https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address
387 2013-06-24 21:28:49 <gaantr2> does anyone know how I can get "ticker" into my app?
388 2013-06-24 21:29:24 <gaantr2> writing a Java application - I'd like to get ;;ticker price into the application
389 2013-06-24 21:29:54 <md2k7> gaantr2: I guess poll a web service for it? like bitcoincharts.com or blockchain.info have developer APIs
390 2013-06-24 21:35:01 <Luke-Jr> devrandom: ok
391 2013-06-24 21:39:06 <sipa> devrandom: GPLv3 license for my (very minimal) gitian co tributions: ok
392 2013-06-24 21:44:29 <devrandom> thank you
393 2013-06-24 21:45:18 <devrandom> the tor people did a Gitian build of TBB... impressive.