1 2012-06-16 00:28:49 <sipa> gzip: 55.8 MiB, bzip2: 50.7 MiB, lzma: 42.8 MiB
  2 2012-06-16 00:29:26 <Diablo-D3> okay, so what about ck's thing
  3 2012-06-16 00:30:01 <sipa> which?
  4 2012-06-16 00:31:54 <Diablo-D3> he has a compressor
  5 2012-06-16 00:31:57 <Diablo-D3> beats everything out there
  6 2012-06-16 00:32:02 <Diablo-D3> forget the name of it though
  7 2012-06-16 00:32:19 <Diablo-D3> (what, you only thought he wrote bfs and cgminer?)
  8 2012-06-16 00:34:48 <gmaxwell> sipa: I'd only expect to do better with a custom compressor that knows to send the txids verbatim.
  9 2012-06-16 00:35:36 <gmaxwell> (I mean over the xz/lzma)
 10 2012-06-16 00:36:14 <sipa> 50.1 MiB
 11 2012-06-16 00:36:40 <sipa> gmaxwell: txids, key ids, pubkey coordinates, ...
 12 2012-06-16 00:41:32 <phantomcircuit> gmaxwell, really the only thing that's compressible is var ints and maybe the op codes in scripts
 13 2012-06-16 00:42:06 <gmaxwell> phantomcircuit: the scripts are highly repeative.
 14 2012-06-16 00:42:19 <gmaxwell> the several bytes of pushes and checksigs can all become a fraction of a bit.
 15 2012-06-16 00:42:37 <gmaxwell> and the output addresses are repetative too.
 16 2012-06-16 00:42:43 <phantomcircuit> right as i said opcodes
 17 2012-06-16 00:42:55 <phantomcircuit> but you're gonna save like 12 bytes per script
 18 2012-06-16 00:43:09 <gmaxwell> sure, which will be like 10%
 19 2012-06-16 00:43:35 <gmaxwell> not that I think it matters. More important is actually using such a datastructure on nodes.
 20 2012-06-16 00:54:51 <gribble> New news from bitcoinrss: bitcoinuser opened issue 1473 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1473>
 21 2012-06-16 03:37:06 <devrandom> ;;later tell BlueMatt may be useful in the future: https://github.com/devrandom/gitian-builder/blob/master/bin/canon-zip
 22 2012-06-16 03:37:07 <gribble> The operation succeeded.
 23 2012-06-16 07:52:24 <Diapolo> Can someone post a testnet address I can add into my addressbook ;)?
 24 2012-06-16 07:59:38 <Diapolo> got one
 25 2012-06-16 08:02:50 <wumpus> testnet addresses:
 26 2012-06-16 08:02:54 <wumpus> mxKx1GxgUpqoQ71kxc5GAjMd6hqDJHRbBL mx5DgE1aUNCxhowwQmtuxUwzPXEpE1ZhBV n1AUqxRpEdeUGZwAqRKmoWA8GVYYHGoQfV mfgkiy8g3oX5nn9Raq5gejfHDmqaWT15HG mvDoMzbrmjsf5xkkLiUHmLtFxsRZsk7Gbv moC55rciNJvSqMk5VPWbEku7oXKMibNDBU n2aDpjABAsDLDHJ7v6eCzncHknqF2oPDPh ms5Bk3xzcVHNEQM5vpRmApuGPHsfWNZZWr mtoKs9V381UAhUia3d7Vb9GNak8Qvmcsme mxKx1GxgUpqoQ71kxc5GAjMd6hqDJHRbBL miGuMc6qtVEKS6Pf1jKddaa81DeHjMzkpB
 27 2012-06-16 09:26:03 <sipa> gmaxwell: 65462071 bytes uncompressed, 45090522 bytes after lzma
 28 2012-06-16 09:27:49 <justmoon> sipa: told you compression would be interesting :P
 29 2012-06-16 09:29:39 <ClOaKeD-Banshee1> is that the blockchain?
 30 2012-06-16 09:30:08 <sipa> ClOaKeD-Banshee1: the most important part of it
 31 2012-06-16 09:30:23 <justmoon> the part you need to verify new transactions
 32 2012-06-16 09:30:27 <sipa> it's not enough to do rescans, reorganisations or serve the blockchain to other nodes
 33 2012-06-16 09:30:57 <ClOaKeD-Banshee1> nice, its prety kl to see it compresses down to 45mb :)
 34 2012-06-16 09:30:59 <sipa> justmoon: i suppose we can thank 1VayNert and DICE for the compressibility
 35 2012-06-16 09:31:23 <justmoon> sipa: I guess I have to add one more argument against decouraging address reuse :P
 36 2012-06-16 09:31:24 <sipa> s/thank/"thanks"/
 37 2012-06-16 09:31:34 <justmoon> discouraging*
 38 2012-06-16 09:32:24 <sipa> gzip only reduces it to 58260726 bytes
 39 2012-06-16 09:33:06 <justmoon> and bzip2?
 40 2012-06-16 09:33:24 <sipa> though there are certainly some improvements possible still, i think i have to go experiment with changing bitcoind's verification logic to use this data, instead of further squishing the last redundancy out of it
 41 2012-06-16 09:33:34 <sipa> 53040010 bytes
 42 2012-06-16 09:33:43 <justmoon> interesting
 43 2012-06-16 09:34:04 <justmoon> I have about 13 pages worth of debate response email to gmaxwell - spent all day yesterday writing, about five hours today, still not happy with it ^^
 44 2012-06-16 09:34:17 <sipa> i gave up following that thread
 45 2012-06-16 09:34:39 <sipa> i already have a custom integer encoder, custom amount encoder, custom script encoder and custom pruned-transaction encoder
 46 2012-06-16 09:34:55 <justmoon> I'll probably post it on the forums, it's a bit much for the mailing list
 47 2012-06-16 09:35:03 <justmoon> sipa: is that code up somewhere yet?
 48 2012-06-16 09:35:14 <justmoon> I want to play with putting it in bzing as well
 49 2012-06-16 09:35:38 <sipa> justmoon: in my 'info' branch
 50 2012-06-16 09:35:45 <justmoon> nice, you're the man!
 51 2012-06-16 09:35:56 <sipa> let me rebase and push the latest version
 52 2012-06-16 09:45:07 <eryngi> dev's around?
 53 2012-06-16 09:45:32 <justmoon> what kind of dev?
 54 2012-06-16 09:46:04 <eryngi> like gavin
 55 2012-06-16 09:46:36 <justmoon> there is at least one online that I know of, but rule #1 of irc is: ask your question, don't ask to ask your question
 56 2012-06-16 09:47:27 <eryngi> I'm just curious on the dev's opinion regarding recent advancements of several companies aiming to produce ASIC for mining
 57 2012-06-16 09:48:21 <eryngi> the fabs of the world are run by ~10 corporations, most of them in the USA
 58 2012-06-16 09:48:38 <eryngi> ASIC will force practically all mining onto ASIC
 59 2012-06-16 09:48:59 <justmoon> you realize that the same is true for GPU chips, right?
 60 2012-06-16 09:49:04 <eryngi> nope
 61 2012-06-16 09:49:21 <eryngi> GPU chips are widely available product that has been hacked to mine bitcoins
 62 2012-06-16 09:49:33 <eryngi> bitcoin specific ASIC is just that
 63 2012-06-16 09:49:47 <justmoon> you realize that most GPU chips we use for mining come from one of two companies? :)
 64 2012-06-16 09:49:54 <eryngi> eh..
 65 2012-06-16 09:50:04 <eryngi> you fail to see the point here my friend
 66 2012-06-16 09:50:14 <galambo> do you have one
 67 2012-06-16 09:50:25 <justmoon> I think I get your point, GPUs are generic, ASIC are produced specifically for Bitcoin
 68 2012-06-16 09:50:35 <justmoon> but I fail to see how that is a problem
 69 2012-06-16 09:50:45 <justmoon> ASIC manufacturers are happy to produce whatever you order
 70 2012-06-16 09:50:48 <eryngi> well it takes no more than some pressure from ane government to stop the production of those chips
 71 2012-06-16 09:51:06 <eryngi> or if not stop, then seize imports
 72 2012-06-16 09:51:06 <sipa> then we'll all get back to GPU mining or FPGA mining, right?
 73 2012-06-16 09:51:25 <Graet> its just an arems race that will increase mining costs and drive difficulty way high, to the point asics wont make more profit than gpus do now
 74 2012-06-16 09:51:31 <eryngi> no, then the entity that want's to shut down bitcoin will produce a run of ASIC
 75 2012-06-16 09:51:43 <sipa> plus, i believe governments have far easier ways to shut down bitcoin if they really wanted to
 76 2012-06-16 09:51:53 <sipa> like making it illegal
 77 2012-06-16 09:51:59 <justmoon> :D
 78 2012-06-16 09:52:17 <eryngi> lol?
 79 2012-06-16 09:52:31 <galambo> ... i think the bigger problem is that the companies that are claiming to make advancements in ASIC aren't being honest.
 80 2012-06-16 09:52:32 <sipa> i fail to see the humor
 81 2012-06-16 09:52:42 <eryngi> drugs are illegal too
 82 2012-06-16 09:53:15 <sipa> so, how will making asic production illegal work?
 83 2012-06-16 09:53:16 <justmoon> eryngi: and yet they are readily available, making your point about restricting ASIC somewhat dubious as well maybe? :P
 84 2012-06-16 09:53:27 <justmoon> hehe
 85 2012-06-16 09:53:31 <sipa> there is a large difference though
 86 2012-06-16 09:53:36 <justmoon> which is?
 87 2012-06-16 09:53:37 <sipa> bitcoin has a network effect
 88 2012-06-16 09:53:42 <eryngi> err
 89 2012-06-16 09:53:53 <eryngi> there are 10 companies creating ASIC
 90 2012-06-16 09:53:56 <sipa> drugs don't - they are useful in any amount on themselves (well, for some definition of 'useful')
 91 2012-06-16 09:54:09 <eryngi> there are 10000000 people working for drug business
 92 2012-06-16 09:54:28 <sipa> closing off bitcoin from the reach of honest businesses, before it reaching some critical mass, will effectively kill it, imho
 93 2012-06-16 09:54:49 <eryngi> how can that be done in your opinion?
 94 2012-06-16 09:55:00 <galambo> yes but none of those companies is going to devote resources to making bitcoin specific asic (its not enough to make an asic you have to use the same scale processes used in fast gpu and fpga chips)
 95 2012-06-16 09:55:03 <sipa> by outlawing it
 96 2012-06-16 09:55:25 <eryngi> like that stopped silkroad`?
 97 2012-06-16 09:55:27 <justmoon> eryngi: I'm googling, it looks like most suppliers for custom ASICs are in china it looks like
 98 2012-06-16 09:56:00 <eryngi> http://en.wikipedia.org/wiki/List_of_semiconductor_fabrication_plants
 99 2012-06-16 09:56:06 <sipa> eryngi: a currency that is only useful for trading for illegal goods, is not useful at all, even to criminals
100 2012-06-16 09:56:43 <eryngi> sipa, ok so in your opinion we can just neglect this asic issue, because bitcoin can be outlawed?
101 2012-06-16 09:56:53 <eryngi> and that will be the end of it?
102 2012-06-16 09:57:06 <galambo> its totally irrelevant to bitcoin protocol
103 2012-06-16 09:57:08 <eryngi> ok, problem solved!
104 2012-06-16 09:57:58 <eryngi> that's why I asked if any dev's are around here, because I don't want to spend my time chatting beside the point
105 2012-06-16 09:58:11 <eryngi> if you fail to see the point, or disagree, is't fine
106 2012-06-16 09:58:13 <sipa> if your worry about ASICs is that they can be controlled by governments, yes, then that is a valid point
107 2012-06-16 09:58:25 <eryngi> I wan't to hear the dev's stand on this issue
108 2012-06-16 09:58:51 <eryngi> is it possible that we will hold protocol change as a backdoor for self-protection, or not
109 2012-06-16 09:58:53 <sipa> bitcoin is an experiment to me
110 2012-06-16 09:59:08 <sipa> and a damn interesting one
111 2012-06-16 09:59:16 <eryngi> it's a potential revolution to me
112 2012-06-16 09:59:35 <justmoon> eryngi: *looking at list* so you're saying that the governments of the US, Israel, Germany, Japan, China, Taiwan, South Korea, France, Italy, Singapore, Mexico, UAE and Ireland will all outlaw Bitcoin ASICs?
113 2012-06-16 09:59:40 <galambo> governments can control asic like eryngi can demand bitcoin developers time
114 2012-06-16 09:59:59 <sipa> even if it fails, it will teach us invaluable things about how to run a cryptocurrency
115 2012-06-16 10:00:20 <ClOaKeD-Banshee1> so true sipa
116 2012-06-16 10:00:35 <justmoon> which of course includes all of these companies actually figuring out that the chips they are asked to manufacture are made for bitcoin purposes
117 2012-06-16 10:00:39 <eryngi> justmoon, I'm saying there are powers in this world that are capable of this, yes
118 2012-06-16 10:00:56 <eryngi> I'll give you an example
119 2012-06-16 10:01:58 <dub> while -qt starts up and hangs my machine for 30 seconds there is a single white pixel in the middle of the splash screen logo  which I keep mistaking for a dead pixel
120 2012-06-16 10:02:04 <galambo> the economics of asic will never work out
121 2012-06-16 10:02:15 <galambo> after the block rewards start decreasing we should expect the total hashing power of the network to decrease
122 2012-06-16 10:02:16 <eryngi> A terrorist bombs something, we find out he was paid in bitcoins. Governments try to figure out how to close the system, and see that easiest way is to restrict supply of hardware that runs the network, and attack the network
123 2012-06-16 10:02:16 <justmoon> eryngi: also it says at the top that the list is incomplete, here's a better one: http://www.digchip.com/datasheets/manufactures.php
124 2012-06-16 10:02:38 <galambo> its not necessary for the hashrate to be as high as it is today for bitcoin to work
125 2012-06-16 10:02:53 <justmoon> yeah, I don't think that that would be their conclusion, exchanges are much more easy to restrict than hardware
126 2012-06-16 10:03:04 <eryngi> justmoon, those are not fabs
127 2012-06-16 10:03:39 <justmoon> they are semiconductor manufacturers, how do you think they make semiconductors - by hand?
128 2012-06-16 10:04:10 <eryngi> http://en.wikipedia.org/wiki/Semiconductor_device_fabrication
129 2012-06-16 10:04:13 <sipa> eryngi: any amount of hashing power is enough to run the network technically (as soon as it doesn't change too suddenly), the only thing it does is change of economics of the game
130 2012-06-16 10:04:32 <eryngi> http://en.wikipedia.org/wiki/Fab_(semiconductors)
131 2012-06-16 10:05:03 <justmoon> eryngi: I know how semiconductor fabication works, I took tour at two fabs - one at stuttgart university as part of a week long course and one at IBM when I was interning
132 2012-06-16 10:05:05 <eryngi> sipa, you must be talking to galambo?
133 2012-06-16 10:05:10 <justmoon> both fabs aren't listed on wikipedia btw
134 2012-06-16 10:05:39 <sipa> eryngi: no
135 2012-06-16 10:06:12 <sipa> eryngi: kill a fab of ASICs, fine, the hashing power will decrease for a while; so what?
136 2012-06-16 10:06:22 <sipa> on itself that is not a problem
137 2012-06-16 10:06:23 <eryngi> sipa, which network is more protected: a) network with 1Gigaash/s b) networks with 1Petahash/s?
138 2012-06-16 10:06:43 <galambo> which one is a bigger misallocation of resources
139 2012-06-16 10:06:54 <justmoon> galambo: hehe :D
140 2012-06-16 10:07:05 <sipa> eryngi: the network doesn't need more protection than the stakeholders need
141 2012-06-16 10:07:17 <sipa> of course more hash power is more protected
142 2012-06-16 10:07:19 <eryngi> sipa, the point is, if the access to new mining hardware gets restricted for the BTC-friendly, that doesn't stop the BTC-unfriendly to produce hardware to overtake the network
143 2012-06-16 10:07:52 <freewil> you can always just buy gold and guns
144 2012-06-16 10:08:06 <freewil> but someone might have a bigger gun
145 2012-06-16 10:08:16 <eryngi> I repeat my question: Have the dev's looked at this, and where do they stand
146 2012-06-16 10:08:27 <eryngi> only way to protect against ASIC is protocol change
147 2012-06-16 10:08:35 <galambo> lol
148 2012-06-16 10:09:06 <sipa> changing the hash function is unreasonable, i believe
149 2012-06-16 10:09:17 <sipa> unless there is a cryptographic flaw found in it
150 2012-06-16 10:09:20 <eryngi> even if the network is under attack?
151 2012-06-16 10:09:21 <justmoon> I concur
152 2012-06-16 10:09:31 <justmoon> there are alternatives to bitcoin with other proof-of-work systems
153 2012-06-16 10:09:38 <galambo> what change do you propose that would discriminate between ASIC and FPGA hashes
154 2012-06-16 10:09:55 <eryngi> well ASIC cannot change at all
155 2012-06-16 10:10:06 <justmoon> galambo, litecoin uses memory intensive proof-of-work to accomplish that
156 2012-06-16 10:10:10 <freewil> is any hash function really protect against ASIC, or can it just be made more expensive
157 2012-06-16 10:10:13 <sipa> "memory intensive"
158 2012-06-16 10:10:14 <eryngi> it would be trivial to change a bitstream to say sha-256 + 1
159 2012-06-16 10:10:34 <sipa> eryngi: no, all ASIC miners would complain loudly
160 2012-06-16 10:10:44 <sipa> ;)
161 2012-06-16 10:10:46 <eryngi> we have non
162 2012-06-16 10:10:50 <eryngi> yet
163 2012-06-16 10:10:56 <galambo> sha-256 + 1. would that be sha-257?
164 2012-06-16 10:11:00 <eryngi> jesus
165 2012-06-16 10:11:12 <sipa> and we need an extraordinary degree of consensus to change anything that requires a hardfork
166 2012-06-16 10:11:14 <eryngi> ok I'll just wait till someone over 15 comes to the channel
167 2012-06-16 10:11:21 <justmoon> eryngi: we're also not anywhere near big enough for any government to care either
168 2012-06-16 10:12:33 <sipa> eryngi: if your question is: is bitcoin vulnerable to very powerful attackers? yes
169 2012-06-16 10:12:46 <eryngi> no, that was not my question
170 2012-06-16 10:12:50 <sipa> if your question is: does ASIC mining increase that risk? maybe
171 2012-06-16 10:13:20 <eryngi> no, that was not my question either
172 2012-06-16 10:13:31 <galambo> hm having trouble finding sha-257 algo on wikipedia
173 2012-06-16 10:13:44 <justmoon> eryngi: so what's your question?
174 2012-06-16 10:13:57 <eryngi> scroll up, I've said it twice
175 2012-06-16 10:14:06 <sipa> bah, his point is well made; it is programmatically trivial to change the hash function, and yes, that would kill inflexible miners like ASIC miners
176 2012-06-16 10:14:20 <sipa> but changing that function is very non-trivial to the community
177 2012-06-16 10:14:26 <eryngi> exactly
178 2012-06-16 10:14:48 <eryngi> but if the whole community is under attack, would the dev's be ready to do so?
179 2012-06-16 10:14:56 <eryngi> or are we calling it quit's?
180 2012-06-16 10:14:56 <sipa> and if we're eyed by a large government, asic mining will be the least of my worries
181 2012-06-16 10:15:06 <eryngi> sipa, why is that?
182 2012-06-16 10:15:15 <sipa> i'd try to stay out of prison
183 2012-06-16 10:15:31 <eryngi> I don't see many ways of killing bitcoin except attacking the very core of it
184 2012-06-16 10:15:41 <justmoon> it doesn't really matter what we think, somebody would make a version with a different hash function, the question is how many users will switch to it
185 2012-06-16 10:15:55 <eryngi> justmoon, exactly
186 2012-06-16 10:16:06 <eryngi> and the trust would be lost
187 2012-06-16 10:16:19 <sipa> maybe
188 2012-06-16 10:16:20 <eryngi> (in bigger public's eyes)
189 2012-06-16 10:16:25 <eryngi> or general public
190 2012-06-16 10:16:25 <justmoon> if the original block chain is completely busted it would be useless to run the old client, so I'd imagine that people would switch
191 2012-06-16 10:17:08 <justmoon> there would be some diversity, but eventually one or two forks would probably emerge victorious
192 2012-06-16 10:17:10 <eryngi> it wouldn't need to get busted
193 2012-06-16 10:17:12 <justmoon> it wouldn't be pretty
194 2012-06-16 10:17:21 <justmoon> but it should survive in some form
195 2012-06-16 10:18:13 <justmoon> hope that helped answer your question, I have to go back to debating another dev on whether devs have too much power :P
196 2012-06-16 10:18:40 <eryngi> good luck with that, important issue aswell
197 2012-06-16 10:18:45 <sipa> damn, stl::map is inefficient
198 2012-06-16 10:18:59 <justmoon> sipa: google_sparse_hash yo
199 2012-06-16 10:19:13 <sipa> my 65 MiB of data in an stl::map on a 64-bit system requires 330 MiB ram :(
200 2012-06-16 10:19:26 <sipa> sure, there are definitely better tuned datastructures
201 2012-06-16 10:20:02 <justmoon> google_sparse_hash isn't "better tuned" - it's reality defying black magic :)
202 2012-06-16 10:20:27 <sipa> any technology sufficiently advanced is indistinguishable from magic
203 2012-06-16 10:20:37 <justmoon> well said
204 2012-06-16 10:20:59 <sipa> hence, any technically distinguishable from magic is insufficiently advanced ;)
205 2012-06-16 10:21:10 <sipa> *technology
206 2012-06-16 10:21:20 <justmoon> non sequitor
207 2012-06-16 10:22:22 <justmoon> actually, no, it's correct, just misleading, because it's no longer clear that "sufficiently" refers to the distinguishability
208 2012-06-16 10:23:13 <sipa> indeed
209 2012-06-16 10:23:35 <sipa> logically correct, but an incorrect implication when interpreted as everyday english
210 2012-06-16 10:25:52 <sipa> worded differently: there exist a degree of advancedness A for which it is true that any technology beyond A is indistinguishable from magic
211 2012-06-16 10:26:23 <sipa> hence, there exists a degree of advancedness A for which it is true that any technology distinguishable from magic is not beyond A
212 2012-06-16 10:29:28 <justmoon> it should be pointed out though that a technology can appear somewhat magical long before it reaches the threshold of being indistinguishable from magic
213 2012-06-16 10:37:03 <sipa> MysteryBanshee: what for?
214 2012-06-16 10:45:36 <MysteryBanshee> oh im giving out btc randomly
215 2012-06-16 10:48:14 <MysteryBanshee> between 0.05 and 1 to people depending on what /dev/random says :P
216 2012-06-16 10:53:02 <sipa> why...?
217 2012-06-16 10:53:31 <MysteryBanshee> im bored :)
218 2012-06-16 10:58:56 <galambo> has anyone here actually seen a bfl product operating in person
219 2012-06-16 10:59:21 <sipa> in #bitcoin-mining perhaps more people :)
220 2012-06-16 10:59:38 <galambo> i dont want to talk to people that would be motivated to lie
221 2012-06-16 10:59:45 <Graet> lol
222 2012-06-16 11:00:21 <Graet> well 4 of the people that code on my pool say they have them, and i trust them so... and i have seen pics 2 or 3 of them have taken of bfls
223 2012-06-16 11:00:57 <Graet> it wopuld be one hell of a super conspiracy if everyone that said they had one didnt....
224 2012-06-16 11:01:21 <galambo> no actually it wouldnt be a hell of a conspiracy
225 2012-06-16 11:01:33 <sipa> just good marketing ;)
226 2012-06-16 11:01:48 <galambo> it would be a few orders of magnitude smaller than the average penny stock scam
227 2012-06-16 11:04:08 <galambo> there are many miners, id imagine, who expanded their operations during the bubble using credit
228 2012-06-16 11:05:19 <galambo> otherwise honest people could be encouraged to lie under that weight
229 2012-06-16 11:07:26 <Graet> lol
230 2012-06-16 11:07:43 <Graet> whatever, bfls exist, ppl mine on them, bvelieve what you like :)
231 2012-06-16 11:09:43 <galambo> I think its rather convienent that they announced a new product with a "trade-in" for people with preorders of their old product. the new product having even less believable numbers than the last..
232 2012-06-16 11:10:57 <galambo> and its clear that they are still unable to meet their obligations for the old product, if it exists at all
233 2012-06-16 11:21:05 <MysteryBanshee> sipa: thx gd idea
234 2012-06-16 11:31:47 <kokjo> https://en.bitcoin.it/wiki/Protocol_specification#Network_address , specifies that network addresses has a time field. i can't seem to find it in the acctual messages from the satoshi client. is this field removed?
235 2012-06-16 11:38:39 <sipa> kokjo: see CAddress in protocol.h
236 2012-06-16 11:38:50 <sipa> nLastSeen or something
237 2012-06-16 11:47:06 <kokjo> thansk
238 2012-06-16 11:47:09 <kokjo> thanks*
239 2012-06-16 11:49:39 <kokjo> https://github.com/bitcoin/bitcoin/blob/master/src/protocol.h#L82 means that its only when written to disk right? and not to the network?
240 2012-06-16 12:18:51 <sipa> kokjo: either when writing to disk, or when using a network protocol version later than that constant
241 2012-06-16 13:47:48 <gribble> New news from bitcoinrss: xanatos opened issue 1474 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1474>
242 2012-06-16 13:53:11 <devrandom> MysteryBanshee: you are giving out bitcoins based on what I say?  cool!
243 2012-06-16 15:15:11 <luke-jr> so I'm seriously considering limiting the number of transactions Eligius puts into blocks
244 2012-06-16 15:15:21 <luke-jr> we just had a second series of 3 orphans in a row
245 2012-06-16 15:17:24 <Diapolo> luke-jr: I'm "finished" with the UI changes for sign / verify, can you take another look? I'm soon off, but feel free to use the Github thread :D.
246 2012-06-16 15:17:35 <luke-jr> Diapolo: I will later probably
247 2012-06-16 15:17:47 <luke-jr> https://raw.github.com/gist/2941991/49e56aad358e7586eed0c8b35a4961985b09d41d/gistfile1.json
248 2012-06-16 15:19:29 <galambo> how do the pools work
249 2012-06-16 15:19:46 <galambo> does the pool operator keep a digest of the transactions to put into the block and send out the merkle root to the pool?
250 2012-06-16 15:21:40 <MysteryBanshee> oh ffs what is wrong with blockchain.info's wallet
251 2012-06-16 15:21:49 <MysteryBanshee> i meant to send 0.1010101010 btc and it sent 1.010101010 instead
252 2012-06-16 15:22:06 <d34th> did you put 0. or just .
253 2012-06-16 15:22:13 <MysteryBanshee> 0.
254 2012-06-16 15:22:18 <MysteryBanshee> but it seems if you put too many digits in
255 2012-06-16 15:22:21 <MysteryBanshee> (more than 8)
256 2012-06-16 15:22:26 <MysteryBanshee> it confuses the applet
257 2012-06-16 15:22:33 <d34th> seems legit
258 2012-06-16 15:22:48 <MysteryBanshee> urgh i just lost 1 btc
259 2012-06-16 15:23:39 <luke-jr> https://raw.github.com/gist/2941991/6d1ab1e0fb569f82edbdb9aed078a8a84c311578/gistfile1.json
260 2012-06-16 15:24:44 <galambo> is this what you send to your pool?
261 2012-06-16 15:26:22 <MysteryBanshee> if someone had any time, please do me a favour and tell the muppets who run blockchain.info to fix their damn shit
262 2012-06-16 15:26:30 <MysteryBanshee> had=has
263 2012-06-16 15:33:54 <luke-jr> MysteryBanshee: go ahead and tell them
264 2012-06-16 15:34:58 <galambo> luke-jr: why do you send all of the transactions to the miners in your pool
265 2012-06-16 15:35:05 <Graet> MysteryBanshee, i already posted in thier thread once today - diff issue, but basically that :P
266 2012-06-16 15:53:17 <yellowhat> /join #bitcoin-otc
267 2012-06-16 16:07:17 <MysteryBanshee> oh cool thx Graet
268 2012-06-16 16:07:32 <Graet> :)
269 2012-06-16 17:13:27 <luke-jr> anyone have a dice-blocking patch yet?
270 2012-06-16 17:20:17 <PK> does bitcoin's rpc support named parameters?
271 2012-06-16 17:20:28 <JFK911> isnt that called xml
272 2012-06-16 17:20:41 <JFK911> hey maybe you can mix xml with rpc
273 2012-06-16 17:20:50 <JFK911> it would be neat
274 2012-06-16 17:22:08 <PK> I mean something like "params"  : { "account" : "myAccount", "from" : 0, "count" : 25 } instead of "params" : ["myAccount", 0, 25]
275 2012-06-16 17:22:27 <PK> I'm not sure why you could call that xml though
276 2012-06-16 17:23:21 <forrestv> PK, you can do that in jsonrpc 2.0, but i'm pretty sure bitcoind doesn't support it
277 2012-06-16 17:24:17 <PK> forrestv: actually, you can do it in 1.1. But bitcoind keeps telling me that it expects an array. So you might be right about bitcoind not supporting it.
278 2012-06-16 17:24:44 <PK> Is there any way to skip a parameter then? I want to call listtransactions without the account but with the paging values.
279 2012-06-16 17:28:28 <forrestv> PK, i think if you use "*" for account, it's equivalent to not passing it
280 2012-06-16 17:29:20 <PK> forrestv: that works, thanks a lot. You saved my project! :)
281 2012-06-16 17:29:33 <forrestv> hehe :)
282 2012-06-16 17:30:34 <luke-jr> please review http://codepad.org/Hy4Qrnor
283 2012-06-16 17:30:41 <luke-jr> gmaxwell: forrestv: anyone else: ^
284 2012-06-16 17:33:30 <devrandom> /win 18
285 2012-06-16 17:35:08 <sipa> luke-jr: looks safe to me
286 2012-06-16 17:38:29 <forrestv> seems good http://codepad.org/vLfbz3Rb
287 2012-06-16 17:40:46 <gmaxwell> luke-jr: it looks correct. My preference is to treat them as zero fee, low prio instead of totally dropping them but..
288 2012-06-16 17:44:25 <PK> Why is 1dice getting "blocked"? I thought they use the network correctly and pay fees? Did I miss something?
289 2012-06-16 17:48:55 <sipa> PK: fees are payed miners, not to everyone running a node
290 2012-06-16 17:49:40 <sipa> if people use the network in a way that some users do not consider to be beneficial, they may decide not to use it at all
291 2012-06-16 17:50:15 <PK> sipa: yes, I know. But how is that related to my question. You confuse me
292 2012-06-16 17:50:52 <MC1984> so
293 2012-06-16 17:51:06 <sipa> that said, i don't think they are doing something "wrong", but i also don't think it's wrong that some people personally decide to take measures against it
294 2012-06-16 17:51:13 <MC1984> what, cut in everyone running a full node or what?
295 2012-06-16 17:52:05 <PK> sipa: that patch is only for pool code, not for the main bitcoind client?
296 2012-06-16 17:52:05 <sipa> PK: you consider "paying fees" to mean "i can do whatever i want"; technically that is true, but that doesn't mean everyone should consider whatever you do while paying fees to be playing nice
297 2012-06-16 17:52:12 <sipa> PK: of course not
298 2012-06-16 17:52:35 <sipa> i don't think such specific code belongs in the reference code
299 2012-06-16 17:53:16 <sipa> gmaxwell: i put the txid -> compressed pruned txout data in a bdb file: 110 MiB
300 2012-06-16 17:54:54 <PK> sipa: I'm more referring to "oh, I don't like them, I don't think they are beneficial. Let's put an embargo on them." sound more something certain govs would do. Not the bitcoin community. In other words, you're welcome to deal in drugs and weapons of mass destructions, but if you care bloat our chain we get angry!
301 2012-06-16 17:55:20 <PK> s/care/dare/
302 2012-06-16 17:55:48 <sipa> PK: "we" don't get angry, but I don't mind some people personally becoming angry :)
303 2012-06-16 17:56:16 <gmaxwell> I dunno that anyone is angry. It's just something else to deal with.
304 2012-06-16 17:56:19 <moartr4dez> well I think you found the fatal flaw in bitcoin... developer chooses to block arbitrary bitcoin addresses
305 2012-06-16 17:56:29 <gmaxwell> moartr4dez: No one is doing that.
306 2012-06-16 17:56:43 <gmaxwell> And also no one can be made to use software that does that.
307 2012-06-16 17:56:43 <Graet> lol
308 2012-06-16 17:56:46 <PK> I just think it's a bit hypocrite :)
309 2012-06-16 17:56:55 <sipa> moartr4dez: if developers start doing that, I hope you're wise enough to start your own branch
310 2012-06-16 17:57:02 <gmaxwell> ^ that.
311 2012-06-16 17:57:32 <Eliel> PK: there's actually a good reason for miners to use that code change. Bigger blocks are less likely to win races between blocks found close together and end up orphan.
312 2012-06-16 17:58:01 <gmaxwell> PK: I don't welcome people dealing in drugs or weapons of mass destruction. But there is nothing I can do about that. (and in the cast of the latter, I don't believe that exists. Don't spread fud, playing emotions is poor form)
313 2012-06-16 17:58:03 <Eliel> and if you have to keep your blocks smaller, satoshidice txs are a good candidate to exclude
314 2012-06-16 17:58:03 <Graet> actyually its a poolop that trhinks txn from that adress are harming his pool (business) that is proposing this, yes he is a bitcoin dev too, but which hat atm? poolop i'd say
315 2012-06-16 17:58:42 <sipa> PK: well the mining platform is still a free market - i have as little to say about how pools run their business as i have to say in how users use bitcoin, or what for
316 2012-06-16 17:58:54 <moartr4dez> gmaxwell: true, but if its advantageous enough miners might... as a miner I would like to mine transactions for the subset of bitcoin addresses that is most profitable to me
317 2012-06-16 17:59:04 <gmaxwell> Graet: I've personally run patches that filter some kinds of transactions (though not targeting single senders), and I refuse to distribute them, even to other developers. Becuase I don't agree in principle with doing that sort of things.
318 2012-06-16 17:59:23 <moartr4dez> so why not built multiple lists of bitcoin addresses by classification... miners can choose the lists they want to include/exclude
319 2012-06-16 17:59:48 <moartr4dez> kinda like ad blocker lists
320 2012-06-16 17:59:54 <sipa> PK: wait... are you assuming such a patch for blocking DICE would end up in the reference client?
321 2012-06-16 18:00:11 <gmaxwell> PK: As far as I can tell you're babling about nonsense though. ''Most people will use the official client'' Okay, so where is your concern?  Show me a single place where any developer of any kind has proposed blocking in the official client.
322 2012-06-16 18:00:54 <PK> sipa: I was assuming that since we're in #bitcoin-dev, yes. You told me a few lines above that it's not.
323 2012-06-16 18:01:17 <gmaxwell> moartr4dez: because thats just a mess. It's better to identify things based on behavior than based on addresses. Addresses are trivially changed. It would be a waste of code and have more potential for abuse than benefit.
324 2012-06-16 18:01:43 <gmaxwell> PK: No such thing is going in the official client, so relax.
325 2012-06-16 18:02:01 <gmaxwell> PK: you have my word that if any such thing were added I'd revert the change until my access was revoked. Happy?
326 2012-06-16 18:02:07 <MC1984> so pools are gonna block 1dice?
327 2012-06-16 18:02:11 <moartr4dez> lists of addresses can be just as dynamically updated
328 2012-06-16 18:02:21 <Eliel> PK: also, there's actually no way to reliably block transactions in bitcoin network. Any block that doesn't stop all transactions (or all but a certain list) is easily routed around.
329 2012-06-16 18:02:21 <gmaxwell> MC1984: some miners already are.. ::shrugs::
330 2012-06-16 18:02:54 <wizkid057> i've applied luke's code
331 2012-06-16 18:02:55 <Graet> MC1984, a pool has proposed to
332 2012-06-16 18:02:58 <sipa> if dice has enough market share, they can subsidize miners that do allow their transactions as well :)
333 2012-06-16 18:03:00 <wizkid057> has lowered CPU usage... lol
334 2012-06-16 18:03:30 <Graet> sipa, the problem is large blocks /slow propagation, more orphans
335 2012-06-16 18:03:32 <gmaxwell> MC1984: my own nodes have been downpreffing all repeated addresses for some time now. Though that got broken on a merge to current code and at the moment I've moved my minfee up to 0.01 BTC, though I'm unhappy about that because I'd like to preserve some amount of free txn.
336 2012-06-16 18:03:33 <PK> dice simply has to increase the fees until it gets more attractive to process their transactions again.
337 2012-06-16 18:03:34 <MC1984> can it really be considered txn spam though
338 2012-06-16 18:03:58 <Eliel> MC1984: up to you. Everyone can decide for themselves.
339 2012-06-16 18:03:58 <Graet> find a way i can include more txn without blosting block and risking orphans and I'm all for it :)
340 2012-06-16 18:03:59 <sipa> Graet: yeah, never understood why blocks carry the full transactions; those are normally already distributed anyway
341 2012-06-16 18:04:01 <gmaxwell> MC1984: thats the problem with words, they're so limited. It is what it is, nothing more or less.
342 2012-06-16 18:04:25 <MC1984> yeah, its valid txn right, no exploits
343 2012-06-16 18:04:46 <sipa> it's not because a door is open, that it is legal to walk in
344 2012-06-16 18:04:54 <Eliel> Graet: I expect the size of the block will stop mattering once you can avoid transfering the txs that the receiving node already has in mempool.
345 2012-06-16 18:05:07 <gmaxwell> MC1984: well the 'exploit' is only that they get around needing confirmations by using a great many more transactions than any other gambling site with similar volume.
346 2012-06-16 18:05:43 <gmaxwell> MC1984: which is adverse to the future success of bitcoin because it prematurely increases the cost of operating it relative to the economic success of the system. ::shrugs::
347 2012-06-16 18:05:45 <Graet> once we can
348 2012-06-16 18:05:50 <Graet> eta Eliel ?
349 2012-06-16 18:06:03 <Eliel> Graet: I have none but I heard it's being worked on
350 2012-06-16 18:06:14 <wizkid057> Personally, the gripe I have with satoshidice is that there exist much better methods of doing this type of thing WITHOUT 30,000 TXNs/day
351 2012-06-16 18:06:19 <Graet> i mean all this ethicval and should and shouldnty discussion is fine, but atm it is a rwal problem for a lot of pools
352 2012-06-16 18:06:28 <moartr4dez> well I think all that will happen is SD will start issuing new addresses to use on the fly...
353 2012-06-16 18:06:37 <gmaxwell> And say sipa says we can't make the system rules prohibit all possible anti-social behavior without also blocking a lot of legit behavior. Just because the system allows something doesn't mean its the right thing to do.
354 2012-06-16 18:06:37 <moartr4dez> so your 'fix' will be neutered
355 2012-06-16 18:06:46 <PK> I think it's more accurate to compare it to flash mobbing a restaurant every day. You pay full price and bring in 10 times the customers they can handle. That should be good for the restaurant but they might end up refusing service.
356 2012-06-16 18:07:10 <Graet> yes, so we (the poools) need to work out a solution to this, and blcoking some adresses or randomly raising fees wont solve it
357 2012-06-16 18:07:31 <gmaxwell> PK: Thats an interesting comparison point. The restaurant hates it because when the mob stops they may have no other customers left because the mob made everyone not part of the mob give up.
358 2012-06-16 18:07:46 <PK> gmaxwell: exactly.
359 2012-06-16 18:08:23 <wizkid057> Graet: I think part of the issue is that the block size is quite large now that we're including satoshispam, and most pools have connections to many many nodes... if the pool finds a block, it has to use the massive bandwidth of sending a large block out to all of those nodes... which takes time, time enough for another pool with a smaller block to orhpan
360 2012-06-16 18:08:35 <gmaxwell> Graet: my preference is to use the repeated use of an address as a signal that a txn doesn't need high priority, and then drop it at the very end of the priority list.  Couple that with some block relaying and pruned-node improvements and we'd be pretty good.
361 2012-06-16 18:08:44 <Graet> wizkid057, yes
362 2012-06-16 18:08:48 <PK> however, does this mean we hit the limit of the network already and others "not part of the mob give up" ?
363 2012-06-16 18:09:18 <moartr4dez> gmaxwell: I was thinking the same thing... some sort of prioritization to speed bump the txn... but that's susceptible to the same rotation of addresses countermeasure
364 2012-06-16 18:09:19 <Eliel> PK: there's more room for optimization in the code but those take time.
365 2012-06-16 18:09:23 <gmaxwell> PK: It's really hard to say. We do know that this activity is causing some people who know nothing about it to complain about slow/"stuck" transactions.
366 2012-06-16 18:09:24 <Graet> gmaxwell, how will that work for my coinbase generation of blocks, reusing the same addy?
367 2012-06-16 18:09:30 <wizkid057> how compressable are blocks? :P
368 2012-06-16 18:09:44 <gmaxwell> Graet: doesn't do it on block themselves, just related txn.
369 2012-06-16 18:10:02 <Graet> and i forsee a lot of bitcoin businesses reusing addys for same customers, thus we are de prioritising thier customers txns
370 2012-06-16 18:10:13 <Graet> ok
371 2012-06-16 18:10:30 <gmaxwell> moartr4dez: Thats okay. If you're communicating with someone to agree on addresses, then you can also communicate to have a balance and not generate a ton of txns.
372 2012-06-16 18:10:46 <gmaxwell> Graet: and I think thats okay, actually. If you have a standing relationship you don't need fast confirmations.
373 2012-06-16 18:11:02 <Eliel> PK: In my view, satoshidice did a good job in highlighting some scalability issues in the current implementation. However, the point has been made and it'd be preferable the spam stops so regular use is not adversely affected.
374 2012-06-16 18:11:02 <MC1984> well
375 2012-06-16 18:11:16 <MC1984> pools can refuse service for any reason i suppose
376 2012-06-16 18:11:23 <wizkid057> Eliel: i agree with this
377 2012-06-16 18:11:24 <Graet> i think that would depend on thebusiness involved, some sure, but not all :)
378 2012-06-16 18:11:28 <PK> Eliel: then these optimizations should be done before bitcoin become more popular and wide spread.
379 2012-06-16 18:11:31 <MC1984> but its the same as visa and chums refusing service to say wikileaks
380 2012-06-16 18:11:34 <gmaxwell> MC1984: perhaps but thats not good for the success of bitcoin either.
381 2012-06-16 18:12:03 <gmaxwell> It's important to note that regular bitcoin use doesn't result in persistant addresses which can just be blocked.
382 2012-06-16 18:12:11 <moartr4dez> the txn spam problem
383 2012-06-16 18:12:33 <moartr4dez> at least a txn 'costs' something
384 2012-06-16 18:12:34 <wizkid057> well, the issue is that the huge increase in transaction volume needs to inspire an early development shift towards ways of effectively handling the volume, and as a side effect, detract from other development
385 2012-06-16 18:12:36 <MC1984> isnt txn fees supposed to fix this problem
386 2012-06-16 18:12:42 <Eliel> PK: of course, we'll have similar transaction level to what satoshidice is causing right now in a year or so.
387 2012-06-16 18:12:50 <gmaxwell> There are special use case to make it possible for nodes to accept unconfirmed txn which simultaniously increase the number of txn on the network, and use static easily identified addresses.
388 2012-06-16 18:12:53 <PK> *sarcasm* Otherwise Bitcoin really becomes just "gold" and we need something else for silver, like Litecoin.
389 2012-06-16 18:12:58 <Eliel> PK: assuming satoshidice stops causing lots of txs
390 2012-06-16 18:13:20 <gmaxwell> PK: you mean .. the thing which is even less scalable as silver? :)
391 2012-06-16 18:13:53 <MC1984> litecoin is finished i think
392 2012-06-16 18:14:08 <wizkid057> Eliel: i *think* part of the issue is that the satoshidice txns reuse an unconfirmed txn, thus bloating the memory pool... more so than the same amount of "normal" txns
393 2012-06-16 18:14:10 <Graet> loo
394 2012-06-16 18:14:12 <wizkid057> i could be wrong
395 2012-06-16 18:14:16 <gmaxwell> MC1984: I haven't been following it for a while.
396 2012-06-16 18:14:33 <Graet> a lot of keen developers on it atm MC1984
397 2012-06-16 18:14:41 <MC1984> turns out the can GPU mine it after all, so whats the point
398 2012-06-16 18:14:46 <gmaxwell> wizkid057: this might be part of the high cpu usage you were seeing. Linear scans of the memory pool.
399 2012-06-16 18:14:53 <wizkid057> gmaxwell: exactly
400 2012-06-16 18:14:55 <Graet> ltc netwiork hasht=rate has increased over last week
401 2012-06-16 18:15:11 <wizkid057> gmaxwell: perhaps a temporary (perm?) fix would be to optimize scans of the memory pool
402 2012-06-16 18:15:18 <PK> if miners refuse to process 1dice transactions. They will stack up in the pool of unconfirmed ones. Correct? Wouldn't that make it even worse?
403 2012-06-16 18:15:25 <Graet> MC1984, the p[oint is its not economically viable to mine on gpu - even if you can :)
404 2012-06-16 18:15:25 <sipa> Graet: what's the exchange rate LTC<->BTC right now?
405 2012-06-16 18:15:36 <gmaxwell> PK: not if you drop them right on ingress.
406 2012-06-16 18:15:57 <MC1984> nope i read someone worked out how to get megahashes on a gpu with litecoin
407 2012-06-16 18:16:04 <PK> gmaxwell: for the miner, yes. But they still float around the network for the next block.
408 2012-06-16 18:16:14 <gmaxwell> Graet: it's not net positive over power on cpu either, ::shrugs::
409 2012-06-16 18:16:21 <wizkid057> PK: the patch in question just ignores them completely, so, no stacking... and since the bet itself was ignored, the payout also will be ignored since it's input isnt in the memory pool... thus, effectively ignoring 1dice* txns
410 2012-06-16 18:16:27 <Graet> 0.003001 sipa
411 2012-06-16 18:16:33 <gmaxwell> PK: sure, but mempool being slow on nodes that aren't mining isn't a major problem. No one would notice.
412 2012-06-16 18:16:45 <wizkid057> gmaxwell: lies, i noticed... lol
413 2012-06-16 18:16:48 <Graet> gmaxwell, indeed, but worse than btc on gpu, so really silly :)
414 2012-06-16 18:16:51 <sipa> Graet: ah, about the exchange rate between testnet coins and bitcoin 2 years ago ;)
415 2012-06-16 18:17:19 <gmaxwell> Graet: ha. I think thats higher than were I sold all my ltc.
416 2012-06-16 18:17:29 <gmaxwell> (well ~all)
417 2012-06-16 18:17:35 <Graet> MC1984, i have mined with megahashes on gpu, and guees what it costs me more than mining ltc on cpu, so it is still a barrier :)
418 2012-06-16 18:17:56 <Graet> heh cool :D gmaxwell
419 2012-06-16 18:18:49 <wizkid057> heres a silly question...
420 2012-06-16 18:19:00 <wizkid057> would there be a way to optimize satoshidice txns?
421 2012-06-16 18:19:21 <wizkid057> nm, stupid question
422 2012-06-16 18:19:23 <TuxBlackEdo> wizkid057, I am glad you ask
423 2012-06-16 18:19:38 <TuxBlackEdo> they should set up a online wallet
424 2012-06-16 18:19:45 <gmaxwell> wizkid057: sure. But not without making them more vulnerable to doublespends breaking them. I mean every other gambling site handles more traffic than this without issue.
425 2012-06-16 18:19:55 <gmaxwell> What TuxBlackEdo says.
426 2012-06-16 18:20:13 <gmaxwell> And if the wanted do to fast deposits they could accept mtgox codes like Joric's thing does.
427 2012-06-16 18:20:17 <wizkid057> gmaxwell: well, that would be optimal, sure, but what incentive do they have to do so when their current spam works for them
428 2012-06-16 18:20:32 <TuxBlackEdo> so people can deposit into satoshidice
429 2012-06-16 18:20:57 <Eliel> frankly, I can't see them doing that. It'd be reducing the attractiveness of their service.
430 2012-06-16 18:21:22 <wizkid057> i could care less what they do, as long as it doesnt adversely effect me
431 2012-06-16 18:21:37 <wizkid057> as a non-satoshidice user that is
432 2012-06-16 18:21:58 <wizkid057> some random bitcoin user with bitcoin-qt installed shouldnt have to suffer satoshidice CPU spikes
433 2012-06-16 18:22:13 <MC1984> how many txns are they putting out then
434 2012-06-16 18:22:22 <wizkid057> MC1984: > 30k per day
435 2012-06-16 18:22:30 <Eliel> MC1984: 90% of daily transactions currently.
436 2012-06-16 18:22:35 <Eliel> maybe more than that already
437 2012-06-16 18:22:35 <MC1984> jesus christ what the fuck are they doing over there
438 2012-06-16 18:22:46 <TuxBlackEdo> ouch 90%
439 2012-06-16 18:23:00 <wizkid057> so the solutions appear to be either ousting satoshidice from bitcoin somehow (not likely, nor desirable probably), or, solving the underlying issue
440 2012-06-16 18:23:03 <gmaxwell> 13:03 < MC1984> can it really be considered txn spam though
441 2012-06-16 18:23:03 <wizkid057> i prefer the latter
442 2012-06-16 18:23:08 <TuxBlackEdo> might as well call it gamblecoin now
443 2012-06-16 18:23:19 <gmaxwell> wizkid057: you're the only one with an underlying issue that can be solved I think. :)
444 2012-06-16 18:23:20 <MC1984> how are they affording the fees
445 2012-06-16 18:23:26 <Eliel> MC1984: take a look at this graph for an idea: http://blockchain.info/charts/n-transactions
446 2012-06-16 18:23:31 <gmaxwell> wizkid057: most people aren't concerned about the cpu usage, right now.
447 2012-06-16 18:23:50 <gmaxwell> okay, I suppose luke's relaying issue can be solved.
448 2012-06-16 18:23:51 <wizkid057> gmaxwell: well, CPU usage for a generic node is one thing, CPU usage for a pool will be far higher
449 2012-06-16 18:23:53 <TuxBlackEdo> 90% to satoshi dice and 10% to silk road, is there a precentage left for non gambling and non drug use?
450 2012-06-16 18:24:03 <Graet> i prefe the latter too wizkid057 :)
451 2012-06-16 18:24:03 <TuxBlackEdo> that was a joke btw
452 2012-06-16 18:24:10 <gmaxwell> wizkid057: but software fixes don't solve the "my txn is taking forever to confirm! help!"
453 2012-06-16 18:24:17 <sipa> TuxBlackEdo: sure, 1% traffic from/to exchange sites ;)
454 2012-06-16 18:24:41 <gmaxwell> MC1984: their suckers^wcustomers are giving them free money.
455 2012-06-16 18:24:51 <Graet> gmaxwell, it is affecting lots of pools, laggung bitcoinds and causing slow announces and orphan blocks
456 2012-06-16 18:24:58 <wizkid057> gmaxwell: if the software could handle the load better, then perhaps it wouldnt be as much of an issue
457 2012-06-16 18:24:59 <Graet> and slow longpolls
458 2012-06-16 18:25:31 <wizkid057> what Graet said ^^
459 2012-06-16 18:25:33 <gmaxwell> wizkid057: the slow confirmations aren't software issues, the dice txn are crowding non-dice free txn out of blocks.
460 2012-06-16 18:25:37 <Eliel> wizkid057: I believe bitcoind can be optimized to handle this. The issue is just that it was a sudden multiplication of the transaction volume.
461 2012-06-16 18:25:41 <MC1984> TuxBlackEdo we knew the first ue of bitcoin would be shady ones
462 2012-06-16 18:25:46 <gmaxwell> it's not like we've lost apparent block rate due to this.
463 2012-06-16 18:25:46 <MC1984> its the same for all new tech
464 2012-06-16 18:26:05 <Eliel> wizkid057: no time to work on optimizing things in peace.
465 2012-06-16 18:26:16 <Graet> well for every orphan there is a rwal block...
466 2012-06-16 18:26:20 <Graet> so you wouldnt
467 2012-06-16 18:26:25 <Eliel> while the effects are starting to show but not really serious yet.
468 2012-06-16 18:26:27 <Graet> real*
469 2012-06-16 18:27:06 <wizkid057> Graet: if anything, the difficulty probably should be HIGHER, since more blocks are actually being created than accepted
470 2012-06-16 18:27:15 <gmaxwell> Graet: Sure, but I'm just pointing out that the pool perfomance issues aren't causing users to expirence slow txn. The slow txn are because users are sending zero fee txn and dice txn are being accepted before them.
471 2012-06-16 18:27:35 <wizkid057> gmaxwell: well, I disagree
472 2012-06-16 18:27:37 <MC1984> so free txn are on the way out
473 2012-06-16 18:27:41 <MC1984> we knew that would happen anyway
474 2012-06-16 18:27:50 <gmaxwell> MC1984: you mean bitcoin is on its way out.
475 2012-06-16 18:27:51 <Graet> ok well like i said before the pools need to work it out
476 2012-06-16 18:27:56 <galambo> why are people complaining about this?
477 2012-06-16 18:27:56 <MC1984> the only people getting screwed are running nodes without minig
478 2012-06-16 18:28:04 <Graet> all this going around in circles isnt solving anything
479 2012-06-16 18:28:21 <wizkid057> gmaxwell: pools like luke-jr's which would have mined almost all pending txns which ended up with orphans would have been able to help that issue, but instead got booted by satoshispam slowdown...
480 2012-06-16 18:28:37 <gmaxwell> MC1984: miners are more screwed by this than most due to software performance issues.
481 2012-06-16 18:28:47 <Graet> well one pool has lost 300btc from hab=ving blocks orphaned that wouldnt normally be, i guess he has a reason to complain galambo ?
482 2012-06-16 18:28:53 <MC1984> so
483 2012-06-16 18:29:02 <MC1984> maybe they shouldnt have bought up all the semprons eh.......
484 2012-06-16 18:29:09 <galambo> why are people complaining about the blocking
485 2012-06-16 18:29:12 <galambo> i mean to say
486 2012-06-16 18:29:30 <gmaxwell> galambo: becuase what if you get blocked next?
487 2012-06-16 18:29:48 <MC1984> <gmaxwell> MC1984: you mean bitcoin is on its way out.
488 2012-06-16 18:29:49 <MC1984> ha wat
489 2012-06-16 18:29:55 <galambo> then ill make another address :)
490 2012-06-16 18:30:06 <wizkid057> well, let me ask this simple question: Do miners/pools still have the authority to decide which txns are included in their blocks?
491 2012-06-16 18:30:08 <gmaxwell> galambo: yea, you've got me. :)
492 2012-06-16 18:30:17 <wizkid057> if so, the ST*U about the blocking
493 2012-06-16 18:30:20 <wizkid057> if not, wth happened
494 2012-06-16 18:30:45 <gmaxwell> (turning an earlier argument around) Just because you can do something doesn't make it right.
495 2012-06-16 18:31:06 <wizkid057> gmaxwell: well, lets look at it a different way
496 2012-06-16 18:31:13 <wizkid057> online gambling is illegal in germany
497 2012-06-16 18:31:17 <galambo> if the protocol does not make it forbidden, it is allowed. by definition.
498 2012-06-16 18:31:27 <wizkid057> so, not including dice txns may be better for the pool legally
499 2012-06-16 18:31:36 <gmaxwell> galambo: the protocol of the universe permits me to kill your family. ...
500 2012-06-16 18:31:41 <sipa> galambo: if the door does not prevent me from walking through it, it is allowed to enter?
501 2012-06-16 18:31:54 <Graet> itys 4.30am its been looked at many ways, can anyone sugegst a solution pools can adopt in the short term to improve their performance without blocking txns?
502 2012-06-16 18:32:15 <sipa> decreasing priority sounds "nice" to me
503 2012-06-16 18:32:15 <wizkid057> Graet: optimize searches through memory pool
504 2012-06-16 18:32:19 <galambo> the people complaining about blocking are trying to apply their morals to other people
505 2012-06-16 18:32:21 <Graet> or as it is not affecting the "normal" user (which it actually is) it is of no concern?
506 2012-06-16 18:32:23 <wizkid057> Graet: allow blocks to be broadcast compressed
507 2012-06-16 18:32:42 <gmaxwell> Graet: I think you should just go ahead and block them in the short term.  I'm just arguing with wizkid057 and galambo because I think it's fine to say that it's not great even if its also not wrong.
508 2012-06-16 18:32:53 <Graet> sure
509 2012-06-16 18:33:05 <galambo> the people blocking are not making any moral judgement (the transactions will still eventually be confirmed)
510 2012-06-16 18:33:12 <Graet> i see the discussion and its fine, but hey i can ask for advice and help here too?
511 2012-06-16 18:33:33 <gmaxwell> And as I said, I'm also blocking them on my nodes (though at the moment by imposing higher fees, which I think is less good because I want free transactions for regular users)
512 2012-06-16 18:33:47 <Graet> i'd prefer to continue tio be one of the pools including most txn in our blocks, not restrict randdom ppl from having txn accepted
513 2012-06-16 18:33:54 <Eliel> of course, every pool that blocks the satoshidice txs will reduce the total throughput available for satoshidice.
514 2012-06-16 18:34:11 <gmaxwell> Eliel: go go ratelimits.
515 2012-06-16 18:34:12 <Graet> and the txnm backlog will get huge
516 2012-06-16 18:34:30 <galambo> well satoshis dice should be netting transactions if they don't want to be arbitrarily excluded
517 2012-06-16 18:34:54 <galambo> if i invite you into my house and you piss on the floor i dont have to ask you back
518 2012-06-16 18:34:54 <MC1984> ok
519 2012-06-16 18:35:04 <MC1984> now imagine there are no pools
520 2012-06-16 18:35:04 <wizkid057> well, from a pool view, what are the issues? Slow memorypool and slow relay of large blocks found. Can we attack these issues?
521 2012-06-16 18:35:08 <guruvan> Graet: that will have the effect of teching users of satoshidice to slow down some IMO (ratelimitnig it further)
522 2012-06-16 18:35:14 <MC1984> to conspire to deal with dice
523 2012-06-16 18:35:19 <MC1984> what happens
524 2012-06-16 18:35:41 <guruvan> individual solominers conspire :)
525 2012-06-16 18:35:52 <gmaxwell> wizkid057: sure, the first sounds easy, the second would need a protocol change. E.g. a new "Get block without txn" request.
526 2012-06-16 18:35:53 <Graet> guruvan, and all the ppl paying a default fee lower than SD are, what about them? the "normal" user?
527 2012-06-16 18:35:53 <TuxBlackEdo> the sucky thing is there seems to not be a solution for this problem
528 2012-06-16 18:36:31 <gmaxwell> MC1984: I mine p2pool my own bitcoinds' set their own policies. You don't need pools to cooperate.
529 2012-06-16 18:36:39 <gmaxwell> and it's not like we've responded quickly to this.