1 2011-08-05 00:14:29 <Blitzboom> what have the devs to say to this? http://www.slideshare.net/dakami/bitcoin-8776098
  2 2011-08-05 00:30:34 <lfm> Blitzboom: I am on page 8 and it looks good so far. do you have questions about it?
  3 2011-08-05 00:30:42 <Blitzboom> yes
  4 2011-08-05 00:30:52 <Blitzboom> if the end result is the same shit as banks, what is the use of bitcoin?
  5 2011-08-05 00:31:20 <Blitzboom> you have trusted parties and central points of failur
  6 2011-08-05 00:31:21 <Blitzboom> e
  7 2011-08-05 00:31:44 <lfm> end result? I guess I havnt got that far
  8 2011-08-05 00:32:06 <Blitzboom> ive always had that thought, but it needs to be empirically tested
  9 2011-08-05 00:32:30 <Blitzboom> that as bitcoin progresses, it becomes more and more structurally like the old establishment
 10 2011-08-05 00:33:06 <lfm> ok I see one false assumption. He thinks bitcoin can replace creditcards. It obviously cannot
 11 2011-08-05 00:35:12 <gmaxwell> it's really kinda shitty that a lot of people's first introductions to bitcoin was via someone who has had no major involvement
 12 2011-08-05 00:36:03 <Blitzboom> gmaxwell: do you have something to add to kaminsky?
 13 2011-08-05 00:36:34 <luke-jr> Blitzboom: that's why I'm so vocal about "there's no official"
 14 2011-08-05 00:36:40 <gmaxwell> It's borderline unethical to stand up at a conference in front of a lot of people and present a technical analysis as fact without having first exposed it to peer review, but it wouldn't be the first time Kaminsky has been accused of being unethical.
 15 2011-08-05 00:36:52 <lfm> He sez the peer-to-peer model goes away when bitcoin gets big. well, thats that assumptionagain that bitcoin will be or should be used like credit cards
 16 2011-08-05 00:37:11 <gmaxwell> He makes a bunch of points which I've routinely slayed on IRC.
 17 2011-08-05 00:37:23 <gmaxwell> "Bad Choice Of Hash Standard
 18 2011-08-05 00:37:24 <gmaxwell> Could have been bcrypt or the like, in which performance does not scale with pure processing speed"
 19 2011-08-05 00:37:27 <gmaxwell> crap like that
 20 2011-08-05 00:37:45 <gmaxwell> If bitcoin wasn't being used on GPUs today it would be _completely_ controlled by botnets now.
 21 2011-08-05 00:38:04 <RealSolid> whats wrong with botnets
 22 2011-08-05 00:38:25 <gmaxwell> The merits one way or another are debatable, but to just express it like "oops they obviously fucked this up" is bad science.
 23 2011-08-05 00:38:29 <Blitzboom> gmaxwell: could you provide those with regard to kaminsky? thx
 24 2011-08-05 00:39:19 <lfm> RealSolid: ok, should we put you down as a fan of botnets?
 25 2011-08-05 00:39:37 <RealSolid> lfm: in the context of bitcoin, if they get the job done they get the job done
 26 2011-08-05 00:39:46 <luke-jr> gmaxwell: only a matter of time until botnets use GPUs
 27 2011-08-05 00:39:50 <RealSolid> bitcoin shouldnt be judging how the hashing power gets there
 28 2011-08-05 00:40:11 <lfm> doesnt mean we have to like botnets
 29 2011-08-05 00:40:16 <Blitzboom> lfm: then we use fpgas
 30 2011-08-05 00:40:21 <Blitzboom> err luke-jr
 31 2011-08-05 00:40:21 <luke-jr> RealSolid: you don't need mining to get the job done
 32 2011-08-05 00:40:39 <luke-jr> RealSolid: mining is just a trick to force you to slow down, and distribute new coins "diversely"
 33 2011-08-05 00:40:44 <gmaxwell> Blitzboom: Why? He's obviously interested more in making a splash than factual/scientific accuracy. It would be a waste of my time. At best I'd manage to piss him off and leave him attacking me.
 34 2011-08-05 00:41:19 <RealSolid> luke-jr: a lot of people believe the higher difficulty the more secure bitcoin is
 35 2011-08-05 00:41:33 <Blitzboom> gmaxwell: so i know what to think of it
 36 2011-08-05 00:42:05 <luke-jr> RealSolid: the higher the diversity, really. it is ASSUMED that higher difficulty results in higher diversity.
 37 2011-08-05 00:42:15 <gmaxwell> To his credit at least it says "This isnt 0day stuff, this is basically declared almost entirely up front"
 38 2011-08-05 00:42:18 <upb> lol typical kaminsky
 39 2011-08-05 00:42:28 <luke-jr> in practice, we find that higher difficulty results in lower diversity
 40 2011-08-05 00:42:28 <upb> it was dns, now its bitcoin
 41 2011-08-05 00:46:08 <lfm> ya he throws in a few of what he thinks are backhanded complements. He makes a big mistake tho thinking bitcoin will or can ewplcae credit cards
 42 2011-08-05 00:51:47 <upb> http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011
 43 2011-08-05 00:51:53 <upb> this is his main talk
 44 2011-08-05 00:52:38 <upb> apparently he embedded a bunch of shit into the chain
 45 2011-08-05 00:53:16 <luke-jr> woop de do
 46 2011-08-05 00:53:29 <luke-jr> I think everyone noticed that when it happened
 47 2011-08-05 01:05:06 <gmaxwell> A am pleased that he spent enough time the he reached the "The first five times you think you understand it, you dont"
 48 2011-08-05 01:05:14 <gmaxwell> point. :)
 49 2011-08-05 01:05:47 <bliket_> how many inputs does a transaction have to have to make it too complex to send free?
 50 2011-08-05 01:07:19 <gmaxwell> "it depends"
 51 2011-08-05 01:07:35 <draginx> how does the bitcoin network trim blocks for data xsfers?
 52 2011-08-05 01:07:52 <gmaxwell> bliket_: it's too complex to send free if its priority is too low, or if its over a kilobyte in size, or if it has outputs smaller than 0.01.
 53 2011-08-05 01:08:05 <draginx> reason why I ask: http://www.slideshare.net/dakami/bitcoin-8776098
 54 2011-08-05 01:08:26 <gmaxwell> draginx: without flash I can't tellwhat slide you're pointing to.
 55 2011-08-05 01:08:46 <draginx> theres only one slide O_o
 56 2011-08-05 01:09:40 <gmaxwell> draginx: No, you're pointing to one slide in a deck, which I can't see without flash. So tell me what it says.
 57 2011-08-05 01:10:39 <bliket_> gmaxwell: how do i know what priority my transaction is?
 58 2011-08-05 01:11:12 <bliket_> or my would be transaction, rather
 59 2011-08-05 01:11:22 <gmaxwell> bliket_: https://en.bitcoin.it/wiki/Transaction_fees#Technical_info  and IIRC it's actually logged in debug log when it tries to form a txn, the UI could make this more transparent.
 60 2011-08-05 01:11:31 <draginx> gmaxwell: it's a bit&.in-depth =/
 61 2011-08-05 01:12:30 <gmaxwell> draginx: presumably if you have a question you can just ask it rather than pointing a some on the internet?
 62 2011-08-05 01:12:56 <draginx> Well I did ask my question..
 63 2011-08-05 01:13:06 <draginx> "how does the bitcoin network trim blocks for data xsfers?"?
 64 2011-08-05 01:13:09 <gmaxwell> I didn't understand your question.
 65 2011-08-05 01:13:31 <lfm> bliket_: mostly if you pay a fee you are top priority
 66 2011-08-05 01:13:32 <draginx> basically how does the large massive bandwidth of data (blocks) not become a problem especially for newcomers?
 67 2011-08-05 01:13:45 <gmaxwell> draginx: Ah!
 68 2011-08-05 01:13:53 <gmaxwell> draginx: because not all nodes have to have all the data.
 69 2011-08-05 01:14:03 <lfm> draginx: what large massive bandwidth? is none
 70 2011-08-05 01:14:13 <draginx> lfm: for now but later down the road..
 71 2011-08-05 01:14:14 <gmaxwell> draginx: bitcoin was designed to facilitate light clients which only know the block headers (a few MB of data per year)
 72 2011-08-05 01:14:23 <lfm> draginx: wont be
 73 2011-08-05 01:14:25 <draginx> hmm
 74 2011-08-05 01:14:36 <draginx> gmaxwell: how do I get this light client? Because it takes me eons to catch up on blocks :p
 75 2011-08-05 01:15:10 <gmaxwell> draginx: BitcoinJ is a light client but the "official client" is not, because it hasn't really been needed.
 76 2011-08-05 01:15:14 <lfm> draginx: doesnt exist yet cuz its not needed (except you and you dont count)
 77 2011-08-05 01:15:22 <draginx> lol
 78 2011-08-05 01:15:25 <draginx> aye i see
 79 2011-08-05 01:15:43 <gmaxwell> draginx: the slowness of catching up right now doesn't really have anything to do with the size, it's slow because its difficulty to connect to nodes that will feed it to you without hanging up on you.
 80 2011-08-05 01:15:44 <draginx> ok thanks! :) in the slide the guy says eventually we'll need official nodes so to speak (or "banks")
 81 2011-08-05 01:16:12 <gmaxwell> draginx: If it says that its incorrect.
 82 2011-08-05 01:16:19 <lfm> draginx: dont beleive everything you read
 83 2011-08-05 01:16:44 <draginx> lfm: I didnt but i did want to get my facts stright hence going on here :)
 84 2011-08-05 01:16:51 <gmaxwell> Eventually full nodes will be too costly to operate for every single bitcoin user to run them, so most users will run lite clients or partially lite clients.  But that doesn't make the full ones "official"
 85 2011-08-05 01:17:07 <lfm> draginx: he says bitcoin will replace creditcards. it wont.
 86 2011-08-05 01:17:09 <draginx> gmaxwell: what would be the diff besides the light headers?
 87 2011-08-05 01:17:18 <draginx> lfm: it should :( lol
 88 2011-08-05 01:17:36 <lfm> dream on.
 89 2011-08-05 01:17:59 <gmaxwell> draginx: full nodes have to see all the bitcoin transactions, instead of just the headers. Which means they will eventually need megabits of connectivity and terrabytes of disk space if bitcoin continues to grow.
 90 2011-08-05 01:18:11 <lfm> it wont partly cuz of the reasons he sez. it cant really
 91 2011-08-05 01:18:21 <gmaxwell> draginx: it can't really the transaction settling times means bitcoin will never be a credit card replacement by itself.
 92 2011-08-05 01:18:30 <gmaxwell> (not to mention scaling limits.
 93 2011-08-05 01:18:32 <gmaxwell> )
 94 2011-08-05 01:19:08 <gmaxwell> But you can build credit card systems on top of bitcoin that only settle periodically (e.g. daily) using traditional means (like visa) or via distributed means (like ripple)
 95 2011-08-05 01:19:42 <lfm> ya, nothing would stop real banks from starting to deal in bitcoins if they want to.
 96 2011-08-05 01:19:50 <gmaxwell> E.g. bitcoin becomes the better-gold of a digital currency ecosystem better than gold because it's still a lot easier (and more secure) than gold, but not something you'd use for every sodapop you buy.
 97 2011-08-05 01:19:57 <draginx> right
 98 2011-08-05 01:20:08 <draginx> just drugs! :P jk but srsly >.> :p
 99 2011-08-05 01:20:19 <lfm> they dont take over tho. they are just another user
100 2011-08-05 01:20:21 <draginx> so the light clients will still be able ot xsfer coins
101 2011-08-05 01:20:23 <draginx> which si good
102 2011-08-05 01:20:45 <gmaxwell> In theory if you squint just right, bitcoin could just barely scale up to replace credit cards, which makes people think that it will.  But it's really a poor fit.  It's more like a replacement for checks, wire transfers, and gold bars.
103 2011-08-05 01:21:15 <gmaxwell> draginx: oh sure, lite clients will run fine they just won't be contributing to the security of bitcoin overall.
104 2011-08-05 01:21:46 <draginx> :)
105 2011-08-05 01:21:54 <draginx> well personally id like ot see btc replace CC
106 2011-08-05 01:22:01 <draginx> no transaction fees (are smaller fees)
107 2011-08-05 01:22:03 <draginx> or*
108 2011-08-05 01:22:40 <nanotube> gmaxwell: well, bitcoin /can/ replace cc for online purchases, where a little delay in processing is fine.
109 2011-08-05 01:23:16 <gmaxwell> draginx: Nah. Bitcoin is the competition which will make future CC's and things like paypal not suck. It will replace them for somethings, but not for others.
110 2011-08-05 01:23:21 <nanotube> also, for POS-like stuff, can just rely on payment processors... but they'll of course want fees... and it remains to be seen if the bitcoin payment processors will want lower fees than the current CC guys :)
111 2011-08-05 01:23:43 <draginx> :)
112 2011-08-05 01:23:44 <gmaxwell> nanotube: yes, bitcoin is a fine replacement for CC's where CC's are really being used as crappy proxies for checks and wiretransfers.
113 2011-08-05 01:23:53 <nanotube> yea a little competition will do this market well.
114 2011-08-05 01:25:01 <gmaxwell> You can think of bitcoin as a replacement for a bunch of things that CC's replace poorly.  It's not really a replacement for CCs or instant payment services, but compeition from bitcoin and bitcoin spawned alternatives will make those things more effective.
115 2011-08-05 01:25:34 <nanotube> indeed
116 2011-08-05 01:25:39 <gmaxwell> For example, there is a nice thread on the form about using ripple-esq settlment to do fast transactions backed in bitcoin: http://bitcointalk.org/index.php?topic=28565
117 2011-08-05 01:26:18 <gmaxwell> The idea being that you can use some other protocol based on pairwise trusts to exchange IOUs which you periodically/eventually settle with bitcoin.
118 2011-08-05 01:27:09 <gmaxwell> This would make transactions fast (though a bit less secure than bitcoin: you have to have some trusted parties while bitcoin is trust-no-one), and it would remove traffic from the bitcoin network (letting bitcoin support more users without becoming too costly to operate)
119 2011-08-05 01:29:20 <nanotube> gmaxwell: yes, now replace 'bitcoin' with 'dollars' and 'fast verification nodes' with 'banks'... and we already have an implementation, i think :)
120 2011-08-05 01:30:27 <gmaxwell> Indeed, though the ripple system is a design that can make everyone a bank. (dunno how well it work work in practice)
121 2011-08-05 01:33:01 <gmaxwell> e.g. you have pairwise trust (a trusts b, b trusts c, etc). Ripple finds a path in order to build an IOU chain securely. If someone cheats only the party with the stupidly placed trust is screwed.  Then you just shim that up to bitcoin to automatically settle. And you could do things like had the party who is trusting you a transaction as proof of your intent and probable ability to pay, but they let you keep updating it until it comes time t
122 2011-08-05 01:50:58 <nanotube> gmaxwell: your msg got cut off at 'come time t'
123 2011-08-05 01:51:47 <nanotube> also, i know how ripple works, and am a big fan, generally. it may actually work quite well in a commercial setting.
124 2011-08-05 01:51:56 <nanotube> though possibly not so well in a personal one.
125 2011-08-05 01:52:39 <nanotube> (i.e. you probably won't want to stick your friend with the bill if some credit routed through him fails.)
126 2011-08-05 01:54:14 <gmaxwell> until it comes time to settle.
127 2011-08-05 01:55:11 <upb> haha or 'until it comes time t' :D
128 2011-08-05 01:55:49 <cjdelisle> "finds a path in order to build an IOU" that's kind of the problem, routing algorithms are complicated and don't scale well.
129 2011-08-05 01:56:11 <nanotube> cjdelisle: well, as long as it can find "a reasonable path" it doesn't have to be necessarily "the best path"
130 2011-08-05 01:56:59 <cjdelisle> yea but even that means "link state updates" need to be broadcast globally which is D:
131 2011-08-05 01:57:46 <nanotube> reminds me of bitcoin :)
132 2011-08-05 01:57:52 <nanotube> where tx have to be broadcast globally :P
133 2011-08-05 01:58:11 <gmaxwell> cjdelisle: routing in small world graphs is trivial if you don't actually need to be sure you always have the shortest path.
134 2011-08-05 01:58:29 <luke-jr> ;;bc,stats
135 2011-08-05 01:58:32 <gribble> Error: 'HTTP Error 503: Service Unavailable' is not a valid integer.
136 2011-08-05 01:58:35 <luke-jr> nanotube: they don't *have* to be
137 2011-08-05 01:58:50 <cjdelisle> "small world graphs?"
138 2011-08-05 01:59:16 <gmaxwell> things like google maps wouldn't work if routing was, _that hard_, and road networks have much lower average order than business trust, I assume.
139 2011-08-05 01:59:31 <gmaxwell> cjdelisle: http://en.wikipedia.org/wiki/Small-world_network
140 2011-08-05 02:00:12 <cjdelisle> hmm
141 2011-08-05 02:00:29 <gmaxwell> in fact, purely random routing doesn't work too terribly in small world graphs.
142 2011-08-05 02:02:51 <gmaxwell> (there are fun games for kids where you write up an letter to "random person if city, country" and just hand it to a random friend and ask them to pass it via friends to the destination. This apparently works.)
143 2011-08-05 02:06:14 <cjdelisle> If you pass the letter to someone near by to you and they pass it to someone neatby to them who happens to have a friend living in X country and sends it to them then they continue passing it along, it makes a lot of sense
144 2011-08-05 02:07:13 <cjdelisle> although I don't know of anyone having developed a routing algorithm which works that way.
145 2011-08-05 02:08:13 <gmaxwell> cjdelisle: freenet routing
146 2011-08-05 02:08:24 <gmaxwell> (not quite like that, but vaguely)
147 2011-08-05 02:08:40 <gmaxwell> It does loop prevention too "I've seen that message before! don't give it back to me"
148 2011-08-05 02:09:14 <gmaxwell> and it has a one dimensional direction. Your node is also aware of your peers peers in some cases, which is amusingly like social routing too.
149 2011-08-05 02:09:21 <gmaxwell> "Bob has friends in germany!"
150 2011-08-05 02:09:33 <cjdelisle> hmm
151 2011-08-05 02:10:02 <cjdelisle> Freenet actually does routing, I thought it was strictly an overlay network and couldn't function on it's own.
152 2011-08-05 02:10:26 <cjdelisle> I mean technically tor does routing but take away gbp/ospf and it's sunk.
153 2011-08-05 02:10:31 <gmaxwell> oh wow, no. It's an overlay network on the internet but routes internally.
154 2011-08-05 02:10:52 <gmaxwell> It's unlike tor, which is source routed.
155 2011-08-05 02:11:12 <gmaxwell> For freenet no one has visiblity of the whole network in fact the most anyone knows is some of their peers peers.
156 2011-08-05 02:12:05 <cjdelisle> I won't bother you to read me the freenet faq but that's interesting.
157 2011-08-05 02:13:03 <gmaxwell> Yea, you can google it. Unlike many open projects the freenet folks have used extensive simulation to inform their design too.
158 2011-08-05 02:36:03 <RealSolid> whats the chances of a tx with confirms=6 being invalidated
159 2011-08-05 02:42:32 <gmaxwell> See the bitcoin paper.
160 2011-08-05 02:42:42 <gmaxwell> RealSolid: assuming that no one is trying to double spend it zero.
161 2011-08-05 02:42:59 <gmaxwell> Assuming they are trying to double spend it and nave >>50% hashpower. 1.
162 2011-08-05 02:43:12 <gmaxwell> Assuming they don't have tons of hash power. ??? (see paper)
163 2011-08-05 02:45:00 <nanotube> gmaxwell: nice summary :)
164 2011-08-05 02:45:28 <gmaxwell> s/nave/have/
165 2011-08-05 02:46:51 <RealSolid> what happens in the double spend situation, youd forever have a TX with 0 confirms?
166 2011-08-05 02:47:31 <gmaxwell> RealSolid: if you're on the losing side.
167 2011-08-05 02:47:34 <RealSolid> ie TXa goes through, TXb doesnt, but it still shown?
168 2011-08-05 02:48:47 <gmaxwell> IIRC yes. (I've actually done double spends in testing, but I don't have any wallets right now with any to go look to see if the txn is still there)
169 2011-08-05 02:49:48 <RealSolid> on the receiving end of this, ie i get a TXb and its later invalidated, will the tx disappear?
170 2011-08-05 02:51:09 <gmaxwell> I don't want to comment from my hazy memory because I'm not sure at the moment.
171 2011-08-05 02:51:51 <gmaxwell> One thing thats always spooky is seeing transactions made by another client just show up like you made them locally when you have keys in two places.
172 2011-08-05 02:52:34 <RealSolid> yah
173 2011-08-05 02:53:05 <RealSolid> what im guessing happens is say getreceivedbyaddress ( minconfirm=0 ) will show the TXb added until its invalidade
174 2011-08-05 02:53:17 <RealSolid> and potentially also the TXa
175 2011-08-05 02:53:39 <gmaxwell> It won't show both while both are unconfirmed for sure.
176 2011-08-05 02:53:42 <RealSolid> or i guess that cant happen, both active, but TXa will appear
177 2011-08-05 02:53:48 <RealSolid> after TXb removed
178 2011-08-05 02:54:03 <gmaxwell> Your node will instantly drop any conflicting transaction it hears about outside of the blockchain.
179 2011-08-05 02:54:09 <RealSolid> yah
180 2011-08-05 02:54:19 <RealSolid> then the next block is done and TXa is now there, TXb gone
181 2011-08-05 02:54:28 <gmaxwell> (which is protective against double spends they don't tend to propagate on the network worth a darn)
182 2011-08-05 02:54:33 <RealSolid> i think the client which sent should be the only one having the trans there forever unconfirmed
183 2011-08-05 02:54:52 <gmaxwell> Yea, the sending client does, I'm pretty sure of that.
184 2011-08-05 02:55:13 <gmaxwell> And I'm absolutely sure that you won't see both on the rx side while both are unconfirmed.
185 2011-08-05 02:55:20 <RealSolid> indeed
186 2011-08-05 02:55:23 <gmaxwell> What I'm not completely sure is if the loser will go away if you heard it first.
187 2011-08-05 02:55:29 <RealSolid> thanks for helping to explain
188 2011-08-05 03:43:19 <osmosis> im seeing a tendency for # of connections to jump every day at about 5PM PST
189 2011-08-05 03:44:03 <gmaxwell> Hm? you're not constantly maxed out?
190 2011-08-05 03:44:10 <gmaxwell> are you running .24?
191 2011-08-05 03:44:51 <osmosis> im running a server with 1024 max.  So no, not maxed out.  fluctuates between 70 and 110.
192 2011-08-05 03:45:01 <osmosis> yah,  latest
193 2011-08-05 03:45:18 <gmaxwell> just fair warning, 1024 max will make you crash if you haven't carefully upped the max fds.
194 2011-08-05 03:46:07 <osmosis> what should I have it set at?
195 2011-08-05 03:48:00 <gmaxwell> well, lower your connection count to 1000 and your should be safe. Or up the FD limit to 65535. :)
196 2011-08-05 03:52:04 <osmosis> gmaxwell, ill try it at 512 and see if I get a different result
197 2011-08-05 04:14:07 <upb> what the hell is a 'UABB'
198 2011-08-05 04:14:15 <upb> without having to read 1000 spammy forum posts
199 2011-08-05 04:16:06 <imsaguy> some bullshit about representing the community at large
200 2011-08-05 04:16:43 <upb> oh heh
201 2011-08-05 04:25:45 <iddo> anyone looked at slides of dan kaminsky? why did he say in slide 12 that in the future each block will be 1gb ? i thought block size is affected only by num of current transactions (not entire history), no? http://www.reddit.com/r/Bitcoin/comments/j9e4a/kaminsky_on_bitcoin/
202 2011-08-05 04:28:13 <markus_wanner> iddo: it must be only the number of current transactions (previous history covered by just a hash), but at some point, we'll have lots and lots of transactions within 10 minutes, right?
203 2011-08-05 04:28:34 <markus_wanner> iddo: (disclaimer: I didn't look at the slides, yet...)
204 2011-08-05 04:29:24 <copumpkin> json isn't known as the most space-efficient format
205 2011-08-05 04:32:17 <imsaguy> blocks are still limited in size to 2mb
206 2011-08-05 04:33:57 <gmaxwell> iddo: he's taking some crazy estimate based on visa's peak traffic levels
207 2011-08-05 04:34:14 <gmaxwell> iddo: which is crazy because its unlikely that bitcoin would replace visa.
208 2011-08-05 04:34:23 <iddo> i wonder if we would have many more transactions compared to now, e.g. if there are separate layers above bitcoin that use actual bitcoin transactions less frequently, like option 3 described in https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation
209 2011-08-05 04:34:24 <upb> those are probably quoted from somewhere because i remember reading something like that
210 2011-08-05 04:34:42 <gmaxwell> (instead people will build credit and payment networks on top of bitcoin that provide many advantages, including reducing traffic on bitcoin)
211 2011-08-05 04:35:04 <gmaxwell> iddo: jinx, basically.
212 2011-08-05 04:35:53 <iddo> so his 1gb per block is just an error? what is the size of a block right now? i cannot imagine that it will be that much larger than it is now
213 2011-08-05 04:37:41 <gmaxwell> It's a calculation based on a crazy assumption.
214 2011-08-05 04:37:41 <iddo> about 5kb per block?
215 2011-08-05 04:37:55 <gmaxwell> No, they're bigger than that. the average is probably up to 100k or so.
216 2011-08-05 04:38:15 <imsaguy> plenty of room to grow before 2m
217 2011-08-05 04:38:29 <gmaxwell> The maximum size the software will currently allow is capped (I thought at 1MB, but I see people saying 2MB and I'm too lazy to go look)
218 2011-08-05 04:38:34 <iddo> i divided 700mb blockchain by 139000 block, was about 5kb ?
219 2011-08-05 04:38:43 <imsaguy> I though it was 2, but I could be wrong
220 2011-08-05 04:38:47 <gmaxwell> iddo: the blockchain is way smaller than 700mb
221 2011-08-05 04:39:09 <iddo> hmm so it should be even less than 5kb on average?
222 2011-08-05 04:39:14 <gmaxwell> The average over all history is not a great predictor of the future.
223 2011-08-05 04:39:44 <gmaxwell> iddo: you can see recent sizes on blockexplorer.
224 2011-08-05 04:40:17 <gmaxwell> in any case the 1gb number is assuming 10k transactions per second or something like that.
225 2011-08-05 04:41:16 <gmaxwell> Which duh, that won't work so well. The point of that analysis is to show that bitcoin itself can scale up quite a bit (because a lot of people have this "omg flodding?! wtf that can't work!" response)
226 2011-08-05 04:42:10 <gmaxwell> and it's true, you could concievably make pretty much all money exchanges transactions in the world go through bitcoin. But that would be nuts. And pointless. And damanging to bitcoin's decenteralized nature.
227 2011-08-05 04:43:02 <imsaguy> oops
228 2011-08-05 04:43:05 <imsaguy> If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB
229 2011-08-05 04:43:12 <imsaguy> wiki says .5M
230 2011-08-05 04:43:19 <gmaxwell> In a world where bitcoin was very widely used, we'd see bitcoin replace checks, wire transfers, gold bars, CDs  and all the uses of things like credit cards/paypal which would have been better served by those other things if they were transferable online.
231 2011-08-05 04:44:46 <gmaxwell> And the credit cards / payments networks that exist in that bitcoin future would be far less costly and provide more value in order to compete with the direct bitcoin transactions that back them.
232 2011-08-05 04:46:12 <gmaxwell> In exchange for the costs they charge and the trust they require, they'll provide many features: instant confirmation, reporting, pull transactions, perhaps even chargebacks or other anti-fraud measures, reduction in bitcoin fees (due to only needing to settle periodically), etc.
233 2011-08-05 04:47:44 <iddo> could someone attack bitcoin by broadcasting many transactions between addresses that he controls?
234 2011-08-05 04:51:58 <[Tycho]> iddo, no.
235 2011-08-05 04:55:15 <shadders> Any pool operators hanging out in here?
236 2011-08-05 04:55:54 <iddo> [Tycho]: why not? please elaborate?
237 2011-08-05 04:58:56 <shadders> pushpool vs poolserverj performance test: https://bitcointalk.org/index.php?topic=34565.0
238 2011-08-05 04:59:43 <shadders> hopefully keep the java haters quiet for a bit...
239 2011-08-05 05:00:29 <RealSolid> for a bit because any native code has potential to always be faster
240 2011-08-05 05:01:11 <shadders> sure with identical architectures native code will always be faster.  look at the numbers
241 2011-08-05 05:01:30 <RealSolid> is that sarcasm
242 2011-08-05 05:01:42 <shadders> no
243 2011-08-05 05:01:59 <RealSolid> why are you doing it in java then
244 2011-08-05 05:02:05 <RealSolid> why not just optimize it in c++
245 2011-08-05 05:02:17 <shadders> because I'm a java developer, it's big and a lot easier for me to manage in java
246 2011-08-05 05:02:41 <RealSolid> ok
247 2011-08-05 05:02:45 <hugolp> java sucks
248 2011-08-05 05:03:00 <hugolp> just trying to make you feel comfortable
249 2011-08-05 05:03:03 <shadders> JIT compiler get's very close to to native performance after warmup and poolservers aren't CPU bound in any case.
250 2011-08-05 05:03:04 <hugolp> :D
251 2011-08-05 05:03:45 <shadders> thanks :)  first time in here, had a feeling there wasn't much java love in the room
252 2011-08-05 05:04:34 <shadders> oh, the other reason is I don't know c++... fairly major obstacle.
253 2011-08-05 05:04:47 <hugolp> c++ sucks too
254 2011-08-05 05:05:12 <aviadbd> hugolp: the only natural programming language to write in is Brainfuck.
255 2011-08-05 05:05:26 <shadders> I know it means I'm molly coddled but I couldn't imagine having to collect my own garbage
256 2011-08-05 05:07:12 <RealSolid> lawl shadders
257 2011-08-05 05:07:38 <RealSolid> with smart pointers and whatnot on C++ you dont have to do much anyhow
258 2011-08-05 05:07:52 <RealSolid> all the speed of native with the ease of use of java
259 2011-08-05 05:08:05 <shadders> If I knew what that was I'd probably be convinced
260 2011-08-05 05:08:08 <hugolp> aviadbd: first time I heard about it
261 2011-08-05 05:08:09 <aviadbd> RealSolid: not sure that's the case for large complex projects, actually.
262 2011-08-05 05:08:21 <aviadbd> hugolp: what kind of a programmer are you then?! :D
263 2011-08-05 05:08:34 <RealSolid> aviadbd: oh?
264 2011-08-05 05:08:52 <hugolp> Im not even a real programmer... Im an engineer recycled into a programmer. Go figure.
265 2011-08-05 05:08:54 <RealSolid> theres a large project in java now?
266 2011-08-05 05:08:58 <RealSolid> lawl
267 2011-08-05 05:09:07 <aviadbd> RealSolid: yes. Java's GC is working on an entirely different level than just deleting pointers.
268 2011-08-05 05:09:13 <RealSolid> even minecraft developers are sorry they developed in java now
269 2011-08-05 05:09:29 <aviadbd> RealSolid: sigh. Not going into a C++ vs Java argument now. :)
270 2011-08-05 05:09:38 <RealSolid> there is no argument mate
271 2011-08-05 05:09:44 <RealSolid> java is fine for small scale stuff
272 2011-08-05 05:09:59 <hugolp> RealSolid: true, there is no argument, they both suck (big time).
273 2011-08-05 05:09:59 <shadders> actually I'd argue the other way around...
274 2011-08-05 05:10:16 <RealSolid> hugolp: nah, c++0x fixes many of the c++ annoyances
275 2011-08-05 05:10:23 <RealSolid> whilst still having the lovely speed
276 2011-08-05 05:11:04 <shadders> Java is great for big complex projects and if you really need to optimise beyond what the JIT can do write some parts as native
277 2011-08-05 05:11:06 <RealSolid> java has its advantages that C++ never will, but trying to argue speed/resources/development time is pointless
278 2011-08-05 05:11:29 <aviadbd> RealSolid: as I said - not going there, mate.
279 2011-08-05 05:11:29 <RealSolid> shadders: wheres a JAVA OS then
280 2011-08-05 05:11:40 <RealSolid> cant get any more complicated than that
281 2011-08-05 05:11:41 <aviadbd> RealSolid: Where's a C++ OS then?
282 2011-08-05 05:11:45 <aviadbd> RealSolid: All the OS's are written in C.
283 2011-08-05 05:11:51 <hugolp> aviadbd: beat me to it
284 2011-08-05 05:11:52 <aviadbd> or lower.
285 2011-08-05 05:11:53 <RealSolid> C/C++ same thing
286 2011-08-05 05:11:56 <RealSolid> nearly
287 2011-08-05 05:11:58 <hugolp> NO WAY
288 2011-08-05 05:11:59 <aviadbd> RealSolid: it's completely different.
289 2011-08-05 05:12:06 <RealSolid> haha no, its not completely different
290 2011-08-05 05:12:16 <RealSolid> C Is a subset of C++, completely valid as C++
291 2011-08-05 05:12:30 <aviadbd> RealSolid: doesn't make them run the same way.
292 2011-08-05 05:12:35 <shadders> use java for what java's good at (i.e. not OS's) and use c for everything else.
293 2011-08-05 05:12:44 <aviadbd> RealSolid: in that case I'd argue that Objective-C is a subset of C and runs the same way. But it's not.
294 2011-08-05 05:12:54 <hugolp> shadders: or one could just use python instead of Java
295 2011-08-05 05:13:01 <RealSolid> aviadbd: no, C code doesnt run in C#
296 2011-08-05 05:13:14 <RealSolid> or compile rather
297 2011-08-05 05:13:20 <aviadbd> RealSolid: so what?
298 2011-08-05 05:13:24 <aviadbd> RealSolid: doesn't mean anything about runtime
299 2011-08-05 05:13:27 <RealSolid> C in C++ does
300 2011-08-05 05:13:43 <hugolp> saying that c++ and c are the same has to be a crime somewhere
301 2011-08-05 05:13:50 <aviadbd> hugolp: I know.
302 2011-08-05 05:13:57 <shadders> or jython, then you can not only interpret your code but execute it in it a JVM for extra teabreaks between prompts
303 2011-08-05 05:13:59 <aviadbd> hugolp: shows some disrespect for the profession.
304 2011-08-05 05:14:07 <RealSolid> you can program objectively in C++ or functionally, doesnt matter
305 2011-08-05 05:14:14 <RealSolid> in java youre forced
306 2011-08-05 05:14:18 <aviadbd> RealSolid: try to write embedded systems in C++ and tell me its the same thing.
307 2011-08-05 05:14:35 <aviadbd> sigh.
308 2011-08-05 05:14:43 <aviadbd> went there even though I said I wouldn't.
309 2011-08-05 05:14:44 <RealSolid> supporting C++ is obviously more intensive than plain C, but its irrelevant
310 2011-08-05 05:14:57 <hugolp> aviadbd: I dont think many people does (mainly because of memory constraints) but embedded compilers are starting to accept C++ (dont ask me why)
311 2011-08-05 05:14:57 <shadders> you're not forced, you can use static methods to write functionally in java
312 2011-08-05 05:15:31 <aviadbd> hugolp: barely. And for that matter, embedded systems are accepting Java as well. Check out RTSJ.
313 2011-08-05 05:15:40 <hugolp> are you serious?
314 2011-08-05 05:15:58 <RealSolid> lol shadders, youre forced to use SOME object stuff at lesat
315 2011-08-05 05:16:45 <aviadbd> hugolp: even though I think it's kind of abandoned since the Oracle purchase.
316 2011-08-05 05:16:57 <aviadbd> but it had some qualities.
317 2011-08-05 05:17:03 <hugolp> At least Oracle did something right...
318 2011-08-05 05:17:03 <shadders> yes
319 2011-08-05 05:17:17 <hugolp> like what?
320 2011-08-05 05:17:45 <RealSolid> the gap between C/C++ compilers isnt that large for todays embedded hardware
321 2011-08-05 05:18:00 <aviadbd> hugolp: there were some cool hovering aircrafts, some manufacturing robots - even the one winning the fastest in 2005/6 or something. Can't remember exactly.
322 2011-08-05 05:18:04 <RealSolid> and where it is, the hardware is nearly irrelevant
323 2011-08-05 05:18:47 <hugolp> RealSolid: in the embedded world memory is VERY expensive
324 2011-08-05 05:18:58 <RealSolid> hugolp: since when
325 2011-08-05 05:18:59 <hugolp> it also adds to consumption
326 2011-08-05 05:19:05 <RealSolid> were not in 1996 anymore