1 2013-07-16 01:04:23 <amiller> who's nogleg?
2 2013-07-16 01:04:29 <amiller> http://blockchain.info/hub-nodes
3 2013-07-16 01:04:41 <amiller> relays so many transactions to blockchain.info
4 2013-07-16 01:05:44 <gmaxwell> presumably someone running that python spamming thing that just relays everything without any validation at all, not even checking the hash.
5 2013-07-16 01:06:39 <amiller> gmaxwell, which python spamming thing?
6 2013-07-16 01:08:38 <gmaxwell> this guys software: https://bitcointalk.org/index.php?action=profile;u=49
7 2013-07-16 01:09:36 <gmaxwell> I can't seem to find it now.
8 2013-07-16 01:10:23 <gmaxwell> In any case, it's just software that reads and write bitcoin messages and relays stuff as fast as possible with no validation. As a result people who run it just end up getting blacklisted by nodes.
9 2013-07-16 01:10:37 <gmaxwell> (because it relays garbage too)
10 2013-07-16 02:07:34 <Diablo-D3> http://community.namecheap.com/blog/2013/07/15/bitcoin-zero-confirmation/
11 2013-07-16 02:08:41 <gmaxwell> Sure? why not??? even without reading the url: they can revoke your name if your transaction is reversed.
12 2013-07-16 02:08:56 <gmaxwell> and presumably they can couple that to some other anti-dos methods.
13 2013-07-16 05:47:02 <fanquake> Just experienced the chainstate db uncorrupting itself for the second time. Both times I've aborted the db rebuild and turned my comp off/on, then Qt opens fine with no corruption.
14 2013-07-16 05:52:01 <gmaxwell> fanquake: what you're describing is impossible as you describe it.
15 2013-07-16 05:52:58 <gmaxwell> You were in the middle of a rebuild? the old chainstate data has been _destroyed_ at that point. Presumably whats happening is that its just leaving you at whatever height it was at and its catching back up in the background... is that possibly consistent with your expirence?
16 2013-07-16 05:53:11 <fanquake> No not in the middle of the rebuild
17 2013-07-16 05:53:24 <fanquake> I chose to abort the rebuild, i.e not do it.
18 2013-07-16 05:54:31 <gmaxwell> hm!
19 2013-07-16 05:54:39 <gmaxwell> What OS?
20 2013-07-16 05:54:50 <fanquake> osx 10.8.4
21 2013-07-16 05:55:44 <fanquake> I made a ticket ( https://github.com/bitcoin/bitcoin/issues/2785) when it happened the first time, and it has the debug log. Although it doesn't really offer any insight. I'll upload the latest log to that ticket.
22 2013-07-16 06:28:01 <toffoo> fanquake maybe this https://github.com/bitcoin/bitcoin/issues/2770
23 2013-07-16 07:18:37 <petertodd> First use of OP_RETURN in production: c4397247190d3f8d88b587990d1c374d6b0ae25ebf9ced81ea8b69665b43d7de (first p2pool block after the v13 hardfork)
24 2013-07-16 07:19:43 <petertodd> Heh, pretty sure that's the first idea of mine ever actually implemented in production too...
25 2013-07-16 07:20:32 <petertodd> ACTION needs to write more code.
26 2013-07-16 07:24:44 <phantomcircuit> petertodd, what's that do?
27 2013-07-16 07:25:10 <petertodd> phantomcircuit: Proves that the transaction can't be spent, and thus it doesn't need to be added to the UTXO set.
28 2013-07-16 07:25:29 <phantomcircuit> oh
29 2013-07-16 07:25:46 <phantomcircuit> i assume the data after it is just something for p2pool people
30 2013-07-16 07:25:58 <petertodd> phantomcircuit: I'm probably not the first person to think of that, but I got that particular standard agreed on and got forrestv to change p2pool to use it.
31 2013-07-16 07:26:09 <petertodd> phantomcircuit: Yup, that's the hash of the sharechain.
32 2013-07-16 07:26:37 <phantomcircuit> i have not a clue how p2pool works so i'll stick with "for p2pool"
33 2013-07-16 07:26:42 <petertodd> heh
34 2013-07-16 07:27:22 <phantomcircuit> pretty far into the realm of things i dont care about
35 2013-07-16 07:27:23 <phantomcircuit> :)
36 2013-07-16 07:27:44 <phantomcircuit> im sure you're not interested in my high performance trading platform either
37 2013-07-16 07:27:50 <phantomcircuit> (250k orders/second actual!)
38 2013-07-16 07:28:14 <petertodd> worth understanding - I can credit p2pool for my probabalistic payments idea
39 2013-07-16 07:28:24 <petertodd> damn, that's fast...
40 2013-07-16 07:28:44 <phantomcircuit> well on my workstation it only does 100/second with fsync enabled
41 2013-07-16 07:28:45 <petertodd> 8000cycles/order
42 2013-07-16 07:29:01 <petertodd> (on 2GHz single core)
43 2013-07-16 07:29:04 <phantomcircuit> but i dont have the 500k for the io subsystems necessary to do 250k flush ops/second
44 2013-07-16 07:29:43 <phantomcircuit> petertodd, the central limit orderbook code is more like 1.25m/second
45 2013-07-16 07:29:44 <petertodd> yeah, I was thinking the issue must be to keep the minimum work required for cocurrency down - not easy
46 2013-07-16 07:30:02 <phantomcircuit> the limit is largely that im using the native java thread queues
47 2013-07-16 07:30:28 <phantomcircuit> which are good but for something where the tightloop takes on the order of 2k cycles sluggish
48 2013-07-16 07:30:56 <petertodd> huh, so is this 250k orders/second for one asset class, or across several?
49 2013-07-16 07:31:09 <phantomcircuit> petertodd, per asset class
50 2013-07-16 07:31:36 <phantomcircuit> well actually im being lazy so it's a global system with multiple orderbooks, but if i was less lazy it could be per asset fairly easily
51 2013-07-16 07:31:51 <petertodd> So am I correct in thinking the issue is the mimimum amount of work required to save and retrieve state in such a system?
52 2013-07-16 07:32:11 <phantomcircuit> petertodd, the primary limit is cpu cache misses
53 2013-07-16 07:32:22 <phantomcircuit> which seems absurd but...
54 2013-07-16 07:32:38 <petertodd> Heh, I'm thinking theoretical limits, not the implementation, but yeah, to have cache misses be the problem sounds about right...
55 2013-07-16 07:32:39 <phantomcircuit> the key is figuring out how to horizontally shard users across multiple servers
56 2013-07-16 07:32:45 <Scrat> phantomcircuit: which is ok since each asset can run in its own cpu
57 2013-07-16 07:32:51 <Scrat> on*
58 2013-07-16 07:33:05 <phantomcircuit> Scrat, well they would actually need something more like their own system
59 2013-07-16 07:33:31 <phantomcircuit> i suspect a multi cpu system would actually be slower than a single cpu system
60 2013-07-16 07:33:50 <phantomcircuit> sharing information between the two takes ~1k ns
61 2013-07-16 07:33:59 <phantomcircuit> compared to 15ns to share cache lines on the same cpu
62 2013-07-16 07:34:31 <phantomcircuit> oh and did i mention i did this all in java
63 2013-07-16 07:34:33 <phantomcircuit> heh
64 2013-07-16 07:34:45 <phantomcircuit> c++ orderbook trivially does 5m orders/second
65 2013-07-16 07:34:53 <phantomcircuit> but it's too much like running with scissors
66 2013-07-16 07:34:54 <petertodd> phantomcircuit: What's so impressive about doing it in a language compiled to machine code? :P
67 2013-07-16 07:35:17 <petertodd> phantomcircuit: What do you say doing it with custom FPGA's is like?
68 2013-07-16 07:35:32 <phantomcircuit> nobody does this with custom fpgas
69 2013-07-16 07:35:46 <phantomcircuit> those are all running in house trading strategies
70 2013-07-16 07:36:08 <petertodd> ah, ok
71 2013-07-16 07:36:09 <phantomcircuit> or running the much simpler request for quote style messaging networks
72 2013-07-16 07:36:27 <phantomcircuit> when most people think high frequency trading they're thinking about a request for quote messaging network
73 2013-07-16 07:36:34 <phantomcircuit> which isn't at all like a central limit order book
74 2013-07-16 07:36:42 <petertodd> the EE press runs stories every so often about the crazy hardware financial people are creating from scratch
75 2013-07-16 07:36:48 <phantomcircuit> indeed many of the HFT things dont even work with a CLOB
76 2013-07-16 07:36:53 <phantomcircuit> since you cant race anybody
77 2013-07-16 07:37:31 <phantomcircuit> petertodd, the biggest thing they do is have NIC's that DMA packets directly to user space
78 2013-07-16 07:37:38 <phantomcircuit> and then run ip stacks in user space
79 2013-07-16 07:37:44 <phantomcircuit> some of them dont even run an ip stack
80 2013-07-16 07:37:53 <phantomcircuit> just ethernet frame parsing
81 2013-07-16 07:38:15 <phantomcircuit> but that's pretty safe as long as you assume you're going to lose/miss messages regularly
82 2013-07-16 07:38:17 <phantomcircuit> which they do
83 2013-07-16 07:38:53 <petertodd> phantomcircuit: yeah, what the EE press talks about is mainly ethernet optimization - kinda like real-time ethernet implementations, except I assume the financial guys actualy only care about average latency
84 2013-07-16 07:39:47 <phantomcircuit> petertodd, most of them are dealign with RFQ systems where you can cancel an order even after it's placed
85 2013-07-16 07:39:55 <petertodd> on, I'd never read about RFQ trading, so it's purely trades against market makers?
86 2013-07-16 07:40:19 <phantomcircuit> petertodd, not exactly it's basically a broadcast network in which you spam everybody with a request for quote
87 2013-07-16 07:40:26 <phantomcircuit> in some systems only the market makers respond
88 2013-07-16 07:40:30 <phantomcircuit> in others anybody can respond
89 2013-07-16 07:40:45 <phantomcircuit> but because in almost all of them you can cancel losing orders after the fact
90 2013-07-16 07:40:57 <phantomcircuit> they're mostly worried about minimum latencies rather than average/max
91 2013-07-16 07:40:59 <petertodd> ah ok, so you spam your messaeg, others respond with an offer, and there's some period that you can cancel orders?
92 2013-07-16 07:41:23 <phantomcircuit> right since you could conceivably accept multiple offers for the same quote
93 2013-07-16 07:41:32 <phantomcircuit> and then you cancel the ones you decide you dont want
94 2013-07-16 07:41:36 <petertodd> oh, so even if average latency was bad, their trading strategies can make use of them getting occasional very low latency orders?
95 2013-07-16 07:41:40 <phantomcircuit> it's all very ridiculous
96 2013-07-16 07:41:53 <phantomcircuit> petertodd, right
97 2013-07-16 07:42:31 <petertodd> it does all sound like a case where there's a set of arbitrary rules, and people have optimized the heck out of the strategies... not so different from my ideas about bitcoin stuff really
98 2013-07-16 07:42:49 <phantomcircuit> pretty much
99 2013-07-16 07:42:57 <phantomcircuit> well the rules weren't arbitrary at some point
100 2013-07-16 07:43:11 <phantomcircuit> they're all from when people would be shouting at each other to accept an offer
101 2013-07-16 07:43:39 <phantomcircuit> then all the rules carried over to electronic messaging networks
102 2013-07-16 07:43:44 <phantomcircuit> where they dont particularly make sense
103 2013-07-16 07:43:49 <petertodd> true, they just look arbitrary these days because the tech has changed so much
104 2013-07-16 07:44:06 <phantomcircuit> especially in light of people like me being able to write CLOB's which do 250k orders/second without much in the way of resources
105 2013-07-16 07:44:23 <phantomcircuit> but RFQ systems tend to make the market makers a lot of money
106 2013-07-16 07:44:27 <phantomcircuit> which is why they still exist
107 2013-07-16 07:44:28 <petertodd> so the issue is that in a CLOB the whole book is always visible
108 2013-07-16 07:44:47 <petertodd> sounds like RFQ systems are a worse deal for those genuinely wanting good price discovery
109 2013-07-16 07:44:55 <phantomcircuit> pretty much
110 2013-07-16 07:45:12 <phantomcircuit> RFQ systems the orderbook is more or less a cached copy of the orders other people have said they want
111 2013-07-16 07:45:26 <petertodd> which implies in a rational market the only RFQ participants would be HFT players, resulting in a zero-sum game for them...
112 2013-07-16 07:45:28 <phantomcircuit> but those other people can cancel their orders or just not accept any offers
113 2013-07-16 07:45:41 <phantomcircuit> which is also why the SEC has tons of rules to stop shenanigans
114 2013-07-16 07:45:51 <phantomcircuit> except of course the rules have loopholes
115 2013-07-16 07:46:06 <phantomcircuit> not intentionally but because this all gets crazy complex very fast
116 2013-07-16 07:46:09 <petertodd> yeah, people always forget that the stock market, bastion of free market capitalism, is the *most* regulated industry on the planet
117 2013-07-16 07:46:30 <phantomcircuit> petertodd, it's part of the reason all the bitcoin exchanges are CLOB's
118 2013-07-16 07:46:44 <phantomcircuit> it's hard to manipulate a market in which your attempt at manipulation might get executed
119 2013-07-16 07:46:45 <phantomcircuit> :)
120 2013-07-16 07:46:50 <petertodd> hehe
121 2013-07-16 07:47:22 <petertodd> although... what's interesting is the RFQ model is the only one that can be decentralized, but with fidelity bonds and a bunch of rules you could turn RFQ into CLOB...
122 2013-07-16 07:47:26 <phantomcircuit> sequence_id 11990000 bids 0 asks 4673 nanoseconds 207270854567257
123 2013-07-16 07:47:27 <phantomcircuit> sequence_id 11010000 bids 0 asks 3681 nanoseconds 207266812968773
124 2013-07-16 07:47:52 <gribble> 0
125 2013-07-16 07:47:52 <phantomcircuit> ;;calc (11990000-11010000)/(207270854567257-207266812968773) / 10 ** 9
126 2013-07-16 07:48:04 <gribble> 242478.317398
127 2013-07-16 07:48:04 <phantomcircuit> ;;calc (11990000-11010000)/((207270854567257-207266812968773) / 10 ** 9)
128 2013-07-16 07:48:32 <phantomcircuit> petertodd, you'd end up with a pretty complex market place though
129 2013-07-16 07:48:37 <phantomcircuit> im sure it's possible
130 2013-07-16 07:48:41 <phantomcircuit> im not sure it's practical
131 2013-07-16 07:49:21 <petertodd> for sure, heck, anytime you use fidelity bonds with automated systems the result is horrendously complex, which is probably why no-one has ever tried
132 2013-07-16 07:49:35 <gribble> 8248.16017144
133 2013-07-16 07:49:35 <phantomcircuit> ;;calc 2*10**9 * (1/242478.317398)
134 2013-07-16 07:49:42 <phantomcircuit> 8248 cycles
135 2013-07-16 07:50:00 <petertodd> it's interesting in light of the people, including myself, talking about zerocoin though, because you'd wind up with a distributed RFQ system to do the bitcoin<->zerocoin trading
136 2013-07-16 07:50:01 <phantomcircuit> that's ~30 main memory lookups
137 2013-07-16 07:50:17 <petertodd> phantomcircuit: stupid speed of light
138 2013-07-16 07:50:51 <phantomcircuit> petertodd, heh
139 2013-07-16 07:53:32 <petertodd> phantomcircuit: one of my co-workers has a story from working at some research lab that needed some very precise timing between two sequential events for an experiment, the administration was trying to move the experiment to a pair of buildings 100ft apart, and the plan was nearly settled on when someone calculated 100ft/c...
140 2013-07-16 07:53:57 <phantomcircuit> petertodd, lol
141 2013-07-16 07:54:34 <phantomcircuit> the ethernet cables in dc's near the nyse's facility which they rent out are all the same length
142 2013-07-16 07:54:42 <phantomcircuit> no matter how close they are to the switches
143 2013-07-16 07:54:58 <phantomcircuit> :)
144 2013-07-16 07:54:58 <phantomcircuit> they should have auctioned off close 1U spots
145 2013-07-16 07:55:13 <phantomcircuit> capitalism
146 2013-07-16 07:55:15 <petertodd> ha, that's like the macro-scale version of the wiggles in the pcb traces on your motherboard!
147 2013-07-16 07:59:31 <phantomcircuit> hmm actually im just gonna throw in a filter here and create a directory with the asset pair id
148 2013-07-16 07:59:42 <phantomcircuit> magic one daemon per asset pair
149 2013-07-16 07:59:51 <phantomcircuit> except i might want to use this with lots of them
150 2013-07-16 07:59:56 <phantomcircuit> so that would be annoying as all hell
151 2013-07-16 08:00:01 <phantomcircuit> decisions decisions...
152 2013-07-16 08:00:15 <petertodd> per asset pair? um... that's n^(n-1)~=n^2 directories...
153 2013-07-16 08:00:33 <phantomcircuit> petertodd, there would of course be a limited list of asset pairs :)
154 2013-07-16 08:00:35 <phantomcircuit> ie
155 2013-07-16 08:00:47 <phantomcircuit> BTC:USD, BTC:EUR, possibly things other than "currency"
156 2013-07-16 08:00:54 <petertodd> ah, so I can trade dogs for cats, but not dogs for onions unless I go through BTC first? :P
157 2013-07-16 08:00:57 <phantomcircuit> it's easy enough to just make a list
158 2013-07-16 08:01:10 <phantomcircuit> petertodd, right
159 2013-07-16 08:01:12 <phantomcircuit> heh
160 2013-07-16 08:01:46 <phantomcircuit> petertodd, in the normal world you list on your national exchange in your local currency
161 2013-07-16 08:01:52 <phantomcircuit> on the internet... what does that even mean
162 2013-07-16 08:01:57 <phantomcircuit> nothing
163 2013-07-16 08:03:27 <petertodd> actually, so serious question: I'm convinced you can make a truely scalable decentralized crypto-coin by splitting up your coin into n sub-coins and automatically trading, now I *suspect* you can setup the coin-pairs such that it'll take something like log-n steps, but I haven't gotten around to figuring out what routing topology makes sense, and doing it by having nodes pick part of the UTXO space randomly is probably better
164 2013-07-16 08:03:48 <petertodd> it's not as esoteric an issue as you might expect :)
165 2013-07-16 08:04:58 <phantomcircuit> petertodd, that's an interesting thought but i dont see how a relatively expensive trade is any better than the current largeish utxo
166 2013-07-16 08:05:52 <petertodd> phantomcircuit: key advantage is it lets you mine even on a low bandwidth connection because you only need to keep up with part of the UTXO set - the P2P network would be similarly sharded
167 2013-07-16 08:06:17 <phantomcircuit> petertodd, so you'd only need to keep track of the shards you cared about
168 2013-07-16 08:06:33 <phantomcircuit> i kind of suspect that for most people that would eventually grow to be all of them though
169 2013-07-16 08:06:50 <phantomcircuit> unless you automatically traded so stay on one of them which is what you were saying, derp
170 2013-07-16 08:07:08 <petertodd> phantomcircuit: yup, basically "I'll keep track and mine transactions touching the UTXO space starting with 01, 04, and A2"
171 2013-07-16 08:07:47 <phantomcircuit> petertodd, that's an interesting thought
172 2013-07-16 08:08:36 <phantomcircuit> the biggest problem i can see is you'd be sharding the mining power which would mean a much smaller % could overtake a shard
173 2013-07-16 08:08:37 <petertodd> The issue is that if it's explicitly different sub-coins, rather than just "keep up with what you can", the profit margins for those with more of the UTXO set won't be higher than those maintaining less.
174 2013-07-16 08:09:24 <petertodd> phantomcircuit: Yeah, you'd need to have all miners timestamp all "sub-chains", and create consensus rules where those timestamps meant something - tricky.
175 2013-07-16 08:11:20 <petertodd> It'd likely wind up dependent on proving fraud after the fact... which is kinda funny, because it shows how the idea is just the evolution of fidelity bonded bank stuff.
176 2013-07-16 08:12:11 <Scrat> cat bitcoin-dev.log | grep
177 2013-07-16 08:12:19 <Scrat> argh fuck my enter
178 2013-07-16 08:12:34 <Scrat> cat bitcoin-dev.log | grep -i "fidelity bond" | wc -l
179 2013-07-16 08:12:39 <Scrat> laptop gkeyboard runed my joke
180 2013-07-16 08:12:45 <Scrat> ruined*
181 2013-07-16 08:13:20 <petertodd> Scrat: lol! meanwhile "cat github.com | grep -i "fidelity bond" | wc -l"
182 2013-07-16 08:13:23 <petertodd> Scrat: 0
183 2013-07-16 08:19:53 <gmaxwell> DHT still beats fidelity 2:1.
184 2013-07-16 08:20:46 <petertodd> I'm going to have to try harder
185 2013-07-16 08:31:03 <petertodd> gmaxwell: nah, cat bitcoin-dev | grep dht | grep -v webscale paints a different picture
186 2013-07-16 08:33:14 <gmaxwell> you need to get the case right for DHT
187 2013-07-16 08:33:51 <petertodd> I applied the "do what I mean" patch to my grep install
188 2013-07-16 08:34:18 <fluffypony> ola
189 2013-07-16 08:34:33 <fluffypony> copy-paste of my question in #bitcoin:
190 2013-07-16 08:34:34 <fluffypony> question: if I've mined a block, the reward goes straight into my wallet, but doesn't appear in the output of listreceivedbyaddress 0 true???so how do you dumpprivkey if you don't know the address?
191 2013-07-16 08:34:42 <fluffypony> my use case is that it hasn't matured yet, so I wanted to move the privkey to a different machine so I can bring this rig down for maintenance (and yet access the funds whilst the rig is down)
192 2013-07-16 08:34:56 <fluffypony> so trying to avoid having to wait till it matures
193 2013-07-16 08:37:20 <petertodd> you on p2pool?
194 2013-07-16 08:37:55 <fluffypony> petertodd: no, private pool, so this is the bitcoind for the farm/pool
195 2013-07-16 08:38:33 <petertodd> fluffypony: why don't you just look up the block itself and figure out which address the payout went too?
196 2013-07-16 08:38:47 <petertodd> fluffypony: dumpprivkey that
197 2013-07-16 08:38:48 <kinlo> hmmmz, is bitcoind still fast enough to mine on?
198 2013-07-16 08:38:58 <fluffypony> ACTION ponders
199 2013-07-16 08:39:00 <fluffypony> that should work
200 2013-07-16 08:39:09 <kinlo> I'd say even for private pools, use a pool daemon
201 2013-07-16 08:40:15 <petertodd> kinlo: it still is if you don't have much hashing power, but that's mostly useful for testnet
202 2013-07-16 08:40:27 <kinlo> testnet is not bitcoin mining
203 2013-07-16 08:40:29 <petertodd> IE, one or two BFL asics
204 2013-07-16 08:40:48 <kinlo> I have plenty of testnet blocks by just using the bitcoin internal miner
205 2013-07-16 08:41:00 <kinlo> and 1-2 bfl asics isn't enough nowadays to do solomining
206 2013-07-16 08:41:02 <petertodd> kinlo: it's really handy to be able to generate a testnet block in a few seconds by throwing a bunch of hashing power at it
207 2013-07-16 08:41:15 <petertodd> kinlo: depends on how long you are willing to wait... :)
208 2013-07-16 08:41:25 <kinlo> petertodd: true, but again, testnet is testnet :)
209 2013-07-16 08:41:43 <kinlo> I'm talking about the real bitcoin network
210 2013-07-16 08:42:54 <petertodd> kinlo: same code - I'm talking about technical limitations
211 2013-07-16 08:43:39 <kinlo> petertodd: I know bitcoind didn't scale to 100 GH when using pushpool... and 100GH is not enough to solomine
212 2013-07-16 08:44:45 <fluffypony> petertodd: that worked a charm, thanks :)
213 2013-07-16 08:45:58 <petertodd> kinlo: pff, I'm technically correct, the best type of correct
214 2013-07-16 08:46:15 <kinlo> petertodd: from time to time, you're a PITA :)
215 2013-07-16 08:46:48 <petertodd> kinlo: I'll read that as from time t_0=0s to time t_1=infinity...
216 2013-07-16 08:46:59 <kinlo> :p
217 2013-07-16 08:51:28 <bitnumus> can someone explain this
218 2013-07-16 08:51:29 <bitnumus> Estimated Confirmation Time \t7 hours (queue position 644)
219 2013-07-16 08:51:37 <bitnumus> and how the queue position can go up, thanks
220 2013-07-16 08:52:01 <petertodd> bitnumus: queue position can go up if someone makes a transaction with a higher fee than you paid
221 2013-07-16 08:52:10 <petertodd> it's not a first-in-first-out thing
222 2013-07-16 08:52:13 <bitnumus> which if you paid 0, is almost everyone
223 2013-07-16 08:52:15 <petertodd> it's an auction kinda
224 2013-07-16 08:52:18 <bitnumus> so you could be waiting forever
225 2013-07-16 08:52:21 <petertodd> yes
226 2013-07-16 08:52:22 <bitnumus> amazing idea..
227 2013-07-16 08:52:37 <bitnumus> something needs to be done about accidental 0 fee TXs
228 2013-07-16 08:52:47 <petertodd> Right now you can't change the fee you paid on your transaction after the fact; in the future you'll be able too.
229 2013-07-16 08:52:56 <petertodd> (can't easilly anyway)
230 2013-07-16 12:33:24 <enigmuriatic> approximately how many transactions have there been? the number i have in my blockparser output it twice what bitcoinexplorer.com suggests there are with its average block size value.
231 2013-07-16 12:33:30 <enigmuriatic> *is
232 2013-07-16 12:36:42 <sipa> enigmuriatic: tx=20748431
233 2013-07-16 12:36:54 <sipa> at block 246867
234 2013-07-16 12:37:10 <swulf--> sipa: got a quick moment?
235 2013-07-16 12:38:04 <swulf--> curious if you could look at tx c65a0df77a5548ae2f7901c2d63104b311aed31d456f648d2a2a6992a37699c4.. it's weird to me. how is it possible to have 0btc outputs? also, those 2 middle outputs, what format is the address in?
236 2013-07-16 12:38:17 <sipa> 0 BTC outputs are just valid
237 2013-07-16 12:38:24 <sipa> they are non-standard, but valid
238 2013-07-16 12:39:05 <swulf--> well, hmm. blockchain.info certainly won't propagate a 0btc output txn
239 2013-07-16 12:39:16 <sipa> why not?
240 2013-07-16 12:39:21 <swulf--> ACTION shrugs
241 2013-07-16 12:39:39 <swulf--> can I give you a tx i generated to look at?
242 2013-07-16 12:39:52 <sipa> and those two middle outputs have a pay-to-pubkey script, though the pubkey itself is not valid
243 2013-07-16 12:40:14 <swulf--> another weird thing on blockchain, is that it does decypher the pubkey
244 2013-07-16 12:40:24 <swulf--> and i'm not sure how they do it
245 2013-07-16 12:40:27 <swulf--> http://blockchain.info/tx/9f17e914db4db62844bafabd84a75f1cc9d8895f2ca2eaafc4ec9c463eb2cbb6
246 2013-07-16 12:40:31 <swulf--> arg not that one
247 2013-07-16 12:40:36 <swulf--> https://blockchain.info/tx/c65a0df77a5548ae2f7901c2d63104b311aed31d456f648d2a2a6992a37699c4
248 2013-07-16 12:40:55 <sipa> how do you mean "decipher" ?
249 2013-07-16 12:41:16 <swulf--> they "show" a bitcoin address, despite the pubkey not being version 0x02, 3 or 4
250 2013-07-16 12:41:23 <swulf--> are the addresses legit?
251 2013-07-16 12:41:41 <sipa> an pay-to-pubkeyhash address is just the hash of a pubkey
252 2013-07-16 12:41:47 <sipa> there is a pubkey there
253 2013-07-16 12:41:52 <sipa> at least, some hashable data
254 2013-07-16 12:42:00 <sipa> it's not a valid pubkey though, but they don't detect that
255 2013-07-16 12:42:24 <swulf--> so theoretically someone could spend this output (if it had nonzero value) ?
256 2013-07-16 12:42:43 <sipa> the zero value is irrelevant
257 2013-07-16 12:42:47 <sipa> you can still spend it
258 2013-07-16 12:42:52 <swulf--> good point
259 2013-07-16 12:42:57 <sipa> and no, not this one, since there is no valid public key
260 2013-07-16 12:43:02 <sipa> so any signature check would fail
261 2013-07-16 12:43:12 <sipa> but that's the only point where that can be detected
262 2013-07-16 12:43:26 <swulf--> blockchain shows a public key, and I can send coins to it, so the (hash of) the public key is valid
263 2013-07-16 12:43:56 <sipa> of course it is?
264 2013-07-16 12:43:59 <sipa> it's just a hash
265 2013-07-16 12:44:05 <sipa> so you can send to that hash
266 2013-07-16 12:44:15 <swulf--> ok
267 2013-07-16 12:44:18 <swulf--> ACTION gets it
268 2013-07-16 12:44:42 <swulf--> checksig requires a public key, but it's not a public key, but blockchain.info hashes it and turns it into a btc address anyway.
269 2013-07-16 12:45:43 <swulf--> sipa: seriously - your btc address and a tip is coming your way ;) you've helped me more times than i can count
270 2013-07-16 12:48:55 <swulf--> sipa: I've made a txn that gets rejected with sendrawtransaction but parses fine w/ decoderawtransaction. got a quick moment to take a look?
271 2013-07-16 12:51:55 <CheckDavid> When you are mining you are processing transactions right?
272 2013-07-16 12:53:41 <swulf--> Check: you don't have to process any transactions to mine, if you don't want to
273 2013-07-16 12:55:31 <swulf--> it seems weird to make a distinction between non-standard transactions and invalid transactions if both are rejected into the txmempool
274 2013-07-16 12:58:08 <CheckDavid> So, how are the transactions processed?
275 2013-07-16 12:58:23 <CheckDavid> I thought they needed the functions processed by miners.
276 2013-07-16 13:04:24 <swulf--> Miners can (and do) process them, but they aren't obligated to
277 2013-07-16 13:06:06 <CheckDavid> So what if miners decide not to?
278 2013-07-16 13:13:13 <sserrano44> quick question is 16 digits (8 decimal places) is good to represent a bitcoin amount
279 2013-07-16 13:16:52 <swulf--> CheckDavid: then they're abandoning potential transaction fees
280 2013-07-16 13:21:43 <CheckDavid> I see.
281 2013-07-16 13:29:17 <bitanarchy> primecoind listtransactions gives an empty list... am i missing a setting?
282 2013-07-16 13:37:22 <amiller> the version corrseponding to this nogleg guy is "grokked1.01b" and "grokked1.01"
283 2013-07-16 13:37:39 <amiller> i can't find any mention online of a "grokked" client but maybet hat's just the name for the tx spammer python script
284 2013-07-16 13:50:40 <BlueMatt> bitanarchy: if you dont have a prime number of transactions it doesnt return anything
285 2013-07-16 13:58:19 <phantomcircuit> BlueMatt, lol
286 2013-07-16 14:54:22 <helo> sserrano44: using an integer that can store values up to 2.1e15, and keeping all bitcoin balances in satoshi is the preferred approach, i think
287 2013-07-16 14:56:51 <phantomcircuit> helo, depends on what it's for
288 2013-07-16 14:57:11 <phantomcircuit> if it's for a financial application then it's better to use your databases native MONEY type
289 2013-07-16 14:57:27 <phantomcircuit> usually there's such a type which will refuse to round
290 2013-07-16 14:59:50 <helo> interesting
291 2013-07-16 15:16:12 <amiller> i figured out what the nogleg nodes were
292 2013-07-16 15:16:14 <amiller> the're p2pool nodes i think
293 2013-07-16 15:16:21 <amiller> does p2pool relay faster for some reason?
294 2013-07-16 15:17:49 <gmaxwell> amiller: p2pool doesn't speak the bitcoin p2p protocol except locally. A p2pool's bitcoin p2p is just the reference client.
295 2013-07-16 15:17:57 <amiller> hrm.
296 2013-07-16 15:20:32 <gmaxwell> Is there something that indicates that I was wrong about my assumption that it was just running a dumb fast block relayer?
297 2013-07-16 15:21:42 <amiller> not blocks, txes
298 2013-07-16 15:22:01 <amiller> i haven't sent it random invalid txes yet, but it doesn't just send "TX" without waiting for "INV" like i thought
299 2013-07-16 15:22:37 <amiller> er, without waiting for GETDATA.... (sending TX before GETDATA is a good way to the first to relay something and afaict causes no misbehavior demerits)
300 2013-07-16 15:24:13 <sipa> when you mine a block directly in bitcoind, it is immediately broadcast as 'block', without preceeding 'inv'
301 2013-07-16 15:28:18 <amiller> i'm only looking at tx relay behavior for now
302 2013-07-16 15:28:28 <amiller> we checked and it doesn't relay doublespends so it's definitely doing validation not just spam rleay
303 2013-07-16 15:29:06 <sipa> sure
304 2013-07-16 15:29:11 <sipa> nothing is relayed without validation
305 2013-07-16 15:30:39 <amiller> not in a satoshi client, but this is a "Grokked" client
306 2013-07-16 15:34:44 <gmaxwell> amiller: what kind of doublespend did it refuse to relay?
307 2013-07-16 15:36:53 <amiller> gmaxwell, the simplest kind, {input A, output B}, {input A, output B'} ??
308 2013-07-16 15:37:13 <sipa> the first one was accepted into the mempool
309 2013-07-16 15:37:28 <sipa> so the second one would fail validation, as it referred to inputs that were already spent
310 2013-07-16 15:37:59 <amiller> sipa, what i'm tryign to figure out is why the node at the top here relays so many txs so fast http://blockchain.info/hub-nodes
311 2013-07-16 15:38:10 <sipa> ah
312 2013-07-16 15:38:12 <gmaxwell> amiller: okay, but that doesn't preclude it doing actually expensive validations.
313 2013-07-16 16:18:18 <c4pt> anyone know how to adjust the font size in bitcoin-qt ?
314 2013-07-16 18:33:01 <avyd> hello
315 2013-07-16 18:35:37 <avyd> I'm on a bitcoin workshop and we would like to know if there is someone who can answer us a question about the future of bitcoin
316 2013-07-16 18:36:14 <MC1984> just ask
317 2013-07-16 18:36:15 <nsh> one way to find out would be to ask
318 2013-07-16 18:36:56 <avyd> so you can, it's great
319 2013-07-16 18:37:13 <sipa> depends on the question
320 2013-07-16 18:37:23 <sipa> whivch is hard to know without you asking :)
321 2013-07-16 18:37:54 <avyd> when are you planning to take action about the increasing size of the block chain?
322 2013-07-16 18:38:32 <nsh> (your question is misphrased. the blockchain is always increasing in size)
323 2013-07-16 18:38:45 <MC1984> pruning
324 2013-07-16 18:38:53 <MC1984> not until some other important stuff is worked out afaik
325 2013-07-16 18:39:05 <MC1984> pruning sux anyway
326 2013-07-16 18:39:27 <nsh> (oh, actually my reading comprehension is just awful)
327 2013-07-16 18:39:30 <nsh> (sorry)
328 2013-07-16 18:39:32 <avyd> we have already talked about it in our workshop and it sounds complicated
329 2013-07-16 18:39:45 <avyd> you can't just prune
330 2013-07-16 18:40:01 <avyd> or if you can how?
331 2013-07-16 18:40:19 <MC1984> just discard spent outputs in the chain
332 2013-07-16 18:40:55 <MC1984> the real answer is i dont see chainsize as a problem
333 2013-07-16 18:41:03 <MC1984> the UTXO and IDB is the problems
334 2013-07-16 18:41:27 <MC1984> btw im not a dev im just an irc bum
335 2013-07-16 18:42:34 <sipa> avyd: the blockchain will always grow
336 2013-07-16 18:42:51 <avyd> the chain size is not yet a problem but will be soon - the chain size is increasing faster then the storage and it's storage market price
337 2013-07-16 18:42:51 <sipa> but the question is what do you need the (full) block chain for
338 2013-07-16 18:43:10 <sipa> in particular, there is no need for every to store the full chaim
339 2013-07-16 18:43:17 <sipa> *everyone
340 2013-07-16 18:43:23 <MC1984> no its not
341 2013-07-16 18:43:35 <avyd> why?
342 2013-07-16 18:44:00 <sipa> the actual "state" of the bitcoin database is the set of unspent transaction outputs
343 2013-07-16 18:44:05 <MC1984> its 144mb/day max right now
344 2013-07-16 18:44:06 <avyd> the block chain doubles every 6 months
345 2013-07-16 18:44:12 <avyd> doesnt it?
346 2013-07-16 18:44:18 <MC1984> lol no its linear
347 2013-07-16 18:44:31 <sipa> you can see blocks as patches to the set of unspent outpits
348 2013-07-16 18:44:34 <sipa> outputs
349 2013-07-16 18:44:36 <gmaxwell> MC1984: it has a linear maximum, of 52gb/yr.
350 2013-07-16 18:44:52 <sipa> you only need to see them once, to build your own trusted database of unspent outputs
351 2013-07-16 18:44:54 <MC1984> ok, its linear at the block cap
352 2013-07-16 18:45:02 <sipa> after that, you do not need the blocks themself anymore
353 2013-07-16 18:45:04 <avyd> so every year we will have 52 gb more size in the chains?
354 2013-07-16 18:45:06 <MC1984> but i think were past the omg what is this new satosho dice thing now
355 2013-07-16 18:45:55 <MC1984> assuming stiff block competition, yes 52gb
356 2013-07-16 18:46:15 <sipa> avyd: again, yes the block chai will grow
357 2013-07-16 18:46:23 <sipa> avyd: but not everyone needs to store it
358 2013-07-16 18:47:04 <gmaxwell> avyd: under the current network rules a boring cheap 1TB disk would store 20 years of it; and as sipa points out, its not needed that all nodes store all of it.
359 2013-07-16 18:47:14 <MC1984> but note storing independant copies of the chain is important
360 2013-07-16 18:47:47 <gmaxwell> sure, saying that not _Everyone_ needs to store it doesn't mean that there don't need to be many copies of it.
361 2013-07-16 18:48:11 <MC1984> the more the merrier
362 2013-07-16 18:48:28 <MC1984> is as many different polities as possible
363 2013-07-16 18:51:19 <MC1984> what would be better is if BQT gets an spv transition mode and everyone forgets about the chainsize "problem"
364 2013-07-16 18:51:37 <MC1984> it seems to me like one of those things where humans are bad at assesing threats
365 2013-07-16 18:52:20 <avyd> so how is that 52GB calculated?
366 2013-07-16 18:52:52 <gmaxwell> avyd: a million bytes times 144*365.25
367 2013-07-16 18:52:57 <MC1984> 1MB blocks roughly every 10 minutes
368 2013-07-16 18:54:07 <sipa> MC1984: you had me thinking for a minute what 'BQT' stood for...
369 2013-07-16 18:54:20 <avyd> what if there are more transactions that do net fit a 1MB size?
370 2013-07-16 18:54:24 <MC1984> its just another one of my wackronyms
371 2013-07-16 18:54:29 <avyd> and there are much more transactions
372 2013-07-16 18:54:47 <helo> avyd: fee competition
373 2013-07-16 18:54:52 <helo> whoever pays the highest fees will get their transactions mined
374 2013-07-16 18:55:11 <helo> avyd: where this discussion is headed next is that bitcoin is limited to about seven transactions per second
375 2013-07-16 18:55:20 <MC1984> avyd have you read the bitcoin whitepaper?
376 2013-07-16 18:55:28 <sipa> until the blovk size limit is increased
377 2013-07-16 18:55:32 <sipa> block size
378 2013-07-16 18:56:18 <helo> avyd: so 1MB worth of transactions that pay the miner the most in fees get mined, and the rest wait
379 2013-07-16 18:58:24 <avyd> about the seven transactions limit - is it per user or per user?
380 2013-07-16 18:59:02 <gmaxwell> Are those my own two options?
381 2013-07-16 18:59:05 <gmaxwell> er only
382 2013-07-16 18:59:30 <phantomcircuit> avyd, uh.. no?
383 2013-07-16 18:59:37 <avyd> MC1984: I haven't read the whitepaper yet
384 2013-07-16 18:59:41 <helo> avyd: the 1MB limit for every ten minutes on average, with each transaction being 250 bytes leads to seven per second as a very rough estimate.
385 2013-07-16 19:00:58 <gmaxwell> avyd: you really should read the whitepaper before asking more questions. It's far from answering every question... but it's short and provides a good level set.
386 2013-07-16 19:02:09 <avyd> thank you, we didn't know about the wp. Where can we find it?
387 2013-07-16 19:02:46 <warren> I think Bing can find things. I haven't tried it myself.
388 2013-07-16 19:02:48 <gmaxwell> http://bitcoin.org/bitcoin.pdf
389 2013-07-16 19:03:41 <avyd> Thank you guys
390 2013-07-16 21:49:52 <boycey> Hey! Anybody have a problem compiling `multibit` ? Apparently it depends on an old version of bitcoinj, which uses `org.bouncycastle ` ??????
391 2013-07-16 21:50:22 <Luke-Jr> do we have a C++ std::string atoi equivalent?
392 2013-07-16 21:51:42 <sipa> http://www.cplusplus.com/forum/general/13135/ ?
393 2013-07-16 21:53:44 <Luke-Jr> found inlines in util.h <.<
394 2013-07-16 21:56:51 <sipa> Luke-Jr: ?
395 2013-07-16 21:57:20 <sipa> ah, we have an atoi64...
396 2013-07-16 21:57:25 <sipa> never knew that :D
397 2013-07-16 22:08:40 <Luke-Jr> where's the general shutdown code these days?
398 2013-07-16 22:18:11 <Luke-Jr> ACTION stabs GitHub for closing his pullreq on him
399 2013-07-16 23:06:31 <DiabloD3> [08:35:38] --> Twdsbiggestfan (~Twdsbigge@q-338-71-133-186.hsd0.ga.comcast.net) has joined #programming
400 2013-07-16 23:06:31 <DiabloD3> [08:36:09] <Twdsbiggestfan> Hi I own a HTML website, is there a way to ban a IP using only Html?
401 2013-07-16 23:06:31 <DiabloD3> [08:37:00] <Twdsbiggestfan> could anyone please help
402 2013-07-16 23:06:31 <DiabloD3> [08:37:36] <-- Twdsbiggestfan has quit (Client Quit)
403 2013-07-16 23:57:53 <PRab> Can an attacker send a merchant a transaction with many small TxOuts to force the merchant to waste more money on the fee to spend the received bitcoin?