1 2012-08-20 00:00:20 <sipa> we used it for a code generation monad
  2 2012-08-20 00:01:06 <amiller> that makes sense, it basically provides you with a call stack
  3 2012-08-20 00:01:13 <sipa> where each element in the source language was mapped to a monad transformer in a huge monad stack
  4 2012-08-20 00:01:28 <sipa> and each could have its own state
  5 2012-08-20 00:02:27 <sipa> i don't think you need something that complex here
  6 2012-08-20 00:02:40 <amiller> it's not complex, it's just the right level of abstraction
  7 2012-08-20 00:03:07 <amiller> the reason why is that i will be able to run it in one mode "without hashes", and then it should be just as efficient as your utxos are right now
  8 2012-08-20 00:03:40 <amiller> and at any point, given my redblack utxo, i can compute the merkleized root hash version of it directly, without needing to be aware of the order histor
  9 2012-08-20 00:03:54 <amiller> and i'd get the same result as if i ran it the entire time "with hashes turned on"
 10 2012-08-20 00:04:14 <sipa> sure, but adding a memoization transformer doesn't require such a monad zipper
 11 2012-08-20 00:04:37 <amiller> i didn't mention memoization yet
 12 2012-08-20 00:04:48 <amiller> but that would be a third monda
 13 2012-08-20 00:04:53 <sipa> right
 14 2012-08-20 00:04:58 <amiller> basically i would have a 'RedBlackTree' monad transformer based on the zipper
 15 2012-08-20 00:05:16 <amiller> and i can insert three different "hash computation" monads to get different tradeoffs
 16 2012-08-20 00:05:34 <sipa> ok
 17 2012-08-20 00:06:10 <amiller> is there an easy way i can ask ultraprune to give me the utxo at a particular block in time
 18 2012-08-20 00:06:14 <amiller> i'd have to simulate a reorg
 19 2012-08-20 00:06:28 <sipa> it only keeps the final state
 20 2012-08-20 00:06:42 <amiller> how do you handle reorgs?
 21 2012-08-20 00:07:03 <sipa> by keeping undo data for blocks
 22 2012-08-20 00:07:41 <amiller> so you create a copy of the database, apply the undo data back to the fork point, then validate the fork?
 23 2012-08-20 00:07:46 <amiller> and if so, you scrap the old database?
 24 2012-08-20 00:08:19 <sipa> there is never a copy
 25 2012-08-20 00:08:53 <sipa> ah, but the intended changes are kept in a cache in ram until it is certainly correct
 26 2012-08-20 00:09:01 <sipa> and then committed atomiclly
 27 2012-08-20 00:12:18 <sipa> which is kind of a copy-on-write duplicate
 28 2012-08-20 00:12:19 <amiller> close enough, modulo the size of your cache
 29 2012-08-20 00:13:23 <sipa> but even at normal IBD time, i use that cache to accumulate the changes.from multiple blocks, to commit there changes in one go to the db
 30 2012-08-20 00:13:28 <Luke-Jr> what do you guys think of PPCoin?
 31 2012-08-20 00:15:16 <sipa> Luke-Jr: what's that?
 32 2012-08-20 00:16:32 <Luke-Jr> sipa: appears to be the first non-scam altcoin
 33 2012-08-20 00:16:39 <Luke-Jr> https://bitcointalk.org/?topic=101820
 34 2012-08-20 00:16:47 <sipa> proof of stake
 35 2012-08-20 00:16:50 <sipa> interesting
 36 2012-08-20 00:17:41 <sipa> anyway, gtg
 37 2012-08-20 00:17:43 <sipa> cya
 38 2012-08-20 00:17:47 <Luke-Jr> they need to change their icon tho. confusing which one is PPCoin and which is Bitcoin XD
 39 2012-08-20 00:17:51 <jgarzik> Luke-Jr: litecoin is a scamcoin?
 40 2012-08-20 00:20:16 <Luke-Jr> jgarzik: IMO, yes
 41 2012-08-20 00:22:30 <sunshinehappy> what about bitcoin?
 42 2012-08-20 00:22:33 <Luke-Jr> jgarzik: their only substantial change is scrypt PoW, which is fundamentally flawed and they knew it from the start
 43 2012-08-20 00:23:30 <smiddi> anybody noticed the sudden raise of Thash/s? http://bitcoincharts.com/bitcoin/   17Th ---> 23Th
 44 2012-08-20 00:24:30 <jgarzik> smiddi: bitcoincharts was "stuck" earlier, maybe that is the result
 45 2012-08-20 00:30:11 <smiddi> jgarzik: look at http://bitcoin.sipa.be/  this is 5Th higher than ever
 46 2012-08-20 00:30:34 <Luke-Jr> BFL testing ASICs?
 47 2012-08-20 00:30:52 <smiddi> ack, think so
 48 2012-08-20 00:33:03 <smiddi> but how many boards must that be  o.O
 49 2012-08-20 00:35:12 <Luke-Jr> 5 rigs?
 50 2012-08-20 00:35:18 <jgarzik> ChainDb: height 194740, block 00000000000000858b066d91a9986f8700b8835b69cde7480487ca64f0039129
 51 2012-08-20 00:35:33 <jgarzik> neverseen 32?  what a bunch of crap.
 52 2012-08-20 00:35:58 <jgarzik> didn't change the pool size on any bitcoind, either
 53 2012-08-20 00:45:31 <gmaxwell> Luke-Jr: sounds like it's another fool centeralized system, the developers can broadcast checkpoints at will.
 54 2012-08-20 00:46:58 <MC-Eeepc> Luke-Jr are you mining ixcoins and iocoins and shit now
 55 2012-08-20 00:47:21 <Luke-Jr> gmaxwell: that can be fixed ;)
 56 2012-08-20 00:48:50 <gmaxwell> right, but it's a sign of cluelessness.
 57 2012-08-20 00:49:15 <gmaxwell> until things like that are fixed the only motivation to touch is is omg-early-adopter.
 58 2012-08-20 00:51:48 <Luke-Jr> gmaxwell: I look at it more from the perspective of, is it likely to scam people
 59 2012-08-20 00:52:00 <Luke-Jr> mere failures can be left to fail
 60 2012-08-20 00:52:15 <gmaxwell> And that incentive is squared by the fact that the subsidy goes down with difficulty instead of up.
 61 2012-08-20 00:52:45 <gmaxwell> e.g. instead of a linear decrease in rewards as its popularity grows, it's a quadratic decrease in rewards.
 62 2012-08-20 00:53:05 <Luke-Jr> same with Bitcoin, just it's got timestamps and block heights tied in
 63 2012-08-20 00:53:07 <gmaxwell> (rewards per computational unit)
 64 2012-08-20 00:53:40 <Luke-Jr> I don't want to defend it just yet, but it seems to be different from the scamcoins
 65 2012-08-20 00:55:53 <doublec> they justify the checkpoint broadcast in their paper
 66 2012-08-20 00:56:08 <doublec> as something they don't like but have 'for now' or something like that iirc
 67 2012-08-20 00:56:55 <doublec> in a post they also said they reserve the right to restart the chain, etc so it seems to be very much an experiment
 68 2012-08-20 00:57:15 <Luke-Jr> doublec: probably true, since at least one person has already threatened to 51% it
 69 2012-08-20 00:57:27 <doublec> Luke-Jr: heh, that didn't take long
 70 2012-08-20 00:58:10 <doublec> pity it's not merge minable
 71 2012-08-20 00:58:18 <Luke-Jr> yeah
 72 2012-08-20 00:58:30 <Luke-Jr> fwiw, there's a channel in #ppcoin discussing it
 73 2012-08-20 00:58:34 <doublec> oh thanks
 74 2012-08-20 00:59:25 <doublec> it's the first actually interesting alt coin in a while anyway
 75 2012-08-20 01:00:02 <gmaxwell> doublec: hm? they have a paper? the thread I saw seemed to be saying the design was curently a secret.
 76 2012-08-20 01:00:12 <gmaxwell> link link
 77 2012-08-20 01:00:39 <doublec> gmaxwell: http://www.ppcoin.org/static/ppcoin-paper.pdf
 78 2012-08-20 01:01:24 <gmaxwell> Luke-Jr: looks like there are some non-protocol improvements which we want in bitcoin.
 79 2012-08-20 01:01:47 <Luke-Jr> gmaxwell: oh? I noticed the diff was fairly small..
 80 2012-08-20 01:04:48 <jgarzik> random related:  I always wanted to maintain a parallel tree for "if we could start from scratch" bitcoin improvements.  Nothing pie-in-the-sky...  open up all the script ops, use google protocol buffers rather than a custom serialization, ...
 81 2012-08-20 01:05:03 <jgarzik> i.e. if compatibility was not an issue
 82 2012-08-20 01:06:54 <sunshinehappy> why are there not IRC logs for the weekend??
 83 2012-08-20 01:07:03 <gmaxwell> sad that they're not aware of amiller's txout-set-queries as POW stuff.
 84 2012-08-20 01:07:49 <gmaxwell> Luke-Jr: the payout formula also resulted in a super impressive quasi premine.
 85 2012-08-20 01:08:05 <sunshinehappy> :((((((
 86 2012-08-20 01:08:09 <sunshinehappy> I was relying on those logs
 87 2012-08-20 01:08:10 <doublec> I noticed some people having generation values of 2000+
 88 2012-08-20 01:11:29 <gmaxwell> doublec: every 16x increase in difficulty halves the subsidy. It's at 387 now and started at 1, the current reward is about 2300. so the block zero should have been ??
 89 2012-08-20 01:12:16 <gmaxwell> in any case, it's premined all to hell.
 90 2012-08-20 01:12:18 <doublec> gmaxwell: it started at 2xx
 91 2012-08-20 01:12:25 <doublec> gmaxwell: (difficulty that is)
 92 2012-08-20 01:13:10 <gmaxwell> Hm? block1 is difficulty 1.
 93 2012-08-20 01:13:23 <doublec> ok, now I can't find where I read that :)
 94 2012-08-20 01:13:30 <amiller> i bet most unusual difficulty adjustment schemes are provably non-viable
 95 2012-08-20 01:14:10 <doublec> so I am likely wrong
 96 2012-08-20 01:15:31 <Luke-Jr> jgarzik: I've considered that too (and even setup a branch once), but I suspect we have plenty of "we can do it now" improvements to focus on
 97 2012-08-20 01:17:02 <doublec> gmaxwell: block 1 difficulty is 256
 98 2012-08-20 01:17:17 <gmaxwell> er. they appear to base their target off just the last two blocks timestamps (well + the prior difficulty  * alpha) Er. that has to have consequences.
 99 2012-08-20 01:17:18 <doublec> gmaxwell: block 0 is 1.0
100 2012-08-20 01:17:27 <amiller> "We attempted to design a practical distributed checkpointing protocol but found it difficult to secure against network split attack." lame
101 2012-08-20 01:20:30 <amiller> the energy consumption essential in bitcoin, but the time regularization is... how does randomness work with proof of stake
102 2012-08-20 01:20:51 <gmaxwell> amiller: see their paper.
103 2012-08-20 01:23:46 <amiller> unless i'm missing something, you can buy blocks deterministically then, there's no regard to time
104 2012-08-20 01:23:55 <amiller> if you wanted to fork someone, you could just each take turns out bidding each other
105 2012-08-20 01:29:30 <gmaxwell> What incentive exists in this system to include transactions?
106 2012-08-20 01:32:01 <gmaxwell> oh duh, because they're picking the longest chain based on how many transactions it includes.
107 2012-08-20 01:32:51 <amiller> there's a contradiction between two components of the proposal, since the 51% measurement is not about the actual amount of bitcoins you have, but the number of old coins you have
108 2012-08-20 01:33:07 <amiller> so a 10% attacker who holds onto his coins forever will have the advantage over 90% of people who spend their coins
109 2012-08-20 01:33:29 <gmaxwell> indeed.
110 2012-08-20 01:34:41 <gmaxwell> so without their centerally controlled checkpoints you could do a really awesome timewarpish attack on this puppy.
111 2012-08-20 01:35:33 <gmaxwell> You'd fork the chain far back, and then fudge your timestamps so that you mine a ton of coins??? more than the real chain has. Then you paddle those puppies back and forth, thus making yourself a strongly prefered chain.
112 2012-08-20 01:35:37 <gmaxwell> Bummer.
113 2012-08-20 01:36:20 <amiller> "form of proof of ownership of the currency." what does ownership of the currency have to do with "coin age"
114 2012-08-20 01:37:43 <gmaxwell> yea, thats muddled. Proof of stake as discussed is about coin days destroyed. Not about having lots of coins, because without 'been sitting still not moving' factor the dude with the most coins always wins.
115 2012-08-20 01:38:45 <amiller> so if they really mean that making a  <49%  of total coin-age assumption belongs to attackers, what does that mean
116 2012-08-20 01:39:06 <amiller> i think that assumption roughly means "most coins held by honest people haven't being spent recently"
117 2012-08-20 01:39:17 <amiller> haven't been*
118 2012-08-20 01:39:56 <amiller> whenever you make a transaction, you're consuming stake
119 2012-08-20 01:40:34 <amiller> so there's absolutely no size of attacker that this defeats, if "making transactions" is something that honest people do in the normal use
120 2012-08-20 01:44:54 <amiller> "First the cost of controlling significant stake might be higher than the cost of acquiring significant mining power," well no there's no reason to think that, especially because "stake" isn't proportional to coins
121 2012-08-20 01:46:35 <gmaxwell> amiller: yea, one argument that I eventually got is that all fungible resources are equal.
122 2012-08-20 01:47:25 <gmaxwell> in terms of representing an acquistion cost; the best idea I've seen once observed with that lens is at least making sure the resource reflects a capacity to do useful work for the network.
123 2012-08-20 01:59:10 <amiller> it pretty easy for people to exchange trade bitcoins/ppcoins without actually making an official transaction, for example with casacius coins
124 2012-08-20 01:59:38 <amiller> of course, it would be lame if that was the _only_ way to exchange coins, because it's not very secure and reducing reliance is the point of the protocol
125 2012-08-20 02:00:04 <amiller> but since it's certainly possible, it would be bad if the protocol were vulnerable to that kind of transaction
126 2012-08-20 02:01:19 <amiller> so basically it's 51% successful in the case that everyone trusts each other and exchanges coins without making transactions
127 2012-08-20 02:01:26 <amiller> but the minute you make a transaction, you destroy your advatange over the attacker
128 2012-08-20 02:07:06 <gmaxwell> people mining up the difficulty seems to be the only thing preventing unbounded inflation, which seems.. weird to me.
129 2012-08-20 02:10:59 <gmaxwell> Luke-Jr: since you were porting fixes against it, would you happen to have an idea of whatever improvements it has that we should pull into bitcoin?
130 2012-08-20 02:11:16 <gmaxwell> (I mean, non protocol stuff, of course)
131 2012-08-20 02:11:30 <Luke-Jr> gmaxwell: dunno, it was REALLY trivial
132 2012-08-20 02:11:42 <Luke-Jr> I just did git merge 0.6.x, resolved some minor conflicts
133 2012-08-20 02:12:33 <Luke-Jr> when done with that:  40 files changed, 2525 insertions(+), 620 deletions(-)
134 2012-08-20 02:12:53 <Luke-Jr> they bump win32 dep versions for gitian
135 2012-08-20 02:14:11 <gmaxwell> I see getinfo gains
136 2012-08-20 02:14:23 <gmaxwell> which sounds useful (though it's v4 only centric)
137 2012-08-20 02:16:06 <Luke-Jr> src/util.h:        return (pthread_t)0; <-- this is in our code, and invalid O.o
138 2012-08-20 02:23:20 <BCBot> Stats: http://bit.ly/bitcoin-irc-stats
139 2012-08-20 02:54:55 <old-timer> What is the default CPU miner?
140 2012-08-20 02:55:05 <old-timer> Or rather where is it?
141 2012-08-20 02:55:27 <old-timer> Is it completely stripped out of bitcoin?
142 2012-08-20 02:55:51 <old-timer> I've enabled it in bitcoind but CPU is doing nothing.
143 2012-08-20 02:56:22 <old-timer> I can't believe you removed it from the default client.
144 2012-08-20 02:56:45 <old-timer> When was it removed from the GUI?
145 2012-08-20 02:57:13 <old-timer> Anyone?
146 2012-08-20 02:59:40 <forrestv> old-timer, it was removed a while ago
147 2012-08-20 03:00:34 <old-timer> Was it removed from the default bitcoind?
148 2012-08-20 03:00:42 <forrestv> i thought so... checking now
149 2012-08-20 03:02:39 <forrestv> old-timer, ah, no, it still appears to be in there, at least in my week-old version built from git
150 2012-08-20 03:02:48 <forrestv> there was talk about removing it a while, though
151 2012-08-20 03:03:03 <forrestv> a while ago
152 2012-08-20 03:12:13 <gmaxwell> forrestv: we hid it from the gui, but its still there.
153 2012-08-20 03:13:00 <gmaxwell> And it's hidden from the gui because we got tired of people showing up on IRC _furious_ that they'd "mined for weeks and got nothing".
154 2012-08-20 03:13:47 <forrestv> mmhm. well now we have people furious that they can't use the inefficient builtin cpu miner, apparently
155 2012-08-20 03:13:50 <gmaxwell> old-timer: and if it's enabled doing but nothing its because you're either not current with the chain or you don't have connections, it won't and has never worked in those cases.
156 2012-08-20 03:14:06 <gmaxwell> And it was removed something like a year ago.
157 2012-08-20 03:15:13 <old-timer> If I have changed the bitcoin payout split for testing services, how would I get it to start mining?
158 2012-08-20 03:15:43 <gmaxwell> old-timer: use testnet.
159 2012-08-20 03:16:06 <old-timer> I don't want to use testnet.
160 2012-08-20 03:16:43 <gmaxwell> And, to finish the argument??? At the current difficulty at 12 MH (a _fast_ cpu with a state of the art cpu miner, not the one in bitcoind) has an expected time to mine a block of 24 years.
161 2012-08-20 03:17:04 <gmaxwell> old-timer: so if you're planning on cpu mining on the bitcoin network, I hope you're feeling pretty patient.
162 2012-08-20 03:17:09 <old-timer> And if the difficulty dropped to 1?
163 2012-08-20 03:17:14 <Luke-Jr> gmaxwell: erm, I get 15 MH/s with a mid-level CPU :p
164 2012-08-20 03:17:18 <old-timer> Then it would again be relevant.
165 2012-08-20 03:17:39 <Luke-Jr> ;;bc,calc 12000000
166 2012-08-20 03:17:40 <gribble> The average time to generate a block at 12000000 Khps, given current difficulty of 2190865.9701029 , is 1 week, 2 days, 1 hour, 49 minutes, and 1 second
167 2012-08-20 03:17:44 <Luke-Jr> ;;bc,calc 12000
168 2012-08-20 03:17:45 <gribble> The average time to generate a block at 12000 Khps, given current difficulty of 2190865.9701029 , is 24 years, 45 weeks, 0 days, 17 hours, 4 minutes, and 34 seconds
169 2012-08-20 03:17:59 <Luke-Jr> hmm, I'd think it'd take longer
170 2012-08-20 03:18:01 <gmaxwell> old-timer: It's not going to do that??? ever, considering that just a couple cheap gpus can keep it way above that. But regardless, if it did that, then someone could reasonably add the option back to the gui.
171 2012-08-20 03:18:50 <old-timer> Does the client need to be connected to another client at the same block count in order to mine?
172 2012-08-20 03:18:53 <midnightmagic> gmaxwell: I can do 22MH/s with a 6-core 1090T, and that's not, IMO, even really fully optimized.
173 2012-08-20 03:19:09 <Luke-Jr> gmaxwell: meh, not really. kitchen sinks aren't a good idea
174 2012-08-20 03:19:15 <midnightmagic> That CPU is pretty old and busted, too. I'm disappointed with how poorly it's held up over the years.
175 2012-08-20 03:20:03 <gmaxwell> midnightmagic: really? I don't think I ever saw hashrates anywher near that high out of a 1055T
176 2012-08-20 03:20:26 <gmaxwell> In any case, 12years, 24 years, it's still unlikely to find a block in reasonable time.
177 2012-08-20 03:20:55 <gmaxwell> old-timer: What exactly are you trying to accomplish?
178 2012-08-20 03:21:13 <midnightmagic> it was a derived measurement, but as far as I could tell, about 22MH using a dedicated CPU miner. I remember being surprised at how much stronger it was than my..  I think it was a 9600GT.
179 2012-08-20 03:23:26 <old-timer> I want to diverge at an earlier bock by lowering the subsidy.
180 2012-08-20 03:24:15 <midnightmagic> yeah, and that's with a static difficulty. out at those times, the long-term difficulty increases end up actually making a difference. I'd be willing to bet (entirely without working out at all) that he'd never see a block, ever.
181 2012-08-20 03:25:01 <midnightmagic> old-timer: Are you working on some kind of parallel altchain?
182 2012-08-20 03:25:04 <old-timer> If I diverge from the block count when the difficulty was still one, then I should be able to generate just fine.
183 2012-08-20 03:25:10 <gmaxwell> old-timer: okay, well, you need two nodes connected, and it need to believe its not in the initial block download.
184 2012-08-20 03:25:16 <Luke-Jr> old-timer: use testnet. that's what it's for
185 2012-08-20 03:25:17 <old-timer> Sort of.
186 2012-08-20 03:25:50 <gmaxwell> Luke-Jr: hes going to be off on a fork regardless.
187 2012-08-20 03:25:53 <old-timer> Yes, I know that's what testnet is for.
188 2012-08-20 03:25:59 <doublec> I do the same as old-timer for my testing :)
189 2012-08-20 03:26:09 <doublec> start two nodes, disconnected from the network starting at block 1
190 2012-08-20 03:26:27 <midnightmagic> old-timer:  Well..  there're also the checkpoints to consider too. You'll have to disable the checkpoint logic.
191 2012-08-20 03:26:39 <gmaxwell> old-timer: In any case; two nodes, and remove the IsInitialBlockDownload test in bitcoinrpc. and/or nuke all the checkpoints.
192 2012-08-20 03:26:48 <doublec> yeah, checkpoints and that global for estimated block count or whatever it's called
193 2012-08-20 03:26:54 <old-timer> I don't want block 1. Oh, and by the way, how do I start bitcoind without outgoing connections?
194 2012-08-20 03:27:09 <gmaxwell> -connect=127.0.0.1 works fine.
195 2012-08-20 03:27:33 <old-timer> -connect=127.0.0.1 doesn't work.
196 2012-08-20 03:27:45 <midnightmagic> -noirc -nodnsseed I *think* will remove all bootstrap peer location stuff?
197 2012-08-20 03:28:06 <gmaxwell> old-timer: Please be more clear about what you mean by "doesn't work".
198 2012-08-20 03:28:17 <gmaxwell> midnightmagic: noirc is default.
199 2012-08-20 03:28:22 <gmaxwell> (for bitcoin)
200 2012-08-20 03:28:48 <midnightmagic> gmaxwell: Is it now?  Ah, that's a good thing. Hey, do I have to write my own seeder if I want to run a dns seeder?  Seems like everyone's running their own.
201 2012-08-20 03:29:10 <midnightmagic> ah who am I kidding, I'll never get around to that. please ignore that question.
202 2012-08-20 03:29:12 <gmaxwell> midnightmagic: diversity is good. :) Though bluematt's and sipa's are available.
203 2012-08-20 03:29:14 <midnightmagic> old-timer: What are you up to?
204 2012-08-20 03:29:22 <old-timer> Never mind, it must have been another option that I had
205 2012-08-20 03:29:45 <Luke-Jr> 
ACTION wonders if he should try BlueMatt's

206 2012-08-20 03:35:03 <midnightmagic> 
ACTION prods old-timer.

207 2012-08-20 03:35:35 <old-timer> Ok, thanks for your help.
208 2012-08-20 03:35:36 <midnightmagic> 
ACTION pulls out a fork

209 2012-08-20 03:35:56 <old-timer> I've got my clients connected. Now I think I just need to get rid of some checkpoints.
210 2012-08-20 03:36:17 <midnightmagic> old-timer: Whatchya doon?
211 2012-08-20 03:36:45 <old-timer> midnightmagic, top secret-ish
212 2012-08-20 03:37:37 <midnightmagic> old-timer: So when do we get paid for the private support? Is this a project which we are all going to celebrate when we find out about it?
213 2012-08-20 03:40:18 <midnightmagic> meh..
214 2012-08-20 03:40:35 <old-timer> Celebrate? I doubt it. But probably won't be upset or anything.
215 2012-08-20 03:48:48 <gmaxwell> old-timer: So are you investigating a bug, starting up another altcoin of questionable merit, troubleshooting non-bitcoin code, or what?
216 2012-08-20 03:49:55 <gmaxwell> Or are you another one of those crazy people who think they can stop the subsidy halving by just getting miners to switch?
217 2012-08-20 03:52:03 <old-timer> I'm just an old-timer who is pissed that you took out the CPU timer from the GUI. Thank you for your help. Now get off my lawn.
218 2012-08-20 03:52:48 <gmaxwell> old-timer: I'll commit a change right now putting it back in, if you promise to personally handle every angry email, and explain to people why their computer has been heating their house for months without a bitcent in return.
219 2012-08-20 03:53:01 <Luke-Jr> old-timer: your lawn?
220 2012-08-20 03:53:43 <old-timer> How about a documented way to re-enable it?
221 2012-08-20 03:54:09 <old-timer> Like a command line switch or something.
222 2012-08-20 03:54:16 <Luke-Jr> it's completely useless. why bother?
223 2012-08-20 03:54:21 <Luke-Jr> (also, it IS documented already)
224 2012-08-20 03:54:23 <gmaxwell> old-timer: er, it's documented in the commandline help.
225 2012-08-20 03:55:07 <gmaxwell> -gen                   Generate coins
226 2012-08-20 03:55:22 <gmaxwell> It's also documented in the wiki page for the config file.
227 2012-08-20 03:55:35 <Luke-Jr> gmaxwell: maybe that should be changed to "Waste CPU"
228 2012-08-20 03:55:40 <gmaxwell> hah.
229 2012-08-20 03:55:47 <old-timer> I want it in the GUI. Look, I understand why you took it out. Now, lets supposed there was a controled ruduction of CPU mining. The difficulting could be reduced in a few months, not years.
230 2012-08-20 03:56:20 <old-timer> It's a safety measure to the network.
231 2012-08-20 03:56:24 <Luke-Jr> old-timer: but that's not good for Bitcoin, so it won't happen
232 2012-08-20 03:56:43 <Luke-Jr> and miners should be miners, and wallets should be wallets
233 2012-08-20 03:56:44 <gmaxwell> ssh.
234 2012-08-20 03:56:47 <Luke-Jr> there is no reason to mix them
235 2012-08-20 03:57:24 <old-timer> If there wasn't a reason to mix them, then it wouldn't have been in the original client.
236 2012-08-20 03:57:34 <Luke-Jr> you give Satoshi too much credit
237 2012-08-20 03:58:17 <gmaxwell> old-timer: If people are going to the trouble of twiddling a gui option, then is a config option or commandline switch that much of an additional barrier?
238 2012-08-20 03:58:37 <old-timer> I would apprieciate it if it could be re-enabled within the GUI. Was it taken out before or after the Qt switch?
239 2012-08-20 03:59:09 <Luke-Jr> old-timer: forget it already
240 2012-08-20 03:59:18 <gmaxwell> Luke-Jr: hush.
241 2012-08-20 03:59:21 <old-timer> Does anyone happen to have a revision number when it was removed?
242 2012-08-20 03:59:30 <gmaxwell> old-timer: IIRC it was before but I'm trying to find it now.
243 2012-08-20 03:59:52 <old-timer> Thank you.
244 2012-08-20 03:59:59 <Luke-Jr> e93e5349cb32e47bf68f9cc682cb84642a02cfef
245 2012-08-20 04:00:11 <Luke-Jr> aka jgarzik/remove-gui-gen and pull #142
246 2012-08-20 04:01:28 <Luke-Jr> and SSE4 optimizations were removed in b26141e2c5836ccd20bd32a9c653cf2ba5e5b5ee (#141, jgarzik/remove-4way)
247 2012-08-20 04:01:37 <Luke-Jr> err, SSE2
248 2012-08-20 04:02:18 <midnightmagic> old-timer: Satoshi did a lot of what he did because it was just him and a couple other people writing it. Sometimes coding efficiently requires you to take shortcuts if you want to get done quickly. So even if Satoshi *did* it that way, that doesn't imply he *thought it was the best way to do it.*
249 2012-08-20 04:02:56 <gmaxwell> In any case, it would be much more interesting to reintroduce integrated mining in combination with distributed subsidy sharing support.
250 2012-08-20 04:03:10 <midnightmagic> a.k.a. p2pool in mainline!
251 2012-08-20 04:03:12 <midnightmagic> 
ACTION cheers.

252 2012-08-20 04:03:24 <old-timer> Look, I appreciate everyone's contributions, it just put me in a bad mood coming home and not recognizing the place.
253 2012-08-20 04:03:34 <Luke-Jr> midnightmagic: no :p
254 2012-08-20 04:03:53 <midnightmagic> Luke-Jr: Why not?
255 2012-08-20 04:03:59 <Luke-Jr> midnightmagic: because it's biased toward a pool
256 2012-08-20 04:04:00 <Luke-Jr> duh
257 2012-08-20 04:04:44 <gmaxwell> Hey, it would only take 10,000 22MH/s (really fast cpus) miners at current difficulty 1008 days to mine 2016 blocks to quarter the difficulty. hurrah.
258 2012-08-20 04:05:02 <midnightmagic> Luke-Jr: I preferred you when you weren't capitalized
259 2012-08-20 04:06:01 <midnightmagic> old-timer: So where did you go and when did you leave?
260 2012-08-20 04:06:35 <old-timer> Just offline.
261 2012-08-20 04:07:10 <Luke-Jr> old-timer: you know, if you liked wxBitcoin, I wouldn't mind helping you get off the ground reviving it ???
262 2012-08-20 04:07:20 <Luke-Jr> old-timer: then you could, as maintainer, add the menu item back..
263 2012-08-20 04:09:01 <gmaxwell> Unfortunately the rise of mining as a clearly net-profitable adventure has made people astonishingly disdainful of mining at a loss.
264 2012-08-20 04:09:05 <midnightmagic> Or you could take the opportunity to strip all the important guts out of the GUI entirely and make it a separate piece of software where it doesn't matter if it breaks or doesn't get linked against a multithreaded library!
265 2012-08-20 04:09:10 <gmaxwell> (a loss over electrical costs, I mean)
266 2012-08-20 04:09:16 <old-timer> Thanks for the offer. But I'm sure I'll get used to the new client eventually.
267 2012-08-20 04:18:13 <old-timer> Ok, I've got mining working. I promise to not harm the network. See ya all later. Keep up the great work.
268 2012-08-20 04:19:11 <finway> hello
269 2012-08-20 04:28:44 <finway> Why there's no log on 16 17 18 ?
270 2012-08-20 04:29:37 <finway> Did some one clear it out or just nobody talks ?
271 2012-08-20 04:29:54 <gmaxwell> Censored, to hide the information about the upcoming Secret Event.
272 2012-08-20 04:30:04 <sunshinehappy> seriously? I needed those logs
273 2012-08-20 04:32:23 <gmaxwell> No. I'm kidding, the logging service is unreliable. It's gone down twice recently.
274 2012-08-20 04:32:38 <sunshinehappy> oh lol
275 2012-08-20 04:33:01 <sunshinehappy> someone gave me a good command line script but I cleared my .bash_profilebecause it had passwords in it so I lost it
276 2012-08-20 04:33:08 <sunshinehappy> but I was actually able to remember it
277 2012-08-20 04:33:20 <sunshinehappy> but I was trying to find it in the log :/
278 2012-08-20 04:33:33 <gmaxwell> sunshinehappy: to avoid that problem in the future, https://bitcointalk.org/index.php?topic=54671.0
279 2012-08-20 04:35:00 <sunshinehappy> neat! thanks
280 2012-08-20 04:40:23 <finway> What's purecoin, i just noticed that rocornor  return with it.
281 2012-08-20 04:40:46 <gmaxwell> finway: an incomplete bitcoin implementation.
282 2012-08-20 04:41:11 <finway> gmaxwell, i think he means  imcompatible ?
283 2012-08-20 04:42:00 <finway> gmaxwell, where can i find the code or paper ?
284 2012-08-20 04:42:12 <Luke-Jr> [06:29:54] <gmaxwell> Censored, to hide the information about the upcoming Secret Event. <-- lol
285 2012-08-20 05:03:10 <amiller> http://www.rsa.com/rsalabs/staff/bios/aoprea/publications/time-stamping.pdf interesting article by rsalabs of all things, on the use of merkle tries and merkle binary trees for some secure storage protocols
286 2012-08-20 05:03:25 <amiller> they have comparisons of efficiency, for worst case, and for average cases with random data
287 2012-08-20 05:04:05 <amiller> but here's the thing, the only way they got merkle _tries_ to work correctly is that they had an _append only_ structure
288 2012-08-20 05:08:35 <amiller> you know how i keep talking about a skip graph built over the blockchain itself, that's the sort of thing that you really want a patricia trie for
289 2012-08-20 05:09:33 <amiller> it just grows forever, until you forget about it basically
290 2012-08-20 05:13:01 <amiller> but the UTXO is different, it needs to be a balanced tree because we treat it differently
291 2012-08-20 05:14:52 <amiller> tries are protected by proof of work, but balanced trees are deterministically tough.
292 2012-08-20 05:17:16 <amiller> clients produce transactions - their hashes are unconstrained so you can't give preference to them, but fortunately they only need to be validated within a smaller set (not necessarily an infinitely growing one)
293 2012-08-20 05:17:46 <amiller> maybe that's a good place to draw the line - do you guys think of the UTXO set as something that grows forever, or something that stabilizes to a finite size?
294 2012-08-20 05:28:28 <amiller> there are presumably more unique requests for transaction validation so you can't share that load as easily
295 2012-08-20 05:28:52 <amiller> on the other hand proof-of-work chains are relevant to everyone, so they will propagate easily through the network
296 2012-08-20 05:50:28 <amiller> UTXO belongs to the clients, hash-value-highway belongs to the miners
297 2012-08-20 06:13:10 <amiller> miners will compete by storing chunks of historic UTXO data, in a sharded way, which will allow us to validate long forks by swarm effort
298 2012-08-20 06:13:24 <amiller> their average case is mining, their worst-case is dealing with a fork
299 2012-08-20 06:14:10 <amiller> on the other side, there are clients, who hire miners and validate novel blocks and novel transactions
300 2012-08-20 06:16:51 <amiller> they need to make random accesses to the current UTXO.
301 2012-08-20 06:23:14 <dust-otc> can someone explain how miners are rewarded with ppcoin's proof of stake?
302 2012-08-20 06:23:40 <dust-otc> can transaction fees be collected just by holding old coins?
303 2012-08-20 07:35:41 <sacarlson> I've been away for some time and had to install a new version of bitcoin on ubuntu 0.3.24 from ppa,  only real question is what block are we at now?  I've been downloading all day so far and got 126241 blocks so far,  how far I got to go?
304 2012-08-20 07:37:04 <[Tycho]> ;;bc.last
305 2012-08-20 07:37:05 <gribble> Error: "bc.last" is not a valid command.
306 2012-08-20 07:37:08 <gribble> Error: "bc,last" is not a valid command.
307 2012-08-20 07:37:08 <[Tycho]> ;;bc,last
308 2012-08-20 07:37:13 <gribble> Error: "bc.help" is not a valid command.
309 2012-08-20 07:37:13 <[Tycho]> ;;bc.help
310 2012-08-20 07:37:40 <gribble> Alias bc,24hprc, Alias bc,avgprc, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btcguild, Alias bc,calc, Alias bc,calcd, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias bc,fx, Alias bc,gen, Alias bc,gend, Alias bc,halfreward, Alias bc,help, Alias bc,hextarget, Alias bc,intersango, Alias (2 more messages)
311 2012-08-20 07:37:40 <[Tycho]> ;;bc,help
312 2012-08-20 07:37:48 <[Tycho]> ;;bc,blocks
313 2012-08-20 07:37:49 <gribble> 194785
314 2012-08-20 07:38:32 <[Tycho]> Wow, 200k coming soon.
315 2012-08-20 07:38:40 <gribble> Estimated time of bitcoin block reward halving: Mon Dec  3 17:28:00 2012 | Time remaining: 15 weeks, 0 days, 15 hours, 50 minutes, and 0 seconds
316 2012-08-20 07:38:40 <[Tycho]> ;;bc,halfreward
317 2012-08-20 07:39:01 <gribble> 2408120.51951692
318 2012-08-20 07:39:01 <[Tycho]> ;;bc,estimate
319 2012-08-20 07:41:19 <ersi> wuh woh!
320 2012-08-20 08:33:00 <Cryo> damn gavin
321 2012-08-20 08:33:04 <Cryo> <tr><td>Obfuscated email</td><td>IP Address</td><td>Transaction ID</td></tr>
322 2012-08-20 08:33:05 <Cryo> <tr>
323 2012-08-20 08:33:17 <Cryo> oh nm, you got me
324 2012-08-20 08:33:46 <Cryo> braincell just read it as it should be
325 2012-08-20 10:43:52 <genjix_afk> hi, who is responsible for blockchain.info? are they on irc?
326 2012-08-20 10:50:07 <genjix_afk> nevermind. emailed him.
327 2012-08-20 10:50:36 <sipa> very afk you seem!
328 2012-08-20 11:06:58 <Eliel> amiller: If you've read the ppcoin paper by now, you probably noticed this yourself, but to mine with the proof-of-stake you need to expend the coin-age in the process to make a block.
329 2012-08-20 11:07:35 <Eliel> amiller: it makes sustained 51% attack impossible without really having 51%+
330 2012-08-20 11:08:39 <Eliel> amiller: however, it seems to me you can mine future blocks now and know in advance when you'll be finding blocks.
331 2012-08-20 11:11:36 <Eliel> so, without the centralized locking mechanism they're using, it's really not usable.
332 2012-08-20 11:29:33 <gmaxwell> Eliel: they're checkpointing instantly behind the chain head too.
333 2012-08-20 11:30:06 <TD> er
334 2012-08-20 11:30:11 <gmaxwell> (not only does nothing prevent them from purely using the centeralized checkpoints as the only consensus mechenism, thats actually what they're doing)
335 2012-08-20 11:30:11 <TD> doesn't that defeat the point of a block chain?
336 2012-08-20 11:30:45 <Eliel> yep
337 2012-08-20 11:32:05 <Eliel> double-spends are simpler to pull out in their proof-of-stake system than in bitcoin because you can "mine in advance" to know the exact time when you'll find future blocks.
338 2012-08-20 11:32:21 <epscy> what is proof of stake
339 2012-08-20 11:32:26 <epscy> ppcoin needs a wiki
340 2012-08-20 11:33:10 <Eliel> http://www.ppcoin.org/static/ppcoin-paper.pdf
341 2012-08-20 11:33:12 <gmaxwell> In fact, their placement of a checkpoint _appears_ to have orphaned a block of mine.
342 2012-08-20 11:33:41 <Eliel> gmaxwell: considering they seem to do it automatically, it'd mean the block that is orphaned is the one they don't see first.
343 2012-08-20 11:33:47 <gmaxwell> s/a/at least a/
344 2012-08-20 11:34:18 <gmaxwell> Eliel: right right, just pointing out that they're not even attempting to use a decenteralized decision.
345 2012-08-20 11:35:13 <Eliel> not quite a contender for bitcoin as it is right now.
346 2012-08-20 11:35:37 <epscy> In order to facilitate the computation of coin age, we introduced a timestamp field into
347 2012-08-20 11:35:39 <epscy> each transaction. Block timestamp and transaction timestamp related protocols are
348 2012-08-20 11:35:41 <epscy> strengthened to secure the computation of coin age.
349 2012-08-20 11:35:50 <epscy> i would like to know more about this
350 2012-08-20 11:35:52 <cande> Eliel, very interesting
351 2012-08-20 11:35:52 <Eliel> even if I like how they implemented the proof-of-stake mining process.
352 2012-08-20 11:36:04 <epscy> i thought the timestamp in bitcoin wasn't very reliable
353 2012-08-20 11:36:10 <sipa> right, it sounds like an interesting experiment
354 2012-08-20 11:37:01 <tonikt> Guys, I've been using the current master branch, built for Win7,64 - I've had no problems  for weeks. but today it stopped working. The debug file shows taht everything is fine but the gui is just completely frozen - just a window's frame with white area inside
355 2012-08-20 11:37:17 <tonikt> Does it tell you anything?
356 2012-08-20 11:37:28 <sipa> tonikt: what's the last thing in debug.log?
357 2012-08-20 11:37:29 <tonikt> The official relese still launches just fine
358 2012-08-20 11:37:48 <tonikt> The log is being written all the time
359 2012-08-20 11:37:55 <tonikt> Seems like the node itself is working
360 2012-08-20 11:38:00 <sipa> ok, so it's just the GUI that is frozen
361 2012-08-20 11:38:00 <tonikt> Only the giu is frozen
362 2012-08-20 11:38:41 <tonikt> I will try to start it in server mode and let you know if RPC works
363 2012-08-20 11:39:09 <sipa> tonikt: if it's reproducible, can you try to find out approximately since what commit it broke?
364 2012-08-20 11:39:41 <tonikt> I use exactly te same code as like 2 weeks ago - and it only stopped working as fo today
365 2012-08-20 11:40:05 <tonikt> The exe has a timestamp of August 5th
366 2012-08-20 11:40:12 <sipa> oh
367 2012-08-20 11:40:19 <tonikt> RPC works just fine
368 2012-08-20 11:40:38 <tonikt> If you want I can change code, add some debugs, and recompile
369 2012-08-20 11:41:20 <tonikt> I think it started happening after I added a new addres to the address book
370 2012-08-20 11:41:29 <tonikt> But it may as well be a coincidence
371 2012-08-20 11:42:27 <sipa> wumpus: can you help tonikt?
372 2012-08-20 11:42:56 <tonikt> to give you an impression it looks like this: http://img52.imageshack.us/img52/6637/clipboard1q.png
373 2012-08-20 11:43:10 <tonikt> but the node itself, including RPC is working just fine
374 2012-08-20 11:45:45 <TD> this "bitparking" that only includes like 8 or 9 transactions is weird
375 2012-08-20 11:45:55 <TD> i wonder what their ruleset is
376 2012-08-20 11:46:31 <tonikt> anyway: it is 100% reproductible ATM, the same exe was workinng for 2 weeks without any problems, and the last official build does not have the issue (lukcily for me ) :)
377 2012-08-20 11:46:58 <sipa> tonikt: and if you move your datadir out of the way, and start from scratch?
378 2012-08-20 11:47:14 <sipa> (don't delete it though, just move it temporarily while bitcoin is not running)
379 2012-08-20 11:47:15 <gmaxwell> might want to have tonikt compile with the deadlock detection
380 2012-08-20 11:47:25 <sipa> good point
381 2012-08-20 11:47:34 <tonikt> how do I swicth it on?
382 2012-08-20 11:47:48 <sipa> add -DDEBUG_LOCKORDER to the compile command line
383 2012-08-20 11:48:00 <tonikt> ok - i will get back to you
384 2012-08-20 11:48:11 <sipa> thanks!
385 2012-08-20 11:52:15 <Eliel> amiller: one thing I've been wondering about. Could it be possible to build a consensus algorithm that's based on detecting the need to resync by comparing current UTXO merkle root hashes between nodes and if they differ, they find the last common ancestor UTXO merkle root and "resync".
386 2012-08-20 11:53:11 <sipa> Eliel: that should be possible
387 2012-08-20 11:54:00 <sipa> but whether it can be done efficiently... unsure, as you'll need quite some roundtrips before the different parts are locates
388 2012-08-20 11:54:10 <Eliel> the hard part is tuning the parameters so that it converges towards whole network agreement with reasonable speed in case there's conflicts.
389 2012-08-20 11:54:36 <tonikt> I can also try building it with gitian on my linux machine. Is there a way to modify the yml file so it takes the HEAD instead of the commit parameter?
390 2012-08-20 11:55:28 <Eliel> 
ACTION wonders if the proof-of-work algorithm could come into play in resolving conflicts and only when resolving conflicts.

391 2012-08-20 11:55:44 <sipa> tonikt: i have a wrapper script around gitian that copies my working dir into the gitian builder, and takes a commit id as command-line argument
392 2012-08-20 11:56:07 <sipa> tonikt: so it can build from any repository you have fetched, and any commit
393 2012-08-20 11:57:40 <sipa> i believe devrandom added support for something similar already in later versions of gitian though
394 2012-08-20 11:57:52 <tonikt> sipa: ok.. can you show me this script?
395 2012-08-20 11:58:04 <sipa> not sure whether it still works, but sec
396 2012-08-20 11:59:52 <sipa> tonikt: http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt
397 2012-08-20 12:00:32 <tonikt> sipa: thx, I will have a look..
398 2012-08-20 12:01:42 <doublec> TD: that's me
399 2012-08-20 12:01:57 <TD> what is you?
400 2012-08-20 12:02:01 <doublec> TD: bitparking
401 2012-08-20 12:02:04 <TD> ah ok
402 2012-08-20 12:02:08 <TD> so why are you including so few transactions?
403 2012-08-20 12:02:22 <doublec> back when satoshidice was causing a large backlog it was causing issues with the pool
404 2012-08-20 12:02:43 <tonikt> with -DDEBUG_LOCKORDER it just crashes right away - before even writing anything to the log file. doesnt even create the data dir after I remove it
405 2012-08-20 12:02:44 <doublec> due to the interaction with merge mining (frequent blocks on an alt chain)
406 2012-08-20 12:02:54 <TD> don't you think 10 txns or less is a bit excessive? why not just go all the way and include no transactions at all like a botnet?
407 2012-08-20 12:02:59 <doublec> resulting in lots of traversals of the transaction list
408 2012-08-20 12:03:09 <tonikt> let me try the gitian build
409 2012-08-20 12:03:25 <sipa> tonikt: what OS?
410 2012-08-20 12:03:29 <doublec> so I have a had a hard limit of transactions in the memorypool
411 2012-08-20 12:03:35 <tonikt> Windows 7 Ultimate, 64 bit
412 2012-08-20 12:03:56 <doublec> rather, I'd limit the working through the pool picking transactions
413 2012-08-20 12:04:11 <doublec> but the limit is set before it applies the other rules for not including transactions
414 2012-08-20 12:04:17 <doublec> so it ends up quite a bit shorter than my limit
415 2012-08-20 12:04:30 <doublec> I've fixed it but haven't restarted my pool since then. it'll be picked up when that happens.
416 2012-08-20 12:07:15 <TD> ok
417 2012-08-20 12:08:09 <doublec> an unfortunate result of a quick fix basically
418 2012-08-20 12:09:02 <gmaxwell> tonikt: what messages does it output/log when it crashes?
419 2012-08-20 12:09:32 <tonikt> It's just a regulat windows crash window
420 2012-08-20 12:09:49 <gmaxwell> tonikt: launch bitcoin-qt from the commandline so you can see its output.
421 2012-08-20 12:11:27 <tonikt> gmaxwell: there is no output - windows starts it and returns to command prompt. in the background the crash windows appread and when i choose to see details I get this: http://pastebin.com/YEZFYYBr
422 2012-08-20 12:11:33 <gavinandresen> So... any reason we can't spin a 0.7 release candidate 1?
423 2012-08-20 12:11:54 <sipa> gavinandresen: let me have quick look at the pullreq list
424 2012-08-20 12:13:10 <gmaxwell> tonikt: anything in the debug.log?
425 2012-08-20 12:13:51 <tonikt> gmaxwell: no - it crashes right away. doesnt even create the data folder after I deleted it
426 2012-08-20 12:14:01 <tonikt> not to mention the debug.log
427 2012-08-20 12:14:20 <sipa> gavinandresen: i would have liked to see #1672, #1647, #1641, #1526 in 0.7 still
428 2012-08-20 12:14:49 <gmaxwell> woops. I forgot to do that refactoring on 1672.
429 2012-08-20 12:15:11 <jgarzik> gavinandresen: as gmaxwell said the other day, the pull reqs on the 0.7 list all seem to require updates.  I'd say go for it.
430 2012-08-20 12:15:28 <jgarzik> there are lists, but without the pull reqs progressing, I think those lists can be ignored, frankly.
431 2012-08-20 12:16:30 <gmaxwell> I'm unhappy about the recent seemingly more frequent reports of stuck nodes, but I've made no progress in identifying the cause.  This is perhaps a sign that we should expect a 0.7.1 to be soon following in any case.
432 2012-08-20 12:16:34 <jgarzik> gavinandresen: ACK sipa's list
433 2012-08-20 12:18:02 <jgarzik> gmaxwell gavinandresen: if you two can add ACKs to sipa's ACK for https://github.com/bitcoin/bitcoin/pull/1641 we can pull that right now
434 2012-08-20 12:18:18 <gmaxwell> WRT stuck nodes:
435 2012-08-20 12:18:19 <gmaxwell> 07:50 < Eliel> it's also saying "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."
436 2012-08-20 12:18:22 <gmaxwell> 07:18 < DrHaribo> Safe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
437 2012-08-20 12:18:25 <gmaxwell> 00:47 < cande> Safe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.
438 2012-08-20 12:18:28 <gmaxwell> 12:47 < question> the message below in the wallet where normally the block counts : Warning : displayed transactions may not be correct ! you may need to upgrade , or other nodes need to upgrad
439 2012-08-20 12:19:22 <TD> gmaxwell: general performance degradation? andreas was telling me bitcoin-qt has become barely usable for him
440 2012-08-20 12:19:43 <sipa> those warnings probably mean a corrupted block...
441 2012-08-20 12:19:47 <sipa> *index
442 2012-08-20 12:20:30 <gmaxwell> Right, but multiple people dying at the sameish point?
443 2012-08-20 12:21:00 <gavinandresen> jgarzik: 1641 acked
444 2012-08-20 12:21:20 <sipa> gmaxwell: weird, indeed
445 2012-08-20 12:21:42 <gavinandresen> sipa: 1647 (child pays for parent) needs very careful code review before pulling
446 2012-08-20 12:21:53 <gavinandresen> (potential DoS attack lurking there)
447 2012-08-20 12:21:59 <sipa> gavinandresen: yes, that's why i haven't acked it myself; but i still would have liked it in 0.7
448 2012-08-20 12:22:11 <sipa> but if that's not doable, skip it for now
449 2012-08-20 12:22:27 <gmaxwell> jgarzik: 1641 you merged it before I could ack, ACK in any case.:)
450 2012-08-20 12:22:42 <sipa> posthumous ack!
451 2012-08-20 12:23:30 <jgarzik> thanks
452 2012-08-20 12:23:38 <jgarzik> as long as gavinandresen is happy with #1526, I am too
453 2012-08-20 12:24:09 <gavinandresen> 1526 might be controversial.... I haven't publicized the change
454 2012-08-20 12:24:28 <jgarzik> gavinandresen: it got discussed on the ML as a BIP
455 2012-08-20 12:24:57 <sipa> not too much discussion, iirc
456 2012-08-20 12:25:03 <gmaxwell> Well, we'd still have the RC time to further discuss it.
457 2012-08-20 12:25:10 <gavinandresen> ok, then I'm happy....
458 2012-08-20 12:25:21 <jgarzik> hrm
459 2012-08-20 12:25:26 <jgarzik> maybe that was private discussion :/
460 2012-08-20 12:25:45 <sipa> if people feel there hasn't been enough discussion, i'd rather wait with merging
461 2012-08-20 12:25:53 <jgarzik> nvm
462 2012-08-20 12:26:03 <jgarzik> I posted it to bitcoin-devel on July 6
463 2012-08-20 12:26:34 <gmaxwell> sipa: I feel that there won't be much discussion because it's a fairly boring change. :)
464 2012-08-20 12:26:41 <jgarzik> indeed
465 2012-08-20 12:26:41 <sipa> right
466 2012-08-20 12:26:54 <gavinandresen> One reason NOT to pull it is if we'd like to bundle in some other change to block.version==2
467 2012-08-20 12:27:06 <gavinandresen> ... but we've got plenty of versions to play with, so that's not a strong reason
468 2012-08-20 12:27:10 <jgarzik> 
ACTION reviews the m-l discussion; no nak's, just some light "why?" discussion

469 2012-08-20 12:27:22 <jgarzik> I say go for it
470 2012-08-20 12:27:40 <gavinandresen> easier to ask forgiveness than permission....
471 2012-08-20 12:27:40 <jgarzik> been out there on wiki and m-l for 2 months
472 2012-08-20 12:28:10 <gmaxwell> For prudence sake there should probably be a reminder about it.
473 2012-08-20 12:28:10 <jgarzik> personally I would like to require that all coinbases be well formed, but let's not block #1526 for that
474 2012-08-20 12:28:28 <gavinandresen> gmaxwell: go for it (post a reminder)
475 2012-08-20 12:29:45 <gmaxwell> gavinandresen: better to do after its merged, but I'll do so.
476 2012-08-20 12:29:49 <gavinandresen> jgarzik: well-formed coinbases sound like a good idea to me... could be part of the AreInputsStandard() check when they get spent......
477 2012-08-20 12:30:45 <sipa> gavinandresen: not the right place to do so, imho
478 2012-08-20 12:31:02 <gmaxwell> (a reminder is less useful if people will continue to ignore it. :) at least if it goes with a merge it'll be clear you can't just ignore it)
479 2012-08-20 12:31:21 <jgarzik> 
ACTION would prefer to do it with the rest of the block checks -- just declare "v3 + invalid coinbase == invalid block"

480 2012-08-20 12:31:26 <sipa> jgarzik: indeed
481 2012-08-20 12:31:31 <jgarzik> or v2 etc.
482 2012-08-20 12:31:37 <gavinandresen> yeah, that's the right way to do it.
483 2012-08-20 12:31:58 <gmaxwell> jgarzik+1. Really, it would make made sense to do it in v2, esp since both are changing the coinbase rules. But, meh. seems too late now.
484 2012-08-20 12:32:01 <sipa> sorry to bring it up again, but when you're using a UTXO set to validate things, you don't have any inputs anymore
485 2012-08-20 12:32:50 <jgarzik> 
ACTION would prefer v2 to require well formed coinbase too :)

486 2012-08-20 12:33:02 <jgarzik> but I agree it (a) seems late and (b) might complicate miner deployment
487 2012-08-20 12:33:28 <sipa> i agree, and i'm fine with postponing that requirement
488 2012-08-20 12:33:36 <sipa> we shouldn't rush something like that
489 2012-08-20 12:33:51 <jgarzik> it definitely breaks a few oddball merged mining setups
490 2012-08-20 12:34:03 <jgarzik> _most_ coinbases remain well formed, which is good
491 2012-08-20 12:34:16 <jgarzik> well over 60%
492 2012-08-20 12:34:23 <sipa> only 60%?
493 2012-08-20 12:34:34 <sipa> wow,  i thought only exceptions used non-well formed coinbases
494 2012-08-20 12:35:00 <jgarzik> sipa: don't read too much into that number, that's just my from-memory number.  it would be much higher if I had real data in front of me
495 2012-08-20 12:35:12 <sipa> ok
496 2012-08-20 12:35:17 <jgarzik> 
ACTION is just being conservative, and doesn't want to claim "90%!" without having checked in 3 weeks

497 2012-08-20 12:35:29 <sipa> right, sure
498 2012-08-20 12:36:08 <jgarzik> whee, I can add "send mempool at startup" code to pynode now
499 2012-08-20 12:36:16 <jgarzik> let's fill that mempool right up
500 2012-08-20 12:40:42 <gavinandresen> 
ACTION fixing unit tests and signed/unsigned warnings for height-in-coinbase pull.....

501 2012-08-20 12:42:53 <roconnor> sipa: what is a well formed coinbase?
502 2012-08-20 12:43:27 <sipa> roconnor: one where the coinbase input is a push-only script
503 2012-08-20 12:48:45 <gavinandresen> 1526 updated; Matt's pull tester will auto-build it fairly soon, yes?
504 2012-08-20 12:48:57 <sipa> it should
505 2012-08-20 12:50:20 <TD> gavinandresen: what's the DoS risk in 1647?
506 2012-08-20 12:50:26 <TD> gavinandresen: just generally more disk load or what?
507 2012-08-20 12:51:10 <gavinandresen> TD: crafting a set of transactions that require O(n^2) time to determine fee or priority
508 2012-08-20 12:52:32 <jgarzik> sipa: "push only" sounds too tight for coinbase.   I was thinking a well-formed coinbase would simply be "all recognized opcodes" (which includes all PUSHDATA opcodes)
509 2012-08-20 12:52:42 <gmaxwell> gavinandresen: that _should_ be addressed by the code giving up after some amount of work, I guess; but it doesn't do that now.
510 2012-08-20 12:53:34 <gavinandresen> gmaxwell: yes, limiting to immediate parents (or some recursive depth limit) would make me more comfortable.
511 2012-08-20 12:53:56 <TD> gavinandresen: surely the work of calculating fees/priority is trivial compared to actually verifying the tx itself
512 2012-08-20 12:54:17 <gmaxwell> TD: I can flood you with unbounded numbers of txn.
513 2012-08-20 12:54:31 <gavinandresen> luke had a bug in a prior version of that code that made it susceptible to a DoS
514 2012-08-20 12:54:31 <TD> yes. but that is already possible
515 2012-08-20 12:54:34 <gmaxwell> and n^2 checking effort has a way of catching up with any constant factor difference.
516 2012-08-20 12:54:41 <TD> oh, ok
517 2012-08-20 12:59:18 <sipa> jgarzik: well, as coinbases are never executed, allowing non-push operations shouldn't be a problem
518 2012-08-20 12:59:39 <sipa> not sure there's too much use for it, though
519 2012-08-20 13:00:04 <jgarzik> sipa: I admit I don't see a use case, but don't want to be overly restrictive and close off possible avenues for experimentation later.
520 2012-08-20 13:00:21 <sipa> agree
521 2012-08-20 13:02:34 <Joric> regarding binary-encoded messages like the last here http://blockchain.info/address/1EMLwAwseowTkDtKnEHRKrwQvzi4HShxSX, will miners process a transaction with several outputs to the _same_ address?
522 2012-08-20 13:04:15 <Joric> maybe it's not possible for some reason i personally don't see why not
523 2012-08-20 13:04:33 <sipa> why would that be a problem
524 2012-08-20 13:04:34 <sipa> ?
525 2012-08-20 13:04:58 <sipa> (i see no reason why that would be a problem)
526 2012-08-20 13:05:35 <Joric> idk someone sent a bunch of tiny transactions to https://blockchain.info/address/1DkyBEKt5S2GDtv7aQw6rQepAvnsRyHoYM it would look better if it was a single tx
527 2012-08-20 13:06:19 <sipa> the "bunch of" and the "tiny" may be a problem, but the same address shouldn't :)
528 2012-08-20 13:07:10 <Joric> another idea for pruning )
529 2012-08-20 13:07:34 <Joric> though i didn't see those transactions in the wild yet
530 2012-08-20 13:07:43 <gavinandresen> Not a problem for miners. The sendmany RPC command won't let you do that, though, so they're non-trivial to create.
531 2012-08-20 13:08:18 <gavinandresen> (actually, does the GUI let you create a bunch of sends to the same address in one transaction?)
532 2012-08-20 13:08:51 <Joric> blockchain.info wallet can construct those just tried it doesn't check outputs
533 2012-08-20 13:10:38 <gmaxwell> gavinandresen: the rpc doesn't dunno about the gui.
534 2012-08-20 13:16:25 <jgarzik> SatoshiDICE IPO'ing, cute: https://bitcointalk.org/index.php?topic=101902.0
535 2012-08-20 13:17:10 <Joric> ppl will get a ton of money to invest today after 22:00 UTC
536 2012-08-20 13:19:47 <gmaxwell> jgarzik: I boggle at that, what terribly evil things do they need a ton of additional coin. Their 7kbtc in profits in the last couple months aren't enough to finance .. what?
537 2012-08-20 13:20:32 <BlueMatt> Luke-Jr/gmaxwell: even I dont use my own dnsseeder any more...
538 2012-08-20 13:20:34 <sipa> maybe they could use it to pay all those who would otherwise stop running a full node because of their bloat?
539 2012-08-20 13:20:42 <Joric> ppl should buy it out and vote for liquidation :D
540 2012-08-20 13:21:19 <BlueMatt> (diversity would be nice, but not at the expense of that crap...)
541 2012-08-20 13:21:30 <jgarzik> 22:00 UTC is pirate payday?
542 2012-08-20 13:21:42 <jgarzik> I predict pirate pays out 25% of BS&T, and then fades away
543 2012-08-20 13:21:54 <jgarzik> enough for people to say "he's paying"
544 2012-08-20 13:22:32 <gmaxwell> Joric: they're only selling 10%, and at remarkably high prices.
545 2012-08-20 13:23:03 <BlueMatt> TD: saw the merge, nice...there are a few others in fullscripts that I never got around to moving that may be interesting, but none of them are too exciting
546 2012-08-20 13:23:08 <BlueMatt> eg "Implement PUSHDATA4 and check max script size in Script.parse"
547 2012-08-20 13:23:13 <TD> ok
548 2012-08-20 13:23:14 <BlueMatt> or "Print any opcode in Script.toString, adding Script.getOpCodeName"
549 2012-08-20 13:23:19 <jgarzik> whee.  pynode is now running protover 60002, and snarfs mempool contents at startup
550 2012-08-20 13:23:23 <TD> if you rebase them i'll take them
551 2012-08-20 13:23:26 <TD> jgarzik: sweet!
552 2012-08-20 13:25:42 <gmaxwell> Joric: assuming their projected revenue of 33,000 BTC/yr, their _lowest_ share price will take about 10 years to pay itself back.
553 2012-08-20 13:26:42 <jgarzik> "The IPO is occurring exclusively on MPEx"  What the heck is MPEx?
554 2012-08-20 13:27:16 <jgarzik> maybe this is an MPEx promo
555 2012-08-20 13:27:33 <sipa> jgarzik: so that's in 5.5 hours?
556 2012-08-20 13:27:40 <sipa> 6.5
557 2012-08-20 13:28:06 <jgarzik> sipa: I dunno, it's what Joric said
558 2012-08-20 13:28:21 <sipa> ah
559 2012-08-20 13:29:13 <jgarzik> (tangent)
560 2012-08-20 13:29:34 <jgarzik> I fear SatoshiDICE has started the trend of using bitcoin as messaging protocol for games
561 2012-08-20 13:29:47 <Joric> http://polimedia.us/bitcoin/mpex.php?mpsic=S.DICE <- mpex
562 2012-08-20 13:30:33 <Joric> that new satoshidice design looks like an ordinary scam site
563 2012-08-20 13:30:57 <wumpus> gavinandresen: no, it doesn't, it gives an error if you try to send to the same address twice in one transaction
564 2012-08-20 13:31:08 <gavinandresen> wumpus: good
565 2012-08-20 13:31:31 <gavinandresen> wumpus: any must-haves on your list for a 0.7 rc1 release?
566 2012-08-20 13:32:05 <wumpus> imo we're ready
567 2012-08-20 13:32:24 <sipa> wumpus: you saw tonikt's problem above?
568 2012-08-20 13:32:27 <wumpus> though we need to merge messages from transifex
569 2012-08-20 13:32:29 <gavinandresen> good.  That means I need to figure out how I broke my OSX Qt build environment.....
570 2012-08-20 13:33:01 <wumpus> sipa: yes, but I don't recognize it
571 2012-08-20 13:33:05 <jgarzik> I hoped that somebody would come up with a distributed, GPG-signed version of GLBSE.  Doesn't look like MPEx is it.
572 2012-08-20 13:33:20 <wumpus> sipa: also have no idea what could cause it
573 2012-08-20 13:34:07 <sipa> wumpus: too bad; hope we get more reports from the RC
574 2012-08-20 13:34:24 <wumpus> he should probably try to interrupt the running process and see where it's stuck
575 2012-08-20 13:34:35 <Joric> help > debug window > information > show command line options is not resizable, it's painful to read
576 2012-08-20 13:35:11 <wumpus> it's a standard qt message box, those are not resizable
577 2012-08-20 13:35:21 <TD> jgarzik: did you read the stuff about distributed bond markets i wrote? if not my talk at the london conf will cover it
578 2012-08-20 13:35:31 <jgarzik> my GLBSE idea:  broadcast orders <somehow>.  sign bitcoin-for-asset + asset-for-bitcoin transaction (a single trade between two parties), and broadcast that.
579 2012-08-20 13:35:36 <TD> bonds and stocks are pretty similar in that respect
580 2012-08-20 13:35:46 <jgarzik> 
ACTION was about to write... "kinda like what TD posted" ;-)

581 2012-08-20 13:35:50 <TD> heh
582 2012-08-20 13:36:45 <wumpus> and that feature is not really worth making a custom window for, it was originally meant only as a workaround for windows when there is no stdout
583 2012-08-20 13:36:53 <jgarzik> anybody can create an asset with X shares, just as easy as creating a new private key.  once created, you cannot change the number of shares for that object, though you can send (trade) them to another party.
584 2012-08-20 13:37:07 <jgarzik> TD: do you have a link?  I read it when first posted, but don't have it handy
585 2012-08-20 13:37:40 <TD> https://bitcointalk.org/index.php?topic=92421.0
586 2012-08-20 13:37:51 <TD> it basically models bonds / stocks as https://en.bitcoin.it/wiki/Smart_Property
587 2012-08-20 13:38:17 <TD> somebody emailed me about a distributed version of GLBSE a while ago
588 2012-08-20 13:38:29 <TD> i explained how to do it but never heard back. a lot of people find distributed app design tough, i think
589 2012-08-20 13:38:33 <TD> vs just throwing together a web app
590 2012-08-20 13:39:40 <jgarzik> TD: making a distributed app also requires a lot of faith for potentially little direct monetary payback :)
591 2012-08-20 13:39:52 <TD> yeah
592 2012-08-20 13:40:04 <TD> i don't think we'll see a lot of distributed apps being written until the assurance contract stuff is worked out
593 2012-08-20 13:40:48 <BlueMatt> great chicken-and-egg problem, that
594 2012-08-20 13:46:31 <BlueMatt> TD: ok, pushed another few useful commits to the top
595 2012-08-20 13:46:50 <BlueMatt> the MPI one is essentially useless until later,  but the ones before it may be good to pull
596 2012-08-20 13:47:13 <TD> this is the fullverif branch still?
597 2012-08-20 13:47:17 <BlueMatt> yea
598 2012-08-20 13:47:27 <TD> got it
599 2012-08-20 13:50:04 <TD> wow
600 2012-08-20 13:50:07 <TD> the openssl thing is obscure
601 2012-08-20 13:50:11 <TD> how did you find out about that?
602 2012-08-20 13:50:18 <BlueMatt> a tx in the chain failed
603 2012-08-20 13:50:44 <TD> fascinating
604 2012-08-20 13:50:52 <BlueMatt> and gmaxwell pointed me to rconnor who pointed me there
605 2012-08-20 13:50:53 <TD> i really worry about people mining on an alternative implementation
606 2012-08-20 13:51:00 <BlueMatt> yea
607 2012-08-20 13:51:02 <TD> really subtle details like this could result in unexpected chain splits
608 2012-08-20 13:51:43 <BlueMatt> yea, I liked gmaxwell's point of, big miners would only mine txes/blocks/etc that passed on multiple implementations
609 2012-08-20 13:51:49 <TD> even if you don't mine, if you're doing full verification on an alt implementation and there's a bug like this you would be disconnected from the network for a while until it's fixed
610 2012-08-20 13:51:53 <TD> hmm
611 2012-08-20 13:51:59 <TD> yeah. chalk it up to mining professonalism
612 2012-08-20 13:52:03 <BlueMatt> heh
613 2012-08-20 13:52:06 <TD> damn, i wish we had a bitcoin-miners-announce mailing list :(
614 2012-08-20 13:52:13 <TD> i don't trust miners to read the forums, there's too much noise there
615 2012-08-20 13:52:30 <sipa> TD: that's not a bad idea, actually
616 2012-08-20 13:52:47 <BlueMatt> we have a bitcoin-announce, dont we? do we use it for anything anyway?
617 2012-08-20 13:53:20 <TD> not sure. a miners only list might encourage more miners to sign up
618 2012-08-20 13:53:26 <denisx> when you say miners you mean pool operators?
619 2012-08-20 13:53:30 <BlueMatt> true
620 2012-08-20 13:53:40 <TD> miners == people who run full bitcoin nodes that vend work
621 2012-08-20 13:53:47 <TD> so pool operators, solo miners, p2pool users
622 2012-08-20 13:54:45 <BlueMatt> first ever good recommendation from amazon: student solutions manual of a book I just bought
623 2012-08-20 13:55:26 <TD> merged, thanks
624 2012-08-20 13:58:28 <Joric> sipa, do you have students btw? PhD implies teaching )
625 2012-08-20 13:58:47 <copumpkin> Joric: not always
626 2012-08-20 13:58:50 <copumpkin> at all
627 2012-08-20 13:58:57 <copumpkin> fortunately or not :P
628 2012-08-20 13:59:01 <sipa> Joric: i did, but i finished in december, and i'm not at the university anymore
629 2012-08-20 13:59:20 <sipa> also, not particularly interesting courses
630 2012-08-20 13:59:33 <tonikt> the new code does not compile with boost 1.47 anymore - right?
631 2012-08-20 13:59:49 <sipa> BlueMatt should know that
632 2012-08-20 13:59:59 <tonikt> checkpoints.cpp:60: error: ?BOOST_REVERSE_FOREACH? was not declared in this scope
633 2012-08-20 14:00:50 <BlueMatt> I wasnt aware of any issues with boost 1.47, in fact, my system is 1.49
634 2012-08-20 14:02:52 <jgarzik> TD: combining the distributed bonds with P2SH might be interesting
635 2012-08-20 14:03:28 <jgarzik> 
ACTION wonders if P2SH might assist in enforcing policy

636 2012-08-20 14:04:00 <tonikt> Do you guys maybe have this boost-win32-1.49.0-gitian2.zip for windows?
637 2012-08-20 14:04:06 <tonikt> It would save me some time
638 2012-08-20 14:04:13 <TD> why?
639 2012-08-20 14:04:18 <TD> afaict P2SH makes things more complicated
640 2012-08-20 14:04:29 <TD> the protocol relies on being able to read outputs to find relevant transactions in the chain
641 2012-08-20 14:04:41 <TD> so you can't use P2SH for those
642 2012-08-20 14:04:49 <Anduck> guys
643 2012-08-20 14:04:54 <TD> (unless you have a separate data store and use txid as the key)
644 2012-08-20 14:04:55 <Anduck> how can i find out network id?
645 2012-08-20 14:05:07 <sipa> Anduck: what is a network id?
646 2012-08-20 14:05:17 <Anduck> blockchain network id or something
647 2012-08-20 14:05:21 <sipa> context?
648 2012-08-20 14:05:25 <Anduck> its different for testnet
649 2012-08-20 14:05:31 <Anduck> and different for real bitcoin blockchain
650 2012-08-20 14:05:42 <TD> do you mean the version byte in addresses?
651 2012-08-20 14:05:48 <sipa> ah, 0 for realnet addresses and 128 for testnet
652 2012-08-20 14:06:20 <jgarzik> 
ACTION still thinks there needs to be an alt-data chain or fast-transaction chain, for trading applications.  Here's an idea: merge-mined chain of small data items, all of which carry an expiration date of no farther than 7 days in the future.  Publish signed messages there, rather than the main bitcoin chain.  Distributed entities + multisig could review the alt-chain contents, and then sign big transactions on the bitcoin network every 60 sec
653 2012-08-20 14:06:43 <BlueMatt> or does he mean the pchMessageStart
654 2012-08-20 14:06:54 <jgarzik> establish a market to compete to be one of these validating signature entities
655 2012-08-20 14:07:21 <TD> you could also just use a DHT
656 2012-08-20 14:07:29 <jgarzik> keeps a lot of data off the bitcoin network, and reduces requirement to trust in a single signing authority.
657 2012-08-20 14:07:31 <TD> no need to be a PoW chain, as far as i can tell, if you just want to publish messages
658 2012-08-20 14:07:53 <jgarzik> heck, require consensus of 7 signing authorities, each validating the bond market rules
659 2012-08-20 14:08:09 <gavinandresen> tonikt: http://www.boost.org/doc/libs/1_37_0/doc/html/foreach.html says BOOST_REVERSE_FOREACH was in 1.37...
660 2012-08-20 14:08:11 <TD> though that said, i think the messages needed for bonds/stocks/funds/etc wouldn't be particularly large anyway, so it may be better to just let people pay the higher fees and then rely on pruning to get rid of them eventually
661 2012-08-20 14:08:53 <jgarzik> TD: if it's successful, I think you want it to be able to scale to do HFT.  signing authorities that bundle transactions together would help mitigate HFT -> bitcoin network resolution.
662 2012-08-20 14:08:57 <BlueMatt> gavinandresen: re: any txn to test the SIGHASH_SINGLE bug? all I know of is https://github.com/bitcoin/bitcoin/pull/1651
663 2012-08-20 14:08:59 <jgarzik> distributed resolution authority
664 2012-08-20 14:09:08 <jgarzik> with real bitcoin money
665 2012-08-20 14:10:00 <jgarzik> TD: thus, it would be nice to design the system to -not- start out dumping every single transaction involving bitcoins into the blockchain, if there is a better alternative
666 2012-08-20 14:10:45 <jgarzik> 
ACTION wonders if SatoshiDICE could be done with multisig + distributed verifiers, and prevent both cheating and collusion

667 2012-08-20 14:11:23 <tonikt> gavinandresen: thanks. 0.6.3 builds just fine in my gitian, but the master branch - still working on it
668 2012-08-20 14:11:29 <gavinandresen> BlueMatt: RE: 1651: I just submitted a pull request for a different way of making unit tests quiet (adding Yet Another fPrintFlag bugged me)
669 2012-08-20 14:11:47 <BlueMatt> sounds good, Ill remove that
670 2012-08-20 14:14:25 <jgarzik> 
ACTION is trying to think generally -- given an application (SD, bond trading) that implies a lot of transactions, is it possible to devise a distributed set of authorities that work together to (a) validate incoming [data | transactions], and (b) bundle together outgoing transactions into network, blockchain friendly packages?  In the far future, I think bitcoin becomes a resolution currency, with activity happening off-network, with settlemen
671 2012-08-20 14:14:52 <BlueMatt> jgarzik: your /me looks f'd up to me...
672 2012-08-20 14:14:52 <TD> i'm not sure it does imply a lot of transactions, necessarily
673 2012-08-20 14:15:05 <BlueMatt> bitcoin.org down for anyone else?
674 2012-08-20 14:15:28 <TD> but at any rate, the tx replacement mechanism was designed to allow HFT, at least that's how satoshi made it appear to me
675 2012-08-20 14:15:35 <TD> BlueMatt: works for me
676 2012-08-20 14:15:50 <jgarzik> BlueMatt: wfm
677 2012-08-20 14:15:54 <BlueMatt> odd
678 2012-08-20 14:15:59 <jgarzik> BlueMatt: what's f'd up about it? :)
679 2012-08-20 14:16:06 <BlueMatt> I see 
ACTION
680 2012-08-20 14:16:22 <BlueMatt> but it looked ok last time
681 2012-08-20 14:17:34 <gavinandresen> 
ACTION sees jgarzik's /me just fine

682 2012-08-20 14:17:43 <BlueMatt> hmm...guess Im having problems then
683 2012-08-20 14:18:15 <jgarzik> TD: I'm not sure that is applicable to all situations.  Each trade is final, with an audit trail often required by law to reflect such.
684 2012-08-20 14:18:58 <TD> i think if these markets ever develop to the point where HFT actually happens, we'll be living in a star trek future and whatever crazy computers we're running will be able to keep up with the transaction rate without issue
685 2012-08-20 14:19:03 <TD> so right now i'm not too worried about it
686 2012-08-20 14:19:30 <jgarzik> with SatoshiDICE > 50% of the network traffic, I'm already worrying about data services riding on the blockchain
687 2012-08-20 14:19:37 <jgarzik> and your spec adds one more :)
688 2012-08-20 14:20:48 <jgarzik> There needs to be a distributed small message data notary service that is not bitcoin :)
689 2012-08-20 14:20:57 <sunshinehappy> could satoshi dice 51%?
690 2012-08-20 14:21:04 <BlueMatt> no
691 2012-08-20 14:21:18 <BlueMatt> different type of 50%
692 2012-08-20 14:21:30 <sunshinehappy> I heard you could double spend on satoshi dice
693 2012-08-20 14:21:35 <sunshinehappy> has anyone proved that in practice?
694 2012-08-20 14:21:36 <amiller> we also need to sort out the fee schedule at some point, i doubt satoshidice provides >50% of fees, especially since we're still in subsidy mode
695 2012-08-20 14:21:58 <jgarzik> amiller: fee != initial block reward
696 2012-08-20 14:22:11 <TD> i wouldn't describe satoshidice as a "data service"
697 2012-08-20 14:22:13 <jgarzik> amiller: it is conceivable that SD provides >50% of all fees
698 2012-08-20 14:22:16 <TD> those are real bitcoin transactions that move money around
699 2012-08-20 14:22:25 <BlueMatt> sunshinehappy: yes, there are theoretical attacks because of the way sd does tx handling, in practice, I haven't seen anything
700 2012-08-20 14:22:25 <jgarzik> TD: it sends 1 satoshi to notify you of losing bets
701 2012-08-20 14:22:29 <jgarzik> :(
702 2012-08-20 14:22:34 <TD> oh, ok
703 2012-08-20 14:22:46 <TD> those transactions must take forever to confirm
704 2012-08-20 14:23:10 <TD> i think over time bitcoinj will help people write customized clients for that kind of thing
705 2012-08-20 14:23:18 <jgarzik> or pynode :)
706 2012-08-20 14:23:25 <TD> there's no particular reason to use bizarre in-band messaging protocols. it's done that way because modfiying satoshis code is too complicated
707 2012-08-20 14:23:27 <TD> yes or pynode
708 2012-08-20 14:23:32 <jgarzik> </plug>
709 2012-08-20 14:23:34 <jgarzik> :)
710 2012-08-20 14:24:06 <gavinandresen> mmmm... pie....
711 2012-08-20 14:25:46 <jgarzik> I'll try to think some more on a distributed stock/bond trading market.  It does seem to me to be doable simply by requiring X "authority agents" to all validate rules, and then sign multisig transactions that transfer bitcoins from Alice to Bob, after agreeing that 100 shares of FOO stock was transferred from Bob to Alice.
712 2012-08-20 14:26:33 <jgarzik> the impact to the bitcoin blockchain would be fewer, larger transactions settling up with Alice and Bob at the end of the day
713 2012-08-20 14:26:44 <jgarzik> or s/day/$TimePeriod/
714 2012-08-20 14:27:10 <jgarzik> if Alice and Bob are HFT'ing, that is a _lot_ of intermediate bitcoin transfers back and forth that simply do not appear in the blockchain
715 2012-08-20 14:27:33 <TD> did you read the post i wrote? you can model a bond transfer as a regular transaction. the client can then calculate whether bond issuers are keeping up with their payments or not by scanning the block chain looking for the payments to the ownership key
716 2012-08-20 14:27:47 <TD> i didn't need any authority agents in the design posted on the forum
717 2012-08-20 14:27:57 <TD> (well except for distributed investment funds, but that's different)
718 2012-08-20 14:28:01 <amiller> sipa, do you have any thoughts about the size of the UTXO-set over time? do you think of it as something that stabilizes to a bounded size, or something that grows linearly with time?
719 2012-08-20 14:28:20 <jgarzik> TD: yes, that's the tradeoff.  lack of authority agents == much greater blockchain spam.
720 2012-08-20 14:28:41 <TD> i don't see why. selling a bond to somebody else requires a financial transfer anyway (assuming you actually pay in bitcoins)
721 2012-08-20 14:28:45 <Joric> TD, i'm going to write bitcoin j2me app for ancient phones, any advice? :) sold 6 j2me games in the last decade but market seems dead now
722 2012-08-20 14:28:46 <TD> so all you need is an extra output
723 2012-08-20 14:28:55 <TD> Joric: er, don't do it? why would you want to do that?
724 2012-08-20 14:29:10 <TD> Joric: i think a bitbank frontend type app is the only possibility there
725 2012-08-20 14:30:03 <jgarzik> TD: see what I just wrote, above.  if some parties are doing a large number of transactions, all those bitcoin transactions could be kept off-network and collated into a few resolution transactions at the end of the day.
726 2012-08-20 14:31:18 <sipa> amiller: hard to guess
727 2012-08-20 14:31:55 <TD> then it's not a distributed market though. you may as well just use GLBSE. using miners to enforce the ruleset is how you make it distributed
728 2012-08-20 14:32:10 <sipa> amiller: if the exchange rate increases, smaller transactions become viable and necessary, so the degree to which amounts are split out over UTXO's would rise
729 2012-08-20 14:32:21 <Joric> i wonder how much time it would take for sigining a transacion :D those phones are slow as hell
730 2012-08-20 14:32:35 <jgarzik> TD: it is a distributed market if you require X independent agents to validate and resolve your stock market transactions
731 2012-08-20 14:33:00 <TD> Joric: don't sign on the phone ....
732 2012-08-20 14:33:03 <amiller> but the rate at which UTXOs are spent would also rise
733 2012-08-20 14:33:26 <amiller> would you say the rate of UTXOs spent would match the rate of UTXOs created?
734 2012-08-20 14:33:43 <sipa> the size of the UTXO set is definitely increasing right now
735 2012-08-20 14:33:48 <sipa> but not that quickly
736 2012-08-20 14:34:03 <sipa> i've seen it grow from 70 to 80 MiB in the last 2 months or so
737 2012-08-20 14:34:16 <jgarzik> TD: create transactions that require X multisig signatures, and then use a known "bond chain" and "bond P2P network" that signing authorities listen on
738 2012-08-20 14:34:34 <jgarzik> sipa: what is UTXO?
739 2012-08-20 14:35:03 <gavinandresen> unspent transaction output
740 2012-08-20 14:35:03 <TD> i'd rather just scale the core transaction processing to support lots of transactions
741 2012-08-20 14:35:27 <jgarzik> but there is no need to crap up the main chain with this extra data
742 2012-08-20 14:35:34 <TD> over time i'm getting less enamoured of having separate networks and chains for financially related things. for stuff that's not financial like DNS or SSL certs or whatever, sure
743 2012-08-20 14:36:23 <TD> i think over time people will get less sensitive about block chain size and tx rates
744 2012-08-20 14:36:40 <TD> as the core code gets better. with better db usage, multi-threaded tx verification, sharded/offloaded signature verifications and so on
745 2012-08-20 14:36:45 <amiller> jgarzik, if it's 200 years in the future and there's no initial block reward, then it makes sense if 50% of the network pays 50% of the fees
746 2012-08-20 14:37:03 <amiller> the initial blockreward is giving satoshidice a free ride
747 2012-08-20 14:37:12 <jgarzik> even with ultraprune, scaling up to a paypal or Visa level of transactions will ultimately require a lot of bandwidth and data storage, regardless of how prunable the data is.
748 2012-08-20 14:37:32 <jgarzik> designing non-currency-related data applications to piggyback makes the problem worse
749 2012-08-20 14:37:50 <TD> i need to rewrite the scalability page to take into account the latest developments
750 2012-08-20 14:38:09 <jgarzik> amiller: agreed
751 2012-08-20 14:38:12 <TD> i guess i don't see it as a big deal. with the recent improvements and corrections to the numbers on that page it seems like 10ktps is quite achievable by a single studly server
752 2012-08-20 14:38:21 <TD> and the bandwidth usage isn't a big deal for anything sitting in a datacenter
753 2012-08-20 14:38:58 <jgarzik> yes -- it implies at that point that only [a few] studly servers on studly connections are supporting the bitcoin network :)
754 2012-08-20 14:39:17 <sipa> i think the most important effect of ultraprune is that it allows separation between blockchain-storage/serving and transaction validation
755 2012-08-20 14:39:19 <gavinandresen> I agree with TD.  And I think "a few" will actually be "hundreds", which is plenty.
756 2012-08-20 14:39:52 <sipa> storage and bandwidth are cheap, but not what every end-user or even merchant wants to do
757 2012-08-20 14:40:11 <TD> by "studly server" i mean something like a 24 core machine with a bunch of hard disks attached
758 2012-08-20 14:40:19 <TD> hardly out of reach even for hobbyists, assuming they have a job
759 2012-08-20 14:40:22 <TD> and that's with todays tech
760 2012-08-20 14:41:11 <TD> at any rate
761 2012-08-20 14:41:22 <TD> i'd rather start with simple designs and evolve them later if the scalability starts to hurt
762 2012-08-20 14:41:35 <jgarzik> <shrug> oh well.  If you don't discourage blockchain-as-general-messaging and blockchain-as-general-data-storage, that is what it will devolve into.
763 2012-08-20 14:41:41 <TD> remember that when satoshi was designing bitcoin he thought it was just on the boundary of feasability and thought scalability would be the biggest achilles heel
764 2012-08-20 14:41:46 <TD> over time it hasn't proven to be such a big deal as he thought
765 2012-08-20 14:42:07 <TD> i'm not saying use the block chain for things like SDs 1 satoshi messages
766 2012-08-20 14:42:18 <TD> that's clearly just abusing the broadcast network because they don't have a real client of their own
767 2012-08-20 14:42:31 <sipa> jgarzik: i think it's a bad thing that our only way of transferring a transaction from sender to receiver, is *via* the blockchain
768 2012-08-20 14:42:36 <TD> for things like a bond where you want the act of payment to be atomic with transfer of control, it's a natural fit for the block chain
769 2012-08-20 14:42:43 <sipa> hard to prevent people from seeing it as a communication channel
770 2012-08-20 14:42:45 <TD> other solutions end up being weird and awkward, or at least a lot more complicated
771 2012-08-20 14:44:29 <amiller> satoshidice needs to be kept out of the UTXO :/
772 2012-08-20 14:44:31 <TD> basically for smart property, it makes sense to encode the data into an output because that assures atomicity. now whether it makes sense to encode that data directly as a script chunk, or as a hash that keys into some other data storage mechanism, i don't know
773 2012-08-20 14:44:35 <amiller> no one's gonna spend that junk
774 2012-08-20 14:44:49 <TD> i started out by thinking it has to be a hash poiner. now i think it'll matter less
775 2012-08-20 14:45:38 <BlueMatt> how much of its own utxo has sd spent? if they went and spent all their utxo to one tx, would it make a big difference?
776 2012-08-20 14:46:02 <amiller> who are those 1 satoshi messages sent _to_?
777 2012-08-20 14:46:03 <amiller> the loser?
778 2012-08-20 14:46:08 <BlueMatt> yea
779 2012-08-20 14:46:22 <amiller> so SD can't spent them theirselves, its up to the clients who have no motivation to do so
780 2012-08-20 14:46:40 <TD> er, a wallet implementation will use whatever coins it has lying around eventually
781 2012-08-20 14:46:45 <TD> you can't assume they'll never be spent
782 2012-08-20 14:47:00 <BlueMatt> amiller: I mean the winings that sd has accumulated from losers
783 2012-08-20 14:47:16 <BlueMatt> not those sent back to losers/winners
784 2012-08-20 14:47:25 <amiller> i'm assuming they _might_ never be spent, and that's a problem if it's generally accepted that the UTXO shouldn't grow linearly
785 2012-08-20 14:58:56 <gavinandresen> RE: unspent satoshi outputs:  for 0.8 I want to tweak the coin selection and fee code. Assuming miners adopt the sort-by-fee changes in 0.7, we should be able to get rid of the "single satoshi outputs cost MIN_FEE to spend" rule, and make the coin selection code include a couple of small inputs to minimize UTXO
786 2012-08-20 15:00:46 <gmaxwell> They don't cost minfee to spend, they cost minfee to create.
787 2012-08-20 15:01:16 <gmaxwell> The 'problem' now is that adding additoinal inputs for pure txout sweeping purposes lowers your priority. Cleaning up the chain is against your interest.
788 2012-08-20 15:02:09 <gmaxwell> (they lower your priority because they make the txn smaller)
789 2012-08-20 15:02:11 <gavinandresen> Right, the client code would do something like "add a tiny input if it won't hurt your priority/fee"
790 2012-08-20 15:02:37 <gavinandresen> (or won't hurt it enough to significantly change chances of getting into next block)
791 2012-08-20 15:03:02 <gavinandresen> I'm still planning on writing code to estimate how long it will take a given transaction to get into a block.....
792 2012-08-20 15:03:23 <jgarzik> note if you need extra data validation for your OP_DROP data, that's a required authority (since bitcoin is not validating your rules)
793 2012-08-20 15:03:30 <amiller> gmaxwell, you should say cleaning up the UTXO rather than cleaning up the chain, since there's no way to clean the chain (it's append only)
794 2012-08-20 15:03:34 <TD> one thing i've wanted to do for a while (but won't get to for ages) is write background cleaning/aggregation code for bitcoinj, so the android wallet can consolidate outputs at night time when the user is asleep
795 2012-08-20 15:03:37 <gmaxwell> right, someplace I have code for this ??? but when I used it it caused all the addresses in my wallet to get linked right away, the loss of privacy seemed bad.
796 2012-08-20 15:04:08 <TD> jgarzik: the data that's dropped, at least in my designs, is validated by each users client rather than some kind of authority.
797 2012-08-20 15:04:13 <gmaxwell> TD: "Meh" I don't like that??? it should do most of that in actual transactions.
798 2012-08-20 15:06:32 <gavinandresen> gmaxwell: privacy concern is a good point... although I think users with lots of tiny transactions in their wallets might not care.
799 2012-08-20 15:07:10 <gmaxwell> gavinandresen: my hope was that this address group code would solve it. (only pull in things with the already linked groups).  But now after actually working with the code, I don't like it.
800 2012-08-20 15:07:15 <sipa> trying to add small inputs as long as it's harmless may help a bit, but a more final solution should effectively increase priority or lower cost, when it consumes many txins
801 2012-08-20 15:07:41 <gmaxwell> A short term improvement would be to only add inputs which are from the same addresses as the inputs that are already there.
802 2012-08-20 15:07:49 <gmaxwell> It's not very general but it would work very well with the dice spam.
803 2012-08-20 15:07:58 <gmaxwell> And it's both privacy safe and computationally cheap.
804 2012-08-20 15:09:40 <gmaxwell> e.g. iff there is spare fee/priority AND there is already a change output, collect a list of other outputs to the inputs the txn used, sort by value least to most, and add the least value one one at a time until there is no more "free" space.
805 2012-08-20 15:17:57 <Joric> next difficulty estimate +11%
806 2012-08-20 15:18:28 <Joric> 4 days left
807 2012-08-20 15:19:35 <TD> if pubsub was activated the network could be used to find people who also wanted to combine their wallets
808 2012-08-20 15:19:43 <TD> and then a shared transaction would merge and split across multiple peers
809 2012-08-20 15:19:49 <TD> effectively an automatic p2p mixing service
810 2012-08-20 15:23:37 <gmaxwell> TD: meh, thats not actually useful without an anonymity network in between.
811 2012-08-20 15:23:39 <gavinandresen> TD: somebody could use the raw transactions API to create such a service
812 2012-08-20 15:23:54 <gavinandresen> (run through tor maybe....)
813 2012-08-20 15:23:58 <gmaxwell> gavinandresen: it still needs the ability to put pending outputs on hold. :)
814 2012-08-20 15:24:30 <gavinandresen> gmaxwell: true, locking unspent outputs should get implemented.
815 2012-08-20 15:24:57 <TD> ?
816 2012-08-20 15:26:05 <gavinandresen> when you're in the middle of gathering signatures for an anonymizing send-to-selves transaction there's nothing currently stopping somebody from creating another transaction (using the GUI maybe) that accidently double-spends some of the inputs involved
817 2012-08-20 15:29:29 <genjix> TD: why would mix and matching help scalability in any significant way? from what i understand, the spends and outputs would remain the same except there would be fewer transactions now.
818 2012-08-20 15:31:23 <TD> gavinandresen: yes, but does it matter? if that happens you restart the protocol
819 2012-08-20 15:31:30 <TD> genjix: because it'd shrink the working set
820 2012-08-20 15:32:23 <genjix> but that's hardly a bottleneck currently.
821 2012-08-20 15:32:39 <genjix> unless i'm missing something?
822 2012-08-20 15:32:53 <gavinandresen> TD: I think you're right, it shouldn't matter. The protocol will have to handle double-spends to be robust anyway.
823 2012-08-20 15:32:53 <TD> we're thinking long term
824 2012-08-20 15:32:54 <TD> 
ACTION -> home

825 2012-08-20 15:32:59 <genjix> ah ok
826 2012-08-20 15:48:22 <gmaxwell> sipa: https://github.com/bitcoin/bitcoin/pull/1672 Is that what you wanted me to do wrt the wallet class?