1 2012-06-17 00:02:54 meLon has joined
2 2012-06-17 00:02:54 meLon has quit (Changing host)
3 2012-06-17 00:02:54 meLon has joined
4 2012-06-17 00:02:58 Karmaon has quit (Quit: WeeChat 0.3.9-dev)
5 2012-06-17 00:08:56 DomChan has quit (Away!18d4a977@gateway/web/freenode/ip.24.212.169.119|Ping timeout: 245 seconds)
6 2012-06-17 00:11:15 Karmaon has joined
7 2012-06-17 00:16:02 RainbowDashh has joined
8 2012-06-17 00:28:16 JZavala has joined
9 2012-06-17 00:28:54 rav3n_pl_away has quit (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
10 2012-06-17 00:29:18 <xorgate> looking at http://blockexplorer.com/tx/5a79e82995c7162bccfe6f3ca4eabee5ea6390bfb390971eeca7c9b806b9a3ca there are 2 inputs and several outputs, a few to satoshidice. how does SD know which of the 2 input addr to send any winnings to? does it matter?
11 2012-06-17 00:29:52 Z0rZ0rZ0r has quit (Ping timeout: 265 seconds)
12 2012-06-17 00:34:43 eoss has joined
13 2012-06-17 00:37:05 minimoose has joined
14 2012-06-17 00:41:28 sirk390 has quit (Quit: Leaving.)
15 2012-06-17 00:43:43 Karmaon has quit (Remote host closed the connection)
16 2012-06-17 00:45:08 JZavala has quit (Ping timeout: 240 seconds)
17 2012-06-17 00:58:33 <sipa> xorgate: it picks one
18 2012-06-17 01:00:18 <xorgate> sipa the only possibility is that the 2 inputs belong to the same wallet, right?
19 2012-06-17 01:00:53 <sipa> if you use services which pay back to the input addresses, you better make sure they do
20 2012-06-17 01:02:56 word has quit (Quit: Konversation terminated!)
21 2012-06-17 01:10:44 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
22 2012-06-17 01:11:54 AntKinGTube has quit (Read error: Connection reset by peer)
23 2012-06-17 01:31:48 jjjx has joined
24 2012-06-17 01:33:28 word has joined
25 2012-06-17 01:38:35 jjjx has quit (Quit: leaving)
26 2012-06-17 01:40:43 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
27 2012-06-17 01:42:14 RainbowDashh has joined
28 2012-06-17 01:47:18 Karmaon has joined
29 2012-06-17 01:48:20 graingert has joined
30 2012-06-17 01:59:22 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
31 2012-06-17 02:06:55 RainbowDashh has joined
32 2012-06-17 02:15:39 Zarutian has quit (Quit: Zarutian)
33 2012-06-17 02:21:35 Joric has quit ()
34 2012-06-17 02:22:38 Ukto has joined
35 2012-06-17 02:27:44 <luke-jr> does anyone else see this orphan issue as a serious problem?
36 2012-06-17 02:27:58 <luke-jr> all of a sudden, miners have a HUGE incentive to omit transactions from blocksâ¦
37 2012-06-17 02:29:31 <Ukto> I agree
38 2012-06-17 02:31:04 <Ukto> though, I dont think blocking SD transactions is a good idea/option
39 2012-06-17 02:32:40 <Ukto> I am actually impressed with SD for paying TXN's.
40 2012-06-17 02:32:46 <gmaxwell> Ukto: it's due to a bug.
41 2012-06-17 02:32:56 <gmaxwell> See TD's comments a few days ago.
42 2012-06-17 02:33:18 <gmaxwell> BitcoinJ can't tell if transactions meet the regular relay rules, so it pays fees on all txn.
43 2012-06-17 02:33:49 <gmaxwell> This has actually made SD far more a nusance than it would be otherwise. If it weren't paying fees the txn would all be low priority and would be handled after the txn of typical users.
44 2012-06-17 02:33:58 <Ukto> lol, well, still dont see an issue with that. if they stopped paying txn fees I would be more annoyed at the situation
45 2012-06-17 02:34:10 <Ukto> yeah
46 2012-06-17 02:34:14 <gmaxwell> Why? You'd be annoyed if it was less of a problem? ... er.
47 2012-06-17 02:34:50 <Ukto> they are within standards though right? sending small amounts w/ proper fee? correct?
48 2012-06-17 02:35:29 <luke-jr> Ukto: SD doesn't pay fees
49 2012-06-17 02:35:33 <luke-jr> Ukto: it forces its victims to
50 2012-06-17 02:35:51 coblee has quit (Ping timeout: 248 seconds)
51 2012-06-17 02:35:53 <Ukto> luke-jr: elaborate? sorry I missed something on that one
52 2012-06-17 02:36:00 <gmaxwell> And moreover the amount of fees adds up to a bitcent or two per block, it doesn't make mining more profitableâ it doesn't even offset the operating costs of impacting mining. So it's not like its contributing to network security either.
53 2012-06-17 02:36:07 <luke-jr> Ukto: SD takes the fee out of the victim's winnings
54 2012-06-17 02:36:10 <gmaxwell> Ukto: fees are paid out of ^
55 2012-06-17 02:36:10 <Ukto> its taking the fee from the amount given back to the users that that was their winnings?
56 2012-06-17 02:36:14 <Ukto> ah
57 2012-06-17 02:36:17 sirk390 has joined
58 2012-06-17 02:36:42 <Ukto> well, tbh, if the users dont care and use it, then its within reason, right?
59 2012-06-17 02:37:08 <luke-jr> Ukto: SD is basically an elaborate attack on Bitcoin that tricks people into financing it
60 2012-06-17 02:37:20 <luke-jr> but the real problem exists no matter what kind of transactions these are
61 2012-06-17 02:37:20 <gmaxwell> It basically breaks the assumption we had behind the use of fees to prevent blockchain DOS attacks: That few would want to attack to fill the chain enough to spend a bunch of bitcoin doing it.
62 2012-06-17 02:37:47 <gmaxwell> "oops"
63 2012-06-17 02:38:01 <luke-jr> the real problem is that accepting transactions *really does harm miners*, and in significant ways
64 2012-06-17 02:38:01 <Ukto> I was thinking of it as an elaborate way to gamble w/o having a central system :)
65 2012-06-17 02:38:17 <Ukto> luke-jr: that I have seen and agree upon
66 2012-06-17 02:38:27 <gmaxwell> And of course, they don't advertise that in their house percent etc.
67 2012-06-17 02:38:41 <Ukto> gmaxwell: agreed, but its not out business
68 2012-06-17 02:38:41 <gmaxwell> Ukto: huh??? the operator of the site absolutely is a central system.
69 2012-06-17 02:38:51 <luke-jr> the only obvious solution to this IMO, is that miners reject all no-fee txns, and require fees that balance out their risk of being orphaned for including them
70 2012-06-17 02:39:09 <Ukto> gmaxwell: sorry, retract, half thought :)
71 2012-06-17 02:39:24 <Ukto> I do agree with luke to an extent
72 2012-06-17 02:39:24 <luke-jr> which might make Bitcoin too expensive to gain adoption
73 2012-06-17 02:39:37 <Ukto> i think there should just be a limit on no-txn fee transactions per block
74 2012-06-17 02:39:47 <luke-jr> Ukto: already is
75 2012-06-17 02:39:50 <luke-jr> but Dice isn't no-fee
76 2012-06-17 02:39:50 <gmaxwell> Ukto: ... er that doesn't help.
77 2012-06-17 02:40:16 * luke-jr wonders how to calculate the transaction fee requirements based on new info
78 2012-06-17 02:40:57 <luke-jr> gmaxwell: what do you think about optimizing standard scripts (and detection thereof)? would it make any impact on block acceptance times?
79 2012-06-17 02:41:19 <Ukto> before i forget, as far as what they post on their site for advertisements prices/winnings/fees, is not our concern. we are not here to nudge how ppl use bitcoins.
80 2012-06-17 02:41:20 <freewil> maybe we just need a better market to determine tx fees
81 2012-06-17 02:41:24 <luke-jr> (the code to do so would be ugly, I imagine)
82 2012-06-17 02:41:27 <Ukto> but it is causing a major problem
83 2012-06-17 02:41:50 <gmaxwell> Ukto: They're decieving people by understating what they return and by doing so fund a flodding attack.
84 2012-06-17 02:41:58 <Ukto> gmaxwell: not our thing
85 2012-06-17 02:42:07 <Ukto> ppl decieve ppl every day
86 2012-06-17 02:42:10 <Ukto> we are not judges
87 2012-06-17 02:42:21 <Ukto> besides, ppl learn, and realize
88 2012-06-17 02:42:24 <gmaxwell> Ukto: It's not your business to tell me what I'm concerned about. I'm always concerned about deceptive practices that hurt bitcoin users.
89 2012-06-17 02:42:25 <Ukto> if they are unhappy, they wont use it anymore
90 2012-06-17 02:42:32 <Ukto> gmaxwell: no, i agree with that
91 2012-06-17 02:42:43 <Ukto> i am saying as far as the bitcoin system itself goes. :)
92 2012-06-17 02:43:06 <freewil> is there any easy way for a normal user to analyze bitcoin fees and see how they are being prioritized on the network and be able to guess an appropriate fee for their needs
93 2012-06-17 02:43:23 <gmaxwell> freewil: no because you can't tell what the relationship is behind the transaction's acceptance.
94 2012-06-17 02:43:28 <Ukto> blocking someones address, however you do it, is not the answer was what i started with
95 2012-06-17 02:43:44 <gmaxwell> freewil: for example, luke has relationships with mtgox and other sites to process free transactions for them fast.
96 2012-06-17 02:44:12 <gmaxwell> Ukto: Blocking it where?
97 2012-06-17 02:44:32 <freewil> well excluding that
98 2012-06-17 02:44:33 <Ukto> gmaxwell: as for mtgox, one would think that most if not all of their sends would be free anyways with aged coins, etc etc
99 2012-06-17 02:44:41 <freewil> can you see how long a tx sits in the memory pool:?
100 2012-06-17 02:44:44 <Ukto> freewil: there is no exlcuding that
101 2012-06-17 02:44:45 <gmaxwell> Ukto: users paying them.
102 2012-06-17 02:45:12 <gmaxwell> freewil: you can't distinguish that stuff, that was my point.
103 2012-06-17 02:45:26 minimoose has quit (Quit: minimoose)
104 2012-06-17 02:46:16 <freewil> so there would have to at least be a bit of "human intervention" to account for that
105 2012-06-17 02:46:17 <gmaxwell> You can see a bunch of txn get processed quickly and think you don't need a fee. Besides thats no a solution. Making every pay 0.0005 fees still makes bitcoin less attractive, even though we have plenty of space for free transactions still, so long as the transactions that don't need confirmation get delayed.
106 2012-06-17 02:46:20 <Ukto> gmaxwell: blocking/OMIT'ing as luke mentioned when i first entered. I think it would be a bad thing. :)
107 2012-06-17 02:46:48 <D34TH> hey gues what does the envelope with the paper net to balance on blockchain.info do
108 2012-06-17 02:46:56 <gmaxwell> Ukto: varrious miners omit a bunch of stuff already. ::shrugs::
109 2012-06-17 02:46:58 <D34TH> i think i just rm-rf'ed my addr
110 2012-06-17 02:47:23 <luke-jr> return DoS(100,error("ConnectInputs() : %s VerifySignature failed", GetHash().ToString().substr(0,10).c_str()));
111 2012-06-17 02:47:30 <luke-jr> ^ IMO, we need to get rid of that DoS bit ASAP
112 2012-06-17 02:47:35 <Ukto> 0,o
113 2012-06-17 02:47:58 <gmaxwell> luke-jr: hum? why?
114 2012-06-17 02:47:58 <phantomcircuit> luke-jr, why id someone is spamming you with tx's that dont verify seems reasonable to stop listening to them
115 2012-06-17 02:48:13 <gmaxwell> are we VerifySignature failing on orphans?
116 2012-06-17 02:48:14 <luke-jr> gmaxwell: so nodes can verify a random transaction or two, relay, then go back and finish
117 2012-06-17 02:48:15 TheSeven has quit (Disconnected by services)
118 2012-06-17 02:48:17 [7] has joined
119 2012-06-17 02:48:29 <gmaxwell> yea, that sounds like a terrible idea.
120 2012-06-17 02:48:41 <luke-jr> â¦
121 2012-06-17 02:48:51 <gmaxwell> then someone could just dos the whole network by sending out floods of transactions with bad signatures.
122 2012-06-17 02:48:59 <luke-jr> gmaxwell: OK, just in blocks
123 2012-06-17 02:49:58 <gmaxwell> luke-jr: you'd still want to DoS for blocks. If you only partially check blocks and sometimes pass on a bad one, thats your risk.. but when you get a bad one you should still hang up on the peer that gave it to you.
124 2012-06-17 02:50:25 <gmaxwell> Presumably the cache will speed up those verification if they're txn you've heard before.
125 2012-06-17 02:51:01 <luke-jr> gmaxwell: why should you hang up on that peer?
126 2012-06-17 02:51:15 <Ukto> cause if they send one bad, you can expect more
127 2012-06-17 02:51:18 <luke-jr> just because they only partly verified the block?
128 2012-06-17 02:51:51 <gmaxwell> Because they're sending you bad blocks. presumably if you're not the source you'll also evenually hand up on the source and other peers will stop hanging up on you.
129 2012-06-17 02:51:51 <Ukto> then you gotta spend time verifying a bunch, and could/probbaly end up wasting resources
130 2012-06-17 02:51:52 <Ukto> for nothing
131 2012-06-17 02:51:58 <freewil> instead of a static tx fee, what if the user could specify a "max fee" and they would only pay what is necessary to get their tx processed up to the max
132 2012-06-17 02:52:12 <Ukto> freewil: doesnt work that way
133 2012-06-17 02:52:19 <Ukto> the fee has to be paid at time
134 2012-06-17 02:52:28 <gmaxwell> freewil: The software can't tell "what is necessary".
135 2012-06-17 02:52:31 <luke-jr> Ukto: it can.
136 2012-06-17 02:52:43 <Ukto> luke-jr: ?
137 2012-06-17 02:52:44 <gmaxwell> through kinda kludgy ways.
138 2012-06-17 02:52:54 <gmaxwell> Ukto: e.g. replacing the transaction when it fails to go through.
139 2012-06-17 02:52:58 <luke-jr> Ukto: Bitcoin could support changing fees later
140 2012-06-17 02:53:05 <Ukto> couldnt that be abused
141 2012-06-17 02:53:07 <luke-jr> Eligius already does, in more kludgy ways
142 2012-06-17 02:53:10 <Ukto> to empty accounts
143 2012-06-17 02:53:13 <luke-jr> Ukto: depends on replacement rules
144 2012-06-17 02:53:29 <luke-jr> Ukto: only allow replacing transactions if all the same outputs get paid at least just as much ;)
145 2012-06-17 02:53:32 <gmaxwell> Ukto: the sender would have to keep the private keys in memory and keep on signing new versions.
146 2012-06-17 02:53:50 <Ukto> and have to stay online
147 2012-06-17 02:53:54 <luke-jr> gmaxwell: or pre-sign a bunch at send time, and only broadcast them later
148 2012-06-17 02:54:08 <gmaxwell> good point.
149 2012-06-17 02:54:08 <Ukto> so if bitcoin win client does it, and they close the client/shutoff comp, they cant adjust
150 2012-06-17 02:54:13 <gmaxwell> Ukto: correct.
151 2012-06-17 02:54:24 <luke-jr> gmaxwell: also, smart clients might combine transactions at the same time
152 2012-06-17 02:54:31 <Ukto> then you get a whole bunch of broadcast wars
153 2012-06-17 02:54:33 <gmaxwell> luke-jr: halarious, looking at dice transactions I see quite a few payments to their low payout addresses where if they win ~100% of it goes to fee.
154 2012-06-17 02:54:36 <Ukto> to fight over paying higher transactions
155 2012-06-17 02:55:01 <gmaxwell> Ukto: I don't think thats an actual concern. But it would motivate miners to delay txn in the hopes of getting more fees.
156 2012-06-17 02:55:16 <gmaxwell> But I'm not aware of anything better than that.
157 2012-06-17 02:55:37 <Ukto> and realistically, its a client side "option" doing it that way
158 2012-06-17 02:55:42 <Ukto> not really a component to the network itself
159 2012-06-17 02:55:46 <Ukto> since it really already supports it
160 2012-06-17 02:55:54 <Ukto> in a "kludgy" way :P
161 2012-06-17 02:56:06 <gmaxwell> well, no .. nodes won't relay the replacement now.
162 2012-06-17 02:56:17 <gmaxwell> Not until the original ages out.
163 2012-06-17 02:56:33 <Ukto> hm, whats the age limit ?
164 2012-06-17 02:56:40 <luke-jr> Ukto: neve
165 2012-06-17 02:56:41 <luke-jr> r
166 2012-06-17 02:56:53 <Ukto> i see the point in having a limit. wait, what? :P
167 2012-06-17 02:56:55 <gmaxwell> In practice a replacement works in a few days.
168 2012-06-17 02:56:59 <freewil> just seems like there needs to be more transparent market for tx fees, not sure if that needs to be implemented within the protocol or some sort of contract trading
169 2012-06-17 02:57:30 <gmaxwell> freewil: oh awesome so to use bitcoin first you have to participate in some wacked market to buy room for fees?
170 2012-06-17 02:57:31 <luke-jr> gmaxwell: so why should we always ban peers who relay blocks with invalid sigs?
171 2012-06-17 02:57:42 <freewil> lol just brainstorming
172 2012-06-17 02:57:51 <Ukto> gmaxwell: could also have an abused system. post a BUNCH of txn's using diff clients, and have them forcefull war at eahc other to force the price up, until its horrid
173 2012-06-17 02:58:02 <gmaxwell> luke-jr: becuase relaying txn with invalid sigs is a really awesome DOS attack.
174 2012-06-17 02:58:14 <luke-jr> gmaxwell: *blocks*
175 2012-06-17 02:58:35 <gmaxwell> luke-jr: because blocks with invalid sigs being accepted endanger the network.
176 2012-06-17 02:58:39 <Ukto> gmaxwell: i think hes saying to waste resources on checking all requests, invalid or not, but not relay invalids
177 2012-06-17 02:58:48 <luke-jr> gmaxwell: they won't be accepted, just relayed without banning
178 2012-06-17 02:58:59 <Ukto> why bother relaying them if they are bad?
179 2012-06-17 02:59:11 <luke-jr> the goal is to minimize propagation of blocks
180 2012-06-17 02:59:19 <Ukto> then why bother relaying them if they are bad?
181 2012-06-17 02:59:22 <luke-jr> or at least make it not dependent on how many transactions miners put in them
182 2012-06-17 02:59:26 <Ukto> [21:57] <luke-jr> gmaxwell: they won't be accepted, just relayed without banning
183 2012-06-17 02:59:35 <luke-jr> Ukto: you don't know they're bad until you spend seconds of verification
184 2012-06-17 02:59:36 <gmaxwell> luke-jr: I see what you're saying.
185 2012-06-17 03:00:05 <gmaxwell> Why don't we create some fast relay hubs for this instead.
186 2012-06-17 03:00:25 <Ukto> relay-daemons?
187 2012-06-17 03:00:36 <gmaxwell> startup a collection of cutdown nodes that relay blocks while only checking the headers, and encourage miners to connect to one or more of them.
188 2012-06-17 03:00:46 <luke-jr> gmaxwell: then the miners ban the hubs? :P
189 2012-06-17 03:01:04 <gmaxwell> well, we give a switch so you'll never ban something you've addnoded. We should already have that.
190 2012-06-17 03:03:59 <gmaxwell> also, IIRC we could make nodes choose the winner in a tie based on the time they started hearing the block rather than when they finished validating it.
191 2012-06-17 03:04:12 <gmaxwell> er IIRC we're already timestamping at message start.
192 2012-06-17 03:04:55 <luke-jr> gmaxwell: that's not the problem
193 2012-06-17 03:05:18 <gmaxwell> I know, its the cascade between nodes.
194 2012-06-17 03:05:32 <gmaxwell> But the non-validating hubs would help.
195 2012-06-17 03:06:03 <gmaxwell> s/help/basically solve that/ and also increase robustness against attacks that try to split miners to get them mining on seperate forks.
196 2012-06-17 03:06:29 <luke-jr> it only solves/helps if every miner participates in it
197 2012-06-17 03:06:49 <gmaxwell> every doesn't half to.... but if a majority of hashpower does than the minority will be at a disadvantage.
198 2012-06-17 03:07:11 <gmaxwell> Somehow I don't feel bad about income reductions for inattentive miners.
199 2012-06-17 03:07:51 <Ukto> tbh, its a decent idea. once relays are up, miners will want to join, or have a higher chance at orphan
200 2012-06-17 03:08:31 <luke-jr> I made 3 changes to Eligius to try to deal with thisâ¦
201 2012-06-17 03:08:34 <gmaxwell> Ukto: when you don't preface with tbh are you being dishonest?
202 2012-06-17 03:08:34 <luke-jr> 1) block 1dice outputs
203 2012-06-17 03:08:41 <Ukto> gmaxwell: sometimes
204 2012-06-17 03:08:43 <luke-jr> 2) limit blocks to 32 transactions max
205 2012-06-17 03:08:56 <luke-jr> 3) addnode at least 8 peers, all from biggest mining pool
206 2012-06-17 03:08:57 <luke-jr> s
207 2012-06-17 03:09:03 <luke-jr> hard to know which ones help how much :/
208 2012-06-17 03:09:32 <gmaxwell> well I think (1) is redundant in the face of (2) but if you're only mining 32 txn I'm glad that all of them aren't 1dice txn.
209 2012-06-17 03:09:37 <luke-jr> gmaxwell: imo, tbh implies it crossed ones mind to be dishonest on that particular point :P
210 2012-06-17 03:09:46 <Ukto> luke-jr: when you block, how many transactions do you create in payouts on avg? (yes, i know they are not part of the 32count.) just curious
211 2012-06-17 03:09:50 coblee has joined
212 2012-06-17 03:09:59 <luke-jr> Ukto: 0
213 2012-06-17 03:10:11 <luke-jr> or 1 if you count generation
214 2012-06-17 03:10:19 <luke-jr> and technically the coinbase is counted in the 32
215 2012-06-17 03:10:47 <gmaxwell> the many coinbase outputs don't have the validation slowness issue, they're probably irrelevant for this.
216 2012-06-17 03:11:21 <Ukto> no, i was thinking of it a diff way, but once luke said 0 i remembered sendmany :P
217 2012-06-17 03:11:32 <gmaxwell> Ukto: eligius does coinbase payments.
218 2012-06-17 03:11:32 <luke-jr> gmaxwell: well, data size do
219 2012-06-17 03:11:49 <gmaxwell> luke-jr: yea, I'm assuming the data size isn't the big issue. but thats a guess thus 'probably'.
220 2012-06-17 03:12:47 sirk390 has quit (Quit: Leaving.)
221 2012-06-17 03:38:40 <gavinandresen> 32 transactions? wtf are you thinking?
222 2012-06-17 03:39:06 <luke-jr> gavinandresen: I'm thinking we've lost 300 BTC and we're over 1000 BTC behind average.
223 2012-06-17 03:39:26 <gavinandresen> lost 300BTC to who?
224 2012-06-17 03:39:37 <luke-jr> gavinandresen: to the transactions we've accepted
225 2012-06-17 03:39:50 <gavinandresen> No, I mean who took those 300 BTC from you?
226 2012-06-17 03:39:53 <luke-jr> gavinandresen: the delay in validating our blocks causes them to be orphaned
227 2012-06-17 03:40:18 <luke-jr> 3 in a row, twice now
228 2012-06-17 03:40:32 <gavinandresen> what block numbers?
229 2012-06-17 03:41:24 <luke-jr> I don't know any easy way to get that, so it'll be a minute as I loop through gettransaction+getblockâ¦
230 2012-06-17 03:42:23 <luke-jr> hmm
231 2012-06-17 03:42:28 <gavinandresen> 183519 looks like yours
232 2012-06-17 03:42:30 <luke-jr> gettransaction doesn't link coinbases to their blocks
233 2012-06-17 03:42:42 <gavinandresen> ... but you won that...
234 2012-06-17 03:43:32 <gmaxwell> luke-jr: just give the txn id for the orphaned coinbases.
235 2012-06-17 03:43:45 <luke-jr> 184836
236 2012-06-17 03:43:56 int0x27h has quit (Read error: Operation timed out)
237 2012-06-17 03:44:17 <luke-jr> gmaxwell: 1225216f4fb4b3e473dfdf529571cdf6d30898acfbd39cf8b63851b9b2f92112 210f03011883b8dbaf00a1c49fd174426999f0ca2a981d2706615d7a8b9a4014 0e22ee1a5bafb3f4e0e35b814b4517fef1be10528edfa1158709242cf756171a 13a919884cee6f0125cffc589644b844727a80130d0c973a7baa29e48b0d6d2f da0eda43bdad26df9e50871f4229e02668663b6e6aab4e286509909acb36c848 bd62530ce87d1e94bb675261543c408e8e2c42f9ee3ce0986d9b71e5ebdc3a70
238 2012-06-17 03:45:32 <gavinandresen> block 184836 in the main chain has 373 transactions in it
239 2012-06-17 03:45:43 <luke-jr> gavinandresen: it's not just Eligius experiencing it
240 2012-06-17 03:46:15 <luke-jr> fwiw, Eligius's 184836 had 512 txns
241 2012-06-17 03:46:54 <luke-jr> another was Ozcoin/570ish vs Eligius/1024
242 2012-06-17 03:47:32 <gavinandresen> I'm looking at http://blockchain.info/orphaned-blocks ... I'd want to see somebody do some real statistical analysis to see if there's just bad luck or if smaller blocks really do have a significant advantage
243 2012-06-17 03:48:03 <gavinandresen> (e.g. 184577 a 629txn block orphaned a 127 txn block from deepbit
244 2012-06-17 03:48:35 <gavinandresen> I DO like the idea of a new form of getblock that just gets the header and list of transactions, though.
245 2012-06-17 03:48:47 <gavinandresen> (list of transaction hashes)
246 2012-06-17 03:50:57 moartr4dez has joined
247 2012-06-17 03:51:00 ah-bitcoin has joined
248 2012-06-17 03:51:35 Smoovious has joined
249 2012-06-17 03:52:45 gavinandresen has quit (Quit: gavinandresen)
250 2012-06-17 03:53:48 <TuxBlackEdo> that right there was funny ^
251 2012-06-17 03:54:47 AntKinGTube has joined
252 2012-06-17 03:54:53 <luke-jr> gmaxwell: I don't see any code to ignore DoS for addnode peers
253 2012-06-17 03:55:44 int0x27h has joined
254 2012-06-17 04:13:38 vragnaroda has quit (Quit: /ignore *!*@*)
255 2012-06-17 04:19:35 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
256 2012-06-17 04:29:04 da2ce7 has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
257 2012-06-17 04:29:21 int0x27h has quit (Changing host)
258 2012-06-17 04:29:21 int0x27h has joined
259 2012-06-17 04:36:01 RainbowDashh has joined
260 2012-06-17 04:41:03 da2ce7 has joined
261 2012-06-17 04:54:28 <Ukto> gmaxwell: if you did the relay nodes, you would have to have some flag to pass to regular bitcoind's to let them know its a relay, so they dont block the relay nodes :P (not sure what to do about older bitcoind's)
262 2012-06-17 04:55:52 <Ukto> besides, all it would take is for a smaller miner to put up a few relay nodes, string them together, and not accept txn's and try to get orphan overrides :P
263 2012-06-17 04:55:58 <Ukto> right?
264 2012-06-17 04:57:45 MobiusL has quit (Remote host closed the connection)
265 2012-06-17 04:58:03 RainbowDashh is now known as Rabbit67890
266 2012-06-17 04:58:45 MobiusL has joined
267 2012-06-17 04:58:52 Rabbit67890 is now known as RainbowDashh
268 2012-06-17 05:03:15 brwyatt is now known as brwyatt|Away
269 2012-06-17 05:05:49 vragnaroda has joined
270 2012-06-17 05:10:08 maaku has joined
271 2012-06-17 05:36:59 vragnaroda has quit (Quit:)
272 2012-06-17 05:37:50 vragnaroda has joined
273 2012-06-17 05:40:46 rlifchitz has quit (Quit: "I never worry about action, but only about inaction" (W. Churchill))
274 2012-06-17 05:49:07 copumpkin has joined
275 2012-06-17 05:53:25 eoss has quit (Quit: Leaving)
276 2012-06-17 05:55:52 eoss has joined
277 2012-06-17 05:55:52 eoss has quit (Changing host)
278 2012-06-17 05:55:52 eoss has joined
279 2012-06-17 05:59:55 AntKinGTube has quit (Quit: Leaving)
280 2012-06-17 06:03:36 Karmaon has quit (Remote host closed the connection)
281 2012-06-17 06:04:57 Karmaon has joined
282 2012-06-17 06:26:57 copumpkin has quit (Quit: Computer has gone to sleep.)
283 2012-06-17 06:33:13 dvide has joined
284 2012-06-17 06:38:12 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
285 2012-06-17 06:39:11 luke-jr has quit (Ping timeout: 248 seconds)
286 2012-06-17 06:44:57 D34TH has quit (Read error: Connection reset by peer)
287 2012-06-17 06:52:42 ovidiusoft has joined
288 2012-06-17 07:05:57 MysteryBanshee has joined
289 2012-06-17 07:11:07 RainbowDashh has joined
290 2012-06-17 07:26:03 <Graet> ;;later tell gavinandresen lukes theory failed at least one time , eligius block (32 txn) orphaned by Ozcoin block (522 txn) height 184932
291 2012-06-17 07:26:03 <gribble> The operation succeeded.
292 2012-06-17 07:33:48 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
293 2012-06-17 07:35:46 <MysteryBanshee> Graet: What theory is that? lol
294 2012-06-17 07:36:42 <Ukto> mysil2: just let it go for now :)
295 2012-06-17 07:36:51 <Ukto> er MysteryBanshee eve
296 2012-06-17 07:36:51 <Ukto> n
297 2012-06-17 07:36:59 <MysteryBanshee> ok
298 2012-06-17 07:37:25 <Graet> MysteryBanshee, that by limiting eligius blocks to 32txn he would have less orphan
299 2012-06-17 07:37:36 <MysteryBanshee> oh
300 2012-06-17 07:37:39 <Ukto> cause the would propgate faster
301 2012-06-17 07:37:39 <Graet> as smaller blocks propagat quicker
302 2012-06-17 07:37:51 <Graet> he has had a bad ruhn lately :/
303 2012-06-17 07:38:06 <Ukto> the idea has been proven not so accurate so far
304 2012-06-17 07:38:32 <Graet> well its va small smple ;)
305 2012-06-17 07:38:35 <Ukto> wait
306 2012-06-17 07:38:41 <Ukto> Graet: if hes only doing 32txns...
307 2012-06-17 07:38:49 <Ukto> wouldnt that mean a huge backlog should be starting for mtgox ?
308 2012-06-17 07:39:00 <Ukto> hadnt seen any goxers complain yet...
309 2012-06-17 07:39:20 <Graet> um, i dont know thier relationship anymore, but network wide txns are bgacking up
310 2012-06-17 07:39:33 <Ukto> until ozco cleans em out :P
311 2012-06-17 07:39:33 <Graet> have been since deepbit limited satoshidice txnws
312 2012-06-17 07:39:43 <Graet> hehe
313 2012-06-17 07:39:59 <Graet> good advertising maybe? come help clean up the txn spam :P
314 2012-06-17 07:40:10 RainbowDashh has joined
315 2012-06-17 07:40:13 <Eliel> Graet: small blocks are by no means guaranteed to win over big blocks. A big block can win if it has a sufficient head start.
316 2012-06-17 07:40:32 <Ukto> Eliel: thats what I think luke needs to consider
317 2012-06-17 07:40:42 <Graet> well according to timestamps eligius was 3 mins ahead of ozcoin (for what timestamps are worth)
318 2012-06-17 07:40:56 <Ukto> he has only purely blamed blocksize, thus he limited his txns to 32
319 2012-06-17 07:41:10 <Graet> and it is not my theory, i just showed an instance where luke's thoery did not work :)
320 2012-06-17 07:41:24 <Ukto> and its only one of such proof
321 2012-06-17 07:41:30 <Ukto> by not means does that make it fact
322 2012-06-17 07:41:37 <Graet> yes, i mentioned smal;l sample :)
323 2012-06-17 07:41:38 <Eliel> Graet: my point mostly is that just one of those could easily be chance.
324 2012-06-17 07:41:39 <Ukto> and I cant type, must be tired
325 2012-06-17 07:41:58 <Graet> i am not disagreeing Eliel
326 2012-06-17 07:42:01 <Eliel> since those are expected, no matter the number of transactions :)
327 2012-06-17 07:42:23 <Graet> but lukes reason for limiting to 32txn was?....
328 2012-06-17 07:42:46 <Ukto> yeah, while the SD txn spam has been harsh on the bitcoind's for processing, etc... i dont know that it caused lukes bad luck w/ orphans. I think thats the point
329 2012-06-17 07:42:49 <Graet> again this is his idea, i am simply showing 1 instance where it failed
330 2012-06-17 07:42:51 <Eliel> I think he's panicing over 6 orphans.
331 2012-06-17 07:43:10 <Ukto> I remember slush used to get 2~3 a day
332 2012-06-17 07:43:10 <Graet> 7 now :P
333 2012-06-17 07:43:21 <Ukto> when i mined there less than a year ago
334 2012-06-17 07:43:27 <Eliel> yep, so he's trying things he thinks might help.
335 2012-06-17 07:43:53 <Eliel> if the number of orphans keeps growing, regardless, it's time to figure out something else to do.
336 2012-06-17 07:44:01 <Graet> indeed
337 2012-06-17 07:44:14 <Graet> imo we still need to figure out what to do
338 2012-06-17 07:44:18 <Ukto> slow down the network w/ higher diff :P
339 2012-06-17 07:44:45 <Graet> bitcoinds are algging, the network is being ag=ffected, txn that uised to take 1 block for as confirm are taking 9 or 10 etc etc
340 2012-06-17 07:45:21 <midnightmagic> i never wait more than 1-2 blocks for my first confirmation
341 2012-06-17 07:46:14 <Graet> good for you :)
342 2012-06-17 07:46:29 <MysteryBanshee> im usually cool with unconfirmed transactions
343 2012-06-17 07:48:04 * Eliel wonders how big percetange of miners is now blocking 1dice
344 2012-06-17 07:49:29 <Graet> i can vouch that 10.9% of the network is NOT blocking satoshi dice or any other txns
345 2012-06-17 07:49:52 <Eliel> that's ozcoin?
346 2012-06-17 07:50:11 <Graet> yes
347 2012-06-17 07:50:18 <Graet> currently
348 2012-06-17 07:52:23 <guruvan> are you deprioritizing them in anyway yet Graet?
349 2012-06-17 07:54:58 <Graet> no
350 2012-06-17 08:00:38 PK has joined
351 2012-06-17 08:01:33 maaku has quit (Quit: maaku)
352 2012-06-17 08:16:19 molecular has quit (Ping timeout: 245 seconds)
353 2012-06-17 08:17:12 molecular has joined
354 2012-06-17 08:18:10 tcatm has quit (Read error: Connection reset by peer)
355 2012-06-17 08:18:27 tcatm_ has joined
356 2012-06-17 08:19:06 erle- has joined
357 2012-06-17 08:33:29 <MysteryBanshee> 5JMR9dF6zGrD9VywbKH38cJEjNVbDfdjYBFjzgiCwH7WPiQ(XX) Guess the last two digits for some BTC and import the private key :P
358 2012-06-17 08:35:13 <Ukto> there sonyl so many possiblities. a quick script can do it :P
359 2012-06-17 08:35:19 <Ukto> o
360 2012-06-17 08:35:19 <Ukto> r
361 2012-06-17 08:37:36 <MysteryBanshee> :)
362 2012-06-17 08:38:04 <MysteryBanshee> lol someones claimed it
363 2012-06-17 08:38:07 <MysteryBanshee> 1HocL2c3U7ZSXeb2GuzDEaR2QcsfoQh6Mv was the public address
364 2012-06-17 08:38:11 <MysteryBanshee> congratulations :)
365 2012-06-17 08:40:14 <Ukto> how mucho was in there ? :P
366 2012-06-17 08:42:35 <doublec> Graet: how's the pool load with the extra transactions floating around? Has it impacted much at all?
367 2012-06-17 08:42:57 <doublec> my bitcoind cpu % has gone through the roof now that the memory pool is large
368 2012-06-17 08:43:11 RazielZ has joined
369 2012-06-17 08:43:53 * Eliel thinks a hashtable for looking up transactions in the memory pool is needed.
370 2012-06-17 08:44:08 <Graet> yes cpu usage has gone up like 50% at least
371 2012-06-17 08:44:28 <Graet> lagging bitcoind so longpoll is slow and miners get extra stales around longpoll
372 2012-06-17 08:44:31 <Ukto> Graet.. more hashing.. :P
373 2012-06-17 08:44:53 <doublec> it's the collecting of transactions into a priority order that's causing the cpu suckage on my system
374 2012-06-17 08:45:10 <doublec> costantly iterating over the memory pool to create that list
375 2012-06-17 08:45:46 <doublec> perhaps that could be calculated periodically and cached
376 2012-06-17 08:46:01 paraipan has quit (Ping timeout: 276 seconds)
377 2012-06-17 08:47:32 <Eliel> Ukto: I think the hashing has already been done :)
378 2012-06-17 08:47:56 <Eliel> doublec: oh, so it's not hashtable that's needed but a priority queue?
379 2012-06-17 08:48:21 <doublec> Eliel: see the priority handling in CreateNewBlock in main.cpp
380 2012-06-17 08:48:34 sirk390 has joined
381 2012-06-17 08:51:22 Pasha has joined
382 2012-06-17 08:52:09 <[Tycho]> CreateNewBlock isn't called that frequently.
383 2012-06-17 08:52:30 Cory has quit (Disconnected by services)
384 2012-06-17 08:52:33 Pasha is now known as Cory
385 2012-06-17 08:53:32 <Eliel> would it be called at all for non-mining node at all?
386 2012-06-17 08:55:06 <doublec> try an experiment, comment out that transaction priority handling, and see how much your cpu % drops
387 2012-06-17 08:58:30 <doublec> hmm. you're right that it should only be called every 60 seconds
388 2012-06-17 08:58:33 jine has quit (Ping timeout: 245 seconds)
389 2012-06-17 08:59:22 paraipan has joined
390 2012-06-17 09:00:25 <doublec> ah, disregard, my timing was being intefered with by other changes
391 2012-06-17 09:10:03 <doublec> still seeing that having a big effect on load. I'll have to dig into why on my system it's getting called so much. Maybe some merge mining issue.
392 2012-06-17 09:11:07 _Fireball has joined
393 2012-06-17 09:11:48 <PK> Ukto: it was 0.17351254 BTC
394 2012-06-17 09:15:58 sirk390 has quit (Quit: Leaving.)
395 2012-06-17 09:20:38 wizkid057 has quit (Read error: Operation timed out)
396 2012-06-17 09:20:51 graingert1 has joined
397 2012-06-17 09:21:36 wizkid057 has joined
398 2012-06-17 09:22:10 [7] has quit (Ping timeout: 244 seconds)
399 2012-06-17 09:23:36 graingert has quit (Ping timeout: 246 seconds)
400 2012-06-17 09:26:27 talpan has joined
401 2012-06-17 09:27:27 sirk390 has joined
402 2012-06-17 09:31:44 <sturles> Just got a message from a friend. He couldn't remember the passphrase on his bitcoin wallet containing a small fortune of coins. No way. He tried everything.
403 2012-06-17 09:32:18 <gmaxwell> sturles: This is not an outcome we didn't anticipate.
404 2012-06-17 09:32:18 Turingi has joined
405 2012-06-17 09:32:30 <sturles> Then he tried a Windows system restore, or something like that (I'm not a Windows user) to a point before he encrypted his wallet.
406 2012-06-17 09:32:34 <sturles> Voilla.
407 2012-06-17 09:32:47 <sturles> Wallet unencrypted.
408 2012-06-17 09:33:00 <sturles> A small security risk there..
409 2012-06-17 09:33:16 <gmaxwell> ha.
410 2012-06-17 09:34:47 btctest has joined
411 2012-06-17 09:35:47 TheSeven has joined
412 2012-06-17 09:36:12 <btctest> I'm new.... At the first start of bitcoin client how many hours is needed to become sync? It's very hot in here, if it takes 8h maybe it would be better to wait tommorow morning and start earlier. Can I shut down computer while sync and will client continue from where it stopped with sync?
413 2012-06-17 09:36:13 <vragnaroda> sturles: While that is a security risk, I don't think it should be within the scope of Bitcoin development to address that issue.
414 2012-06-17 09:38:17 sirk390 has quit (Quit: Leaving.)
415 2012-06-17 09:40:07 sirk390 has joined
416 2012-06-17 09:40:47 <gmaxwell> btctest: yes it will continue. How long it takes depends on your system. A few hours is normal.
417 2012-06-17 09:41:09 <btctest> gmaxwell: thank you
418 2012-06-17 09:41:35 btctest has left ()
419 2012-06-17 09:42:11 <sturles> vragnaroda: I agree, but it should probably be mentioned somewhere.
420 2012-06-17 09:46:19 <vragnaroda> Yeah.
421 2012-06-17 09:48:17 <gmaxwell> sturles: go edit https://en.bitcoin.it/wiki/Securing_your_wallet
422 2012-06-17 09:49:03 T_X has quit (Ping timeout: 248 seconds)
423 2012-06-17 09:49:04 _flow_ has quit (Ping timeout: 248 seconds)
424 2012-06-17 09:49:37 <sturles> Better if some Windows user who know the relevant terms and how to avoid the problem does it, I think.
425 2012-06-17 09:50:11 <doublec> that's approximately zero people in this channel probably
426 2012-06-17 09:50:35 <sturles> Good point.
427 2012-06-17 09:54:59 <gmaxwell> sturles: a "note: this is an issue" is better than nothing.
428 2012-06-17 09:56:01 <gmaxwell> My Fedora 16/17 OpenSSL RPMs have been updated to the latest updates: https://people.xiph.org/~greg/openssl/
429 2012-06-17 09:58:14 <Graet> <doublec> that's approximately zero people in this channel probably << i hate o/sist assumptions, really sint neccessary, every user has free choice of operating system they are comfortable with :) i use both windows and linux, they both work well in differebnt situations /applications
430 2012-06-17 09:59:26 <Graet> and like it or not the bulk of pcs still run win, and the bulk of ppl we will be attracting to bitcoin also use win. its just how computers and p[eopel are :)
431 2012-06-17 09:59:47 <[Tycho]> "still" ? It's not like this going to change :)
432 2012-06-17 10:00:19 <Graet> :)
433 2012-06-17 10:04:16 <doublec> I'm not o/sist. Based on requests in this channel in the past for knowledgable windows developers I assume there aren't any here and was informing the requestor that there probably isn't anyone knowledgable enough to make the wiki edit
434 2012-06-17 10:04:26 <doublec> knowing that, they could then make an appropriate edit themselves
435 2012-06-17 10:05:13 Z0rZ0rZ0r has joined
436 2012-06-17 10:14:57 <_Fireball> I'm not o/sist either, but I do build my own version of bitcoind in Windows using MSVC. So I could help if needed.
437 2012-06-17 10:17:07 <Graet> doublec, fair enough, but surely it doent take a windows developer to edit the wiki to say system restore is a security issue (tho many ppl wopuld call it a feature) :)
438 2012-06-17 10:18:23 <Graet> and since about winXP its one of the 1st things i turn off on win machines :D
439 2012-06-17 10:27:51 TD has joined
440 2012-06-17 10:28:25 spq has quit (Ping timeout: 244 seconds)
441 2012-06-17 10:30:02 <gmaxwell> hm. Does bitcoind not respond to SIGHUP anymore?
442 2012-06-17 10:30:28 Z0rZ0rZ0r has quit (Ping timeout: 252 seconds)
443 2012-06-17 10:30:48 Z0rZ0rZ0r has joined
444 2012-06-17 10:34:35 <sipa> gmaxwell: did it ever?
445 2012-06-17 10:35:31 <sipa> there was something about reopening the log file, but i can't remember if it was merged
446 2012-06-17 10:36:32 <gmaxwell> sipa: kill -HUP shuts down 0.6.2 nodes here, and this is 'fixed' in git master nodes.
447 2012-06-17 10:37:36 _flow_ has joined
448 2012-06-17 10:38:48 T_X has joined
449 2012-06-17 10:38:48 T_X has quit (Changing host)
450 2012-06-17 10:38:48 T_X has joined
451 2012-06-17 10:43:21 da2ce7 has quit (Ping timeout: 260 seconds)
452 2012-06-17 10:48:40 <sipa> gmaxwell: a maybe that patch changed the semantics of HUP from shutdown to reopen log
453 2012-06-17 10:59:43 noagendamarket has joined
454 2012-06-17 11:03:00 jurov is now known as away!aktooj@84.245.71.31|jurov
455 2012-06-17 11:06:06 SteveBell has joined
456 2012-06-17 11:07:42 <SteveBell> hey guys. I see URI is being worked on. but still several problems on several platforms, right? wish you all the best in implementing this. basically a no-brainer which will lead to a much better adaptation of bitcoin
457 2012-06-17 11:08:09 <SteveBell> this is for win: https://github.com/bitcoin/bitcoin/pull/1437
458 2012-06-17 11:08:15 <SteveBell> is mac also coming?
459 2012-06-17 11:15:04 Clipse has quit (Ping timeout: 245 seconds)
460 2012-06-17 11:19:08 mmoya has joined
461 2012-06-17 11:23:18 SteveBell has quit (Ping timeout: 246 seconds)
462 2012-06-17 11:24:48 smtmnyz has quit (Ping timeout: 245 seconds)
463 2012-06-17 11:43:22 jurov is now known as jurov|away
464 2012-06-17 11:50:54 SteveBel_ has joined
465 2012-06-17 11:51:48 graingert1 has quit (Read error: Connection reset by peer)
466 2012-06-17 11:52:40 da2ce7 has joined
467 2012-06-17 11:56:54 <zebedee_> Sorry I missed it. "The orphan issue" that luke-jr brought up. Anyone have a link?
468 2012-06-17 11:59:25 <Graet> https://bitcointalk.org/index.php?topic=23768.msg968819#msg968819 zebedee_
469 2012-06-17 12:01:33 Clipse has joined
470 2012-06-17 12:06:11 graingert has joined
471 2012-06-17 12:08:53 <zebedee_> Graet, thx!
472 2012-06-17 12:09:19 spq has joined
473 2012-06-17 12:10:39 <zebedee_> I'm not clear on why SD is causing orphans.
474 2012-06-17 12:11:25 <[Tycho]> We don't know for sure if it does.
475 2012-06-17 12:11:36 <[Tycho]> But there are chances that this is possible.
476 2012-06-17 12:11:56 <zebedee_> I see.
477 2012-06-17 12:12:00 fpgaminer has left ()
478 2012-06-17 12:12:02 <sipa> zebedee_: SD -> more transactions -> larger blocks -> slower propagation -> more network delay -> more stale blocks
479 2012-06-17 12:12:22 <zebedee_> Right.
480 2012-06-17 12:13:52 twssbot has joined
481 2012-06-17 12:15:26 twssbot has quit (Remote host closed the connection)
482 2012-06-17 12:18:35 <MysteryBanshee> sipa: pm :)
483 2012-06-17 12:20:40 vigilyn has quit (Read error: Connection reset by peer)
484 2012-06-17 12:28:49 Z0rZ0rZ0r has quit (Quit: Leaving)
485 2012-06-17 12:30:40 luke-jr has joined
486 2012-06-17 12:31:17 rdponticelli has joined
487 2012-06-17 12:33:38 ovidiusoft has quit (Ping timeout: 240 seconds)
488 2012-06-17 12:35:12 <da2ce7> sipa: have no 'fixed size limit' however calculate the 'size' of the last 100 blocks, if the size is is more than x mb, start rejecting blocks that are larger x/100.
489 2012-06-17 12:35:29 <da2ce7> let the miner decide what x is.
490 2012-06-17 12:38:56 <gmaxwell> This is not a good idea.
491 2012-06-17 12:41:36 <da2ce7> maybe de-priotize blocks under that are larger than x. and still reject blocks as current rules also.
492 2012-06-17 12:41:47 <da2ce7> *that are larger than x
493 2012-06-17 12:44:25 <xorgate> maybe there should be tx-neutrality
494 2012-06-17 12:45:56 <[Tycho]> Why should anyone reject valid blocks ?
495 2012-06-17 12:46:13 <gmaxwell> They shouldn't. da2ce7 isn't making a lot of sense here.
496 2012-06-17 12:46:15 <Graet> yes
497 2012-06-17 12:46:58 <luke-jr> da2ce7: wtf?
498 2012-06-17 12:47:28 <luke-jr> blocks larger than x are already being de-prioritized; that's what the problem is
499 2012-06-17 12:48:31 <da2ce7> what is the problem with that... if I make a block that is very large, woudn't it be logical not to want to extend it.?
500 2012-06-17 12:49:05 <gmaxwell> da2ce7: they're de-prioritized because they take longer to send and validate. So they're less likely to win in a race.
501 2012-06-17 12:49:30 <gmaxwell> though I'm a bit skeptical that this is the cause of the orphans lukes had, simply because races are not that common.
502 2012-06-17 12:50:29 <Graet> yes, and why i'm le4ss concewrned, but still would like to improve the longpoll performance :)
503 2012-06-17 12:50:43 <luke-jr> gmaxwell: it's easy to verify there was a race
504 2012-06-17 12:50:59 <luke-jr> gmaxwell: races are more common, when every block takes a long time to propagate
505 2012-06-17 12:51:18 <gmaxwell> luke-jr: how long do you think big ones take to propagate to the major miners. give me a time.
506 2012-06-17 12:51:25 <luke-jr> gmaxwell: minutes
507 2012-06-17 12:53:19 <Graet> up to 4minuites from my observartion of ozcoin blocks
508 2012-06-17 12:53:24 <gmaxwell> okay, so 9.5% of blocks should be found 60 seconds or less from the prior one, for example. Do you think you can really explain two runs of three orphans that way?
509 2012-06-17 12:53:35 <gmaxwell> Graet: observation how?
510 2012-06-17 12:53:53 <luke-jr> gmaxwell: yes? Eligius finds fewer than 10% of blocks these days I think :p
511 2012-06-17 12:54:12 <Graet> frok time i see it in ecoinpool co9nsole till block explorer and blockchian info first show it
512 2012-06-17 12:54:15 <gmaxwell> luke-jr: ... yes but you don't find a particular 10%, you find a random 10%.
513 2012-06-17 12:54:24 <da2ce7> I guess that the rare large block isn't causing the chain to grow so quickly... it is the average block size. Maybe a sliding average would have a better way to some squash on the huge numbers of transactions being accepted, than just limtiing the size of indervidual block.
514 2012-06-17 12:54:28 <luke-jr> gmaxwell: 9.5% is just with 1 minute
515 2012-06-17 12:54:48 <gmaxwell> luke-jr: it's 18.1% for two minutes.
516 2012-06-17 12:54:51 <luke-jr> da2ce7: I don't think anyone here is worried about blockchain growth right now.
517 2012-06-17 12:54:57 <gmaxwell> da2ce7: none of us know what you're talking about.
518 2012-06-17 12:55:06 <Graet> all of these ideas just seem to be ways to extend the waiting txn que da2ce7 :)
519 2012-06-17 12:55:30 <Graet> one of my concerns is the growing que as pools limit the txns in thier blocks
520 2012-06-17 12:55:59 <Graet> seems some of the ip miners are picking up the slack tho
521 2012-06-17 12:56:14 <luke-jr> gmaxwell: I'd say 7% is a high estimate for Eligius' size
522 2012-06-17 12:56:18 <gmaxwell> luke-jr: and still I don't think that losing 18.1% explains those orphan runs.
523 2012-06-17 12:56:37 <gmaxwell> luke-jr: Thats totally irrelevant. You don't selectively mine only the fast blocks. Jesus.
524 2012-06-17 12:56:40 <da2ce7> [Bitcoin-development] Near-term scalability... I took some of this decussion to be the blockchain size.
525 2012-06-17 12:56:42 <luke-jr> random 7%, with ~25% of racesâ¦
526 2012-06-17 12:58:02 <gmaxwell> luke-jr: it doesn't matter how many blocks you solve. 18.1% of whatever it is will be within two minutes of the prior block. And 18.1% of the subsiquent blocks will come within two minutes after yours.
527 2012-06-17 12:58:11 <luke-jr> I wish there was an easy way to view the blocks that orphaned ours
528 2012-06-17 12:58:25 <Graet> in waht way?
529 2012-06-17 12:58:56 <luke-jr> Graet: there's no (easy) way to even find out what the block hash is that was orphaned :/
530 2012-06-17 12:59:10 <gmaxwell> the chance of .181^3 = 0.005% and you're sayin you had two of these runs, and that assumes you'll always lose a race. It just isn't likely.
531 2012-06-17 12:59:22 <gmaxwell> luke-jr: the orphan view on blockchain.info does that.
532 2012-06-17 12:59:24 <luke-jr> gmaxwell: then explain it
533 2012-06-17 12:59:34 <luke-jr> gmaxwell: the orphan view on blockchain.info ignores a lot of orphans
534 2012-06-17 12:59:40 <luke-jr> including all 6 of the ones in question
535 2012-06-17 12:59:54 <gmaxwell> Right, because they didn't get realyed to it I assume.
536 2012-06-17 13:00:00 <luke-jr> probably
537 2012-06-17 13:00:01 <gmaxwell> My own nodes heard none of those six, fwiw.
538 2012-06-17 13:00:06 <Graet> http://blockchain.info/orphaned-blocks not trying to rub it in, but ozcoin orphaned you before, is there anything i can do to help you look at the block?
539 2012-06-17 13:00:19 <gmaxwell> and they peer with you, which means they were dead by the time they got to me.
540 2012-06-17 13:00:27 <luke-jr> Graet: well, I was interested to see if Deepbit has recently
541 2012-06-17 13:00:34 <luke-jr> I suspect not, since I had them as direct peers
542 2012-06-17 13:00:37 <gmaxwell> (heard meaning I can't get block them, so I never accepted them)
543 2012-06-17 13:00:38 <Graet> we did the last
544 2012-06-17 13:00:56 <Graet> 522txn to 32
545 2012-06-17 13:01:34 <luke-jr> gmaxwell: yes, one of them didn't even get to our hub-relay node
546 2012-06-17 13:01:54 <luke-jr> gmaxwell: the work-maker node literally received the competing block right after it found the block
547 2012-06-17 13:02:07 <gmaxwell> luke-jr: p2pool has had high orphans for the last month (and before too perhaps). Including blocks that were quite small. I don't know the cause. I don't doubt that size contributes something to it. But I don't think it explains it.
548 2012-06-17 13:02:23 <gmaxwell> One thing that was clearly happening in p2pool is that the miners were working on old chains.
549 2012-06-17 13:02:48 <luke-jr> gmaxwell: just glancing at blockchain.info's orphan log, what it does show seems to have a clear bias toward the smaller blocks
550 2012-06-17 13:03:22 <gmaxwell> e.g. block X happens and the miners are still on X-1 for two minutes because it took X a long time to get well propagated and accepted. But that isn't something you can fix by shrinking your own blocks.
551 2012-06-17 13:03:58 <gmaxwell> And it's obvious why your parent being slow to accept would be _worse_ so long as you're a minority of hashpower the parent changing is much more common their your own solutions.
552 2012-06-17 13:04:16 <gmaxwell> E.g. losing a minute every block is much worse than losing a minute only on the ones you find.
553 2012-06-17 13:04:22 <luke-jr> yes, others' blocks have an impact too
554 2012-06-17 13:06:07 <gmaxwell> my mining nodes directly peer with every major pool I could identify, and are running on 3.6ghz sandybridges .. out of tmpfs... and I'm still seeing long p2pool skip runs.
555 2012-06-17 13:06:38 <sipa> i suppose you could send out the inv for a received block right after the initial check (before connecting it)
556 2012-06-17 13:06:57 <sipa> if it turns out to be invalid, stop answering to getdata requests for it
557 2012-06-17 13:07:00 <[Tycho]> gmaxwell is mining solo ?
558 2012-06-17 13:07:37 <gmaxwell> [Tycho]: P2pool, which is like solo but with decenteralized payout pooling.
559 2012-06-17 13:07:58 <[Tycho]> Why are mining in p2pool ?
560 2012-06-17 13:08:55 <gmaxwell> Because I support the concept and want it to be successful.
561 2012-06-17 13:09:40 <[Tycho]> luke-jr: you were orphaned by Deepbit ?
562 2012-06-17 13:09:42 <Graet> most devs appear to be against monolithic pools and support p2pool [Tycho] :)
563 2012-06-17 13:10:05 <[Tycho]> Graet: yes, I just was expecting him to mine for profit :)
564 2012-06-17 13:10:11 <Graet> :)
565 2012-06-17 13:10:32 <luke-jr> [Tycho]: I suspect not.
566 2012-06-17 13:10:49 <gmaxwell> [Tycho]: I'm net positive on p2pool in any case, due to some 'quirks' in how it works.
567 2012-06-17 13:10:52 <luke-jr> Graet: p2pool is just another pool
568 2012-06-17 13:11:28 <gmaxwell> luke-jr: You ever considered a job as a republican spokesman? You've got the spin doctoring down pat. :)
569 2012-06-17 13:12:42 <luke-jr> gmaxwell: more like p2pool has strong marketting
570 2012-06-17 13:12:46 <gmaxwell> (Having a fast well maintained p2pool node with lots of hash power gives you an unfair sharechain advantage, my efficiency on p2pool is currently 110%. So p2pool's bad "luck" hasn't really cost me anything)
571 2012-06-17 13:15:01 vigilyn has joined
572 2012-06-17 13:16:08 <Eliel> well, mining is becoming more and more of an experts only thing with the increasing hardware requirements
573 2012-06-17 13:16:24 <luke-jr> anyhow, I'm kicking myself atm because I was so sure I had a solution to this mess when I was waking up this morning
574 2012-06-17 13:16:30 <luke-jr> but I was still half-asleep so I forgot it
575 2012-06-17 13:17:27 <luke-jr> (which also means there's a good chance the solution didn't solve anything either :P)
576 2012-06-17 13:17:52 <gmaxwell> hah. I hate that.
577 2012-06-17 13:18:11 <gmaxwell> "I know, all i have to do is convert it to spatula!" "wait. That makes no sense. Crap."
578 2012-06-17 13:18:17 <luke-jr> LOL
579 2012-06-17 13:18:43 copumpkin has joined
580 2012-06-17 13:19:04 <Graet> rofl gmaxwell ++++ luke missed his calling - spinmdoctor it should have been :D
581 2012-06-17 13:19:30 eoss has quit (Ping timeout: 246 seconds)
582 2012-06-17 13:19:43 <gmaxwell> sipa: if we relay early we risk getting DoS blocked.
583 2012-06-17 13:19:52 <gmaxwell> sipa: luke was complaining about that last night.
584 2012-06-17 13:20:55 <gmaxwell> I feel more neutral about getting rid of that now than I did last night... though it would still be a vulnerability for low difficulty blocks.
585 2012-06-17 13:21:12 <luke-jr> gmaxwell: what low difficulty blocks?
586 2012-06-17 13:21:23 <gmaxwell> Perhaps only skip the DoS if the invalid block had a difficulty over 100k or something.
587 2012-06-17 13:21:39 <gmaxwell> luke-jr: e.g. I flood you with low difficulty invalid blocks.
588 2012-06-17 13:21:44 <luke-jr> don't we reject stupidly low difficulty blocks already?
589 2012-06-17 13:22:38 <gmaxwell> It's not possible to reject them in all contexts without it being a rule change.
590 2012-06-17 13:22:49 <gmaxwell> Not sure about here. Too sleepy.
591 2012-06-17 13:23:07 <luke-jr> gmaxwell: well, I thought Gavin added code to reject ones that couldn't possibly meet the realistic difficulty changes
592 2012-06-17 13:23:21 <luke-jr> so it adjusts when diff changes
593 2012-06-17 13:24:22 <luke-jr> this would be a breaking change, but⦠what if block validity didn't depend on the transactions in it?
594 2012-06-17 13:24:59 <gmaxwell> luke-jr: e.g. the difficulty could be back to 1 log4(diff) blocks after the highest checkpoint.
595 2012-06-17 13:25:43 <gmaxwell> luke-jr: then you'd make SPV nodes insecure.
596 2012-06-17 13:26:40 Diapolo has joined
597 2012-06-17 13:26:41 <gmaxwell> e.g. I mine some wacked block that pays you a billion bitcoin from nowhere in particular. And the network extends it.. and your SPV node shows you the payment because it doesn't know better.
598 2012-06-17 13:27:15 <luke-jr> okâ¦
599 2012-06-17 13:28:05 <luke-jr> I'm tired still. I'll go back to bed and try to remember my nonsense.
600 2012-06-17 13:28:09 <luke-jr> >_<
601 2012-06-17 13:28:35 <sipa> wait... i never argued for extending potentially invalid blocks
602 2012-06-17 13:28:39 <sipa> only relaying
603 2012-06-17 13:28:57 <gmaxwell> I was responding to luke.
604 2012-06-17 13:29:07 copumpkin has quit (Quit: Computer has gone to sleep.)
605 2012-06-17 13:29:10 <gmaxwell> 06:20 < luke-jr> this would be a breaking change, but⦠what if block validity didn't depend on the transactions in it?
606 2012-06-17 13:29:39 <sipa> ow, ok
607 2012-06-17 13:29:42 <gmaxwell> sipa: as far as what you suggested, that would be okay, but right now we DoS() on them, so someone could make all nodes hang up on each other by creating a couple invalid blocks.
608 2012-06-17 13:30:11 <luke-jr> gmaxwell: quick hack: protocol version 60002 = I don't DoS for skipping transaction checks
609 2012-06-17 13:30:14 <sipa> a PoW check is easy, and i'd only relay after the PoW check
610 2012-06-17 13:30:45 <gmaxwell> Sure. But I spend 50 BTC (or N*that, I don't remember how much DoS it adds)... to isolate 100% of nodes
611 2012-06-17 13:31:04 <gmaxwell> so at least the DoS would need to be removed if we were to do that.
612 2012-06-17 13:31:18 <luke-jr> actually, using protocol version would be annoying for backports
613 2012-06-17 13:31:55 <gmaxwell> Last night I was opposed to removing the DoS for it. But now I'm not, at least not if the difficulty is high enough.
614 2012-06-17 13:32:01 random_cat__ has quit (Ping timeout: 276 seconds)
615 2012-06-17 13:32:10 <sipa> gmaxwell: oh sure, somehow i missed the () after DoS
616 2012-06-17 13:33:48 <luke-jr> gmaxwell: right now, a sig failure is 100% DoS()
617 2012-06-17 13:33:54 random_cat__ has joined
618 2012-06-17 13:34:04 <Eliel> I've been playing with an idea of having a bitcoin-like system with a hierarchy of blockchains. That is, it'd have n fast chains (maybe block per minute), then n/2 chains (block per 2 minutes) and then n/4 chains and so on until they're all combined. each chain higher difficulty than the one before and "combining" the smaller chains.
619 2012-06-17 13:34:36 <gmaxwell> Eliel: you could call it ... p2pool!
620 2012-06-17 13:34:50 <luke-jr> gmaxwell: maybe use a new protocol message ("einv"?) to announce the block prematurely? old clients ignore it
621 2012-06-17 13:35:25 <Eliel> the fast bottom level chains would each have their own set of coins unable to do cross chain transfers. For those, you'd need one of the bigger and slower chains.
622 2012-06-17 13:35:55 erle- has quit (Quit: erle-)
623 2012-06-17 13:36:14 <gmaxwell> luke-jr: TD wanted something like this too.
624 2012-06-17 13:36:25 <Eliel> just an idea so far. Not even close to being implementable :)
625 2012-06-17 13:36:36 <gmaxwell> (he wanted spv nodes to relay stuff but not get blocked)
626 2012-06-17 13:37:56 <gmaxwell> luke-jr: you could also ignore einv from nodes that have been giving you bad einv data, so a dos attack just means blocking the fast path.
627 2012-06-17 13:38:31 <luke-jr> gmaxwell: too easy to abuse
628 2012-06-17 13:39:00 <gmaxwell> hm? why?
629 2012-06-17 13:39:07 <gmaxwell> I didn't mean mixing einv types.
630 2012-06-17 13:39:14 <luke-jr> 50 BTC to harm the network's block propagation
631 2012-06-17 13:39:45 <luke-jr> since you check after relaying yourself, everyone will blcok everyone for bad einv data
632 2012-06-17 13:39:48 dw has quit (Ping timeout: 246 seconds)
633 2012-06-17 13:40:44 copumpkin has joined
634 2012-06-17 13:40:49 <gmaxwell> meh. I suppose. I was more thinking about transactions which don't have the upfront barrier.
635 2012-06-17 13:41:07 <gmaxwell> (which is IIRC what TD wanted it for)
636 2012-06-17 13:41:35 <gmaxwell> where full nodes wouldn't ever einv transactions.
637 2012-06-17 13:41:44 <Eliel> I think this sort of system could improve bitcoin's scalability. Each fast chain would only be a subset of the whole economy but all the coins would still be transferable across chains too so the values between the chains would not vary.
638 2012-06-17 13:42:39 <Eliel> and the end result could still be one big blockchain (it could be implemented so that the small chains can be forgotten each time the chain above them in the hierarchy gets a block.
639 2012-06-17 13:42:43 <gmaxwell> Eliel: I think you should work out a complete description, I've discarded ideas that sounded like that in the past as non-viable/pointless.
640 2012-06-17 13:43:12 <gmaxwell> (well, not totally pointless, they can be used for fast low confidence confirmations)
641 2012-06-17 13:43:20 <gmaxwell> (and I've proposed doing that with p2pool)
642 2012-06-17 13:43:46 <gribble> New news from bitcoinrss: Diapolo opened pull request 1475 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1475>
643 2012-06-17 13:44:43 <Eliel> gmaxwell: I started thinking about this when I realized that transactions themselves are actually chains too and we use the blockchain in bitcoin to tie it all up so they sync with each other.
644 2012-06-17 13:45:01 <luke-jr> fast relaying brings the risks down significantly, but it doesn't eliminate them entirely
645 2012-06-17 13:45:49 <james_> hmm question, if someone gets access to a wallet.dat with a passphrase set, couldnt they simply offline-crack the passphrase?
646 2012-06-17 13:45:53 <luke-jr> gmaxwell: what if we accept the block header alone independent from the transactions in it?
647 2012-06-17 13:45:54 <gmaxwell> luke-jr: further improvements would be taking the txn out of blocks. e.g. getbareblock
648 2012-06-17 13:46:08 <Eliel> luke-jr: wouldn't it be better to modify the protocol so the transaction data is propagated all the time and when blocks appear, you only need to transfer mostly headers + coinbase + maybe some nonstandard transactions?
649 2012-06-17 13:46:17 <luke-jr> gmaxwell: and if the transactions are invalid for any reason, the entire block contents get ignored and only the header sticks around for blocks built on top
650 2012-06-17 13:46:47 <luke-jr> Eliel: that punishes miners who accept non-standard transactions
651 2012-06-17 13:46:59 <gmaxwell> james_: Sure. Users should use a good passphrase. The KDF is salted and uses a large number of sha512 iterations. (minimum 25,000, but >100k is typical).
652 2012-06-17 13:47:27 <gmaxwell> luke-jr: that breaks SPV, its what I said above.
653 2012-06-17 13:47:30 <luke-jr> gmaxwell: in other words, prevblockhash is allowed to be a header that wasn't a valid block; and then we just relay the header
654 2012-06-17 13:47:42 <luke-jr> gmaxwell: not really; we'd never relay the new block if it was invalid
655 2012-06-17 13:47:51 <luke-jr> just the header, as a valid prevblock candidate
656 2012-06-17 13:48:03 <Eliel> luke-jr: even so, it's a waste of bandwidth to transfer transactions the recipient already has
657 2012-06-17 13:48:18 <gmaxwell> luke-jr: but the SPV node got it early and doesn't know better.. and sees it extended.
658 2012-06-17 13:48:25 <luke-jr> Eliel: yes, that's a protocol optimization, but not one that helps much with this IMO
659 2012-06-17 13:48:25 <gmaxwell> (or the badguy relays it)
660 2012-06-17 13:48:54 <Eliel> luke-jr: reason being?
661 2012-06-17 13:49:36 <luke-jr> Eliel: because it punishes miners who accept non-standard transactions, and doesn't eliminate the risks altogether
662 2012-06-17 13:49:54 <gmaxwell> it's not important to eliminate them completely.
663 2012-06-17 13:50:07 <gmaxwell> you can't. more data takes more time to transmit, end of story.
664 2012-06-17 13:50:13 <Eliel> james_: of course you can try to offline crack the passphrase.
665 2012-06-17 13:50:14 <luke-jr> gmaxwell: it is important
666 2012-06-17 13:50:19 <Eliel> james_: hence, choose a good passphrase.
667 2012-06-17 13:50:25 <james_> heh
668 2012-06-17 13:50:31 <james_> yes of course
669 2012-06-17 13:50:52 <gmaxwell> luke-jr: it's not important if the loss is cents per day or whatever.
670 2012-06-17 13:50:55 <luke-jr> gmaxwell: if it cannot be eliminated, then no-fee txns are dead
671 2012-06-17 13:51:11 <gmaxwell> blah blah blah.
672 2012-06-17 13:51:22 <james_> so hypothetical situation: wallet with passphrase gets stolen... eventually the passphrase gets cracked... presumably enough time has passed that there's other trnascations in that wallet and any new transactions the hacker makes would be invalidated?
673 2012-06-17 13:51:34 Zarutian has joined
674 2012-06-17 13:52:24 <Eliel> james_: if you suspect the wallet's been stolen, even if it's been encrypted, move the coins ASAP.
675 2012-06-17 13:52:53 <gmaxwell> james_: the wallet contains your private keys, your cracker can learn about the txn from the network. It's possible that you're no longer using any of the private keys in the copy he stole but you wouldn't want to count on that.
676 2012-06-17 13:53:27 <james_> cool thx, ill move the coins and start a new wallet.dat -- all hypothetical of course :P lol
677 2012-06-17 13:53:48 <Eliel> james_: keep the old one in case you get transfer to those addresses
678 2012-06-17 13:53:55 <Eliel> but don't actively use it
679 2012-06-17 13:54:41 <gmaxwell> luke-jr: prevalidation relaying should cut it down to almost nothing, not sending redundant txn data and validation caching would largely remove the rest. The pressure to deny free txn to drive up txn fees is already greater than whatever residual bias against more txn should exist. Besides, does anyone accept free non-standard txn?
680 2012-06-17 13:55:48 <luke-jr> maybe.
681 2012-06-17 13:56:07 <Eliel> luke-jr: with the optimization I proposed, you could still have free transactions if they're standard.
682 2012-06-17 13:56:08 <luke-jr> I suppose it's cheap to try it and see.
683 2012-06-17 13:56:34 <luke-jr> gmaxwell: bitcoind rules won't relay non-standard transactions with ANY fee
684 2012-06-17 13:56:47 dw has joined
685 2012-06-17 13:56:49 <gmaxwell> luke-jr: yes, I know this.
686 2012-06-17 13:57:06 <gmaxwell> luke-jr: but those fees paid you for the slight additional liability of including them. Cope.
687 2012-06-17 13:57:10 <luke-jr> meh
688 2012-06-17 13:57:23 <luke-jr> any suggestions on calculating the cost? :P
689 2012-06-17 13:57:41 p0s has joined
690 2012-06-17 13:57:52 vigilyn has left ("Leaving")
691 2012-06-17 13:58:13 vigilyn has joined
692 2012-06-17 13:58:28 <Eliel> luke-jr: would need some research on how much delay each transaction adds.
693 2012-06-17 13:58:35 <gmaxwell> sure, its however long it would take a single peer (remember not checking on relay) to get that txn and get a response... should be on the order of milliseconds of loss... and not even that because it could be done in parallel with other stuff.
694 2012-06-17 13:59:11 <luke-jr> Eliel: if we're adding a round-trip for every txn the node is missing, quite a bit
695 2012-06-17 13:59:47 <gmaxwell> luke-jr: they could, and should, all be in parallel.
696 2012-06-17 13:59:49 <Eliel> yes, better favor connections to nodes that have good round trip
697 2012-06-17 14:00:00 <luke-jr> right now, it's a single A->B with everything
698 2012-06-17 14:00:28 <luke-jr> A->B--(need these txids!)->A->B is double the hops
699 2012-06-17 14:00:37 <luke-jr> actually triple
700 2012-06-17 14:01:09 <gmaxwell> right now you inv then get (1 rtt) then the data sends (many many rtt)
701 2012-06-17 14:02:08 <gmaxwell> then you'd have inv then get then much less data sends (hopefully just one to a few rtt), then one more rtt to get the missing txn.
702 2012-06-17 14:02:12 imsaguy has quit (Ping timeout: 246 seconds)
703 2012-06-17 14:03:16 * luke-jr ponders tracking which txns our node was missing, and automatically sending those after the block without waiting for requests
704 2012-06-17 14:04:04 imsaguy has joined
705 2012-06-17 14:04:47 <gmaxwell> if they're dropping them for being non-standard that may not help.
706 2012-06-17 14:05:09 <gmaxwell> In any case I think we're deep into overoptimization and we don't have any data to suggest that there are non-trivial problems in this area.
707 2012-06-17 14:05:19 <gmaxwell> Losing a few hunded ms on propagation is no big deal.
708 2012-06-17 14:05:47 <Eliel> maybe change the isstandard such that they won't get relayed or mined but will be accepted into the mempool?
709 2012-06-17 14:06:37 <gmaxwell> Eliel: don't defeat isstandard plz.
710 2012-06-17 14:06:56 <Eliel> ok, please fill me in on the purpose.
711 2012-06-17 14:07:14 <gmaxwell> IsStandard exists because it was proven over and over again that bitcoin's security wasn't up to snuff with respect to unusual transactions.
712 2012-06-17 14:07:41 <gmaxwell> It's important to drop them instead of being 'smart' because apparently we fail at smart.
713 2012-06-17 14:08:33 sanchaz has joined
714 2012-06-17 14:08:34 <Eliel> ok, so it raises the bar for an exploit. You need to get them into a block to make trouble.
715 2012-06-17 14:09:23 <gmaxwell> show me a unit test that gets 100% branch coverage in all the transaction handling code and then perhaps we can just ditch IsStandard entirely or reduce it to a IsObviousBs()
716 2012-06-17 14:09:36 <nanotube> heh
717 2012-06-17 14:10:30 <Eliel> luke-jr: hey, you can get rid of it, just write some tests :)
718 2012-06-17 14:10:56 <gmaxwell> Examples of obvious BS: txn with random data stuffed on to the end (possibly by a third party), txn with a dozen pointless checksigs, etc.
719 2012-06-17 14:11:29 * TD remembes OP_CODESEPARATOR
720 2012-06-17 14:11:32 <TD> heh
721 2012-06-17 14:11:57 <gmaxwell> That really was a good design overall.. but.. oy...
722 2012-06-17 14:13:11 * sipa ponders about trying to compress blocks themselves as well
723 2012-06-17 14:13:19 <sipa> to reduce storage
724 2012-06-17 14:13:42 <Eliel> I expect you could get a lot of reduction for the 1dice transactions.
725 2012-06-17 14:13:57 <sipa> things like using 64 bytes for signatures instead of 72 DER encoding now
726 2012-06-17 14:14:18 <Eliel> I mean, no point saving one address many times.
727 2012-06-17 14:14:23 copumpkin has quit (Ping timeout: 240 seconds)
728 2012-06-17 14:14:25 <sipa> or not using 4 full bytes for version, sequence, locktime, outpos, ...
729 2012-06-17 14:17:19 graingert has quit (Remote host closed the connection)
730 2012-06-17 14:34:49 t7 has joined
731 2012-06-17 14:37:44 darkee is now known as !~darkee@gateway/tor-sasl/darkee|darkee
732 2012-06-17 14:43:06 SteveBel_ has quit (Ping timeout: 260 seconds)
733 2012-06-17 14:43:36 <Diapolo> sipa: current block-chain 1,66GB is 1,06GB when compressed via 7-Zip default settings
734 2012-06-17 14:44:17 <sipa> Diapolo: sure, but that probably uses a lot of inter-block redundancy
735 2012-06-17 14:44:30 <sipa> that's not very useful for live usage
736 2012-06-17 14:44:50 <Diapolo> just wanted to mention that number
737 2012-06-17 14:44:57 <sipa> actually, it may be
738 2012-06-17 14:45:15 graingert has joined
739 2012-06-17 14:45:24 <sipa> i didn't expect it to be that compressible, actually
740 2012-06-17 14:45:38 <Diapolo> what about a compression-algo for the network part?
741 2012-06-17 14:46:22 <sipa> that's harder as it requires a protocol change
742 2012-06-17 14:46:30 <Diapolo> sure, but possible too
743 2012-06-17 14:46:46 <sipa> though if sufficient improvement is possible, why not
744 2012-06-17 14:47:34 <Diapolo> would be interesting how much speed is lost for such solutions
745 2012-06-17 14:48:24 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
746 2012-06-17 14:50:44 bitcoiner has joined
747 2012-06-17 14:52:28 <[Tycho]> Compression is fun :)
748 2012-06-17 14:53:25 bitcoiner has quit (Client Quit)
749 2012-06-17 14:53:31 wizkid057 has quit (Read error: Operation timed out)
750 2012-06-17 14:53:42 <Diapolo> easiest way for users would be to use their FS compression in terms of pure space considerations I think
751 2012-06-17 14:54:28 wizkid057 has joined
752 2012-06-17 14:54:36 <Diapolo> I guess compression-algos could be offloaded to GPUs to a certain amount :D.
753 2012-06-17 14:57:57 <sipa> i'm more talking about more compact serializations than traditional comptession
754 2012-06-17 14:59:16 <Diapolo> there are different layers as to where you can start this IMHO, some are harder, some are easier to implement
755 2012-06-17 15:00:26 <sipa> sure
756 2012-06-17 15:00:31 <Diapolo> btw. NTFS FS compression is only able to lower 1,66GB usage to 1,58GB ... not that valuable
757 2012-06-17 15:01:41 <jgarzik> FS compression works with comparatively tiny blocks
758 2012-06-17 15:01:59 <sipa> indeed
759 2012-06-17 15:03:41 <Diapolo> Another thing in between, a balance change from immature to mature is triggered by a simple change in block-count, right?
760 2012-06-17 15:03:55 <sipa> yes
761 2012-06-17 15:04:50 <Diapolo> thanks, so my patch for that gui display thing is based on the correct assumption ^^
762 2012-06-17 15:06:04 <[Tycho]> I think the question was to use compression for faster block propagation.
763 2012-06-17 15:06:28 <sipa> nah
764 2012-06-17 15:06:49 <sipa> the problem is the fact that blocks are verified before relaying
765 2012-06-17 15:06:56 <sipa> imho
766 2012-06-17 15:07:01 <[Tycho]> May be.
767 2012-06-17 15:07:16 <sipa> well, mostly; not only of course
768 2012-06-17 15:07:18 <Diablo-D3> then why verify them
769 2012-06-17 15:07:20 <Diablo-D3> just spam them
770 2012-06-17 15:07:38 <sipa> haha :)
771 2012-06-17 15:08:15 p0s has quit (Remote host closed the connection)
772 2012-06-17 15:09:35 RainbowDashh has joined
773 2012-06-17 15:15:41 <Diapolo> luke-jr: did you take a look at the sign/verify GUI stuff?
774 2012-06-17 15:20:02 ah-bitcoin has left ("Verlassend")
775 2012-06-17 15:21:36 <Diapolo> Since 5 days I can't seem to get a testnet connection (testnet3) ...
776 2012-06-17 15:21:48 <Diapolo> makes things hard when testing stuff -_-
777 2012-06-17 15:25:22 <gmaxwell> Diapolo: /msg me your IP and I'll see if I've seen you connecting to me today?
778 2012-06-17 15:27:30 <xorgate> build-unix.txt tells me to "sudo apt-get install libdb4.8++-dev" but doing so says "E: Package 'libdb4.8++-dev' has no installation candidate", not overly familiar with building stuff on linux, what am i missing?
779 2012-06-17 15:27:54 <sipa> xorgate: your distribution may not have db 4.8, but you can build against a later version just fine
780 2012-06-17 15:28:13 <sipa> (though wallet files will not be backward compatible with versions that use bdb 4.8)
781 2012-06-17 15:28:59 <xorgate> sipa i'm afraid i dont know what this means for me now. i have an ubuntu 12.04 in a vm
782 2012-06-17 15:29:31 <sipa> try replacing the 4.8 by 5.1
783 2012-06-17 15:29:43 <xorgate> oki
784 2012-06-17 15:30:06 <xorgate> that seems to do the trick, thanks
785 2012-06-17 15:32:19 <gmaxwell> sipa: any idea if the v6 changes broke IRC on windows? seems that Diapolo wasn't finding any testnet peers.
786 2012-06-17 15:33:39 <gmaxwell> hm. nevermind it seems irc was connecting..... ooood
787 2012-06-17 15:34:39 maaku has joined
788 2012-06-17 15:35:00 maaku has quit (Client Quit)
789 2012-06-17 15:38:41 erle- has joined
790 2012-06-17 15:39:15 <gmaxwell> hm.
791 2012-06-17 15:39:16 <gmaxwell> IRC SENDING: NICK u1111113HK8zu
792 2012-06-17 15:39:21 <gmaxwell> seems they're all sending that.
793 2012-06-17 15:40:41 <xorgate> compiling, i get an error about libminiupnpc, the top of the makefile says "USE_UPNP:=0" , this should not include that lib (after some googling), is the colon supposed to be there?
794 2012-06-17 15:41:03 <Diapolo> xorgate: no at least not on Win
795 2012-06-17 15:41:28 <gmaxwell> xorgate: Yes if you don't have miniupnp do like make -j4 -f makefile.unix bitcoind USE_UPNP=
796 2012-06-17 15:41:29 <xorgate> Diapolo i'm trying to compile in an ubuntu vm
797 2012-06-17 15:41:46 <gmaxwell> (just USE_UPNP= at the end)
798 2012-06-17 15:41:58 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
799 2012-06-17 15:45:45 Joric has joined
800 2012-06-17 15:45:45 Joric has quit (Changing host)
801 2012-06-17 15:45:45 Joric has joined
802 2012-06-17 15:46:35 <xorgate> i think it worked
803 2012-06-17 15:47:11 datagutt has joined
804 2012-06-17 15:50:30 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
805 2012-06-17 15:58:42 <Diapolo> sipa: how can I output an CAddress as string?
806 2012-06-17 15:59:15 tsche has joined
807 2012-06-17 15:59:30 tsche has quit (Client Quit)
808 2012-06-17 16:00:34 <Diapolo> got it
809 2012-06-17 16:00:38 tsche has joined
810 2012-06-17 16:00:47 <MysteryBanshee> urgh guys
811 2012-06-17 16:01:01 <MysteryBanshee> My Bitcoin Wallet on blockchain.info is really starting to piss me off
812 2012-06-17 16:01:16 <MysteryBanshee> it wasnt enough that it caused me to waste 1 btc yesterday, now its just refusing to send any money from my wallet
813 2012-06-17 16:01:30 talpan has quit (Remote host closed the connection)
814 2012-06-17 16:01:38 <MysteryBanshee> does anyone know how to contact the developers?
815 2012-06-17 16:02:52 <gribble> New news from bitcoinrss: Bitsky opened issue 1476 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1476>
816 2012-06-17 16:04:36 maaku has joined
817 2012-06-17 16:07:58 maaku has quit (Client Quit)
818 2012-06-17 16:08:30 wizkid057 has quit (Read error: Operation timed out)
819 2012-06-17 16:09:08 wizkid057 has joined
820 2012-06-17 16:10:04 <[Tycho]> MysteryBanshee: can you just use e-mail or write PM at the forum ?
821 2012-06-17 16:10:13 <MysteryBanshee> just sent an email now
822 2012-06-17 16:10:14 <[Tycho]> Also you can post a message to their thread.
823 2012-06-17 16:10:35 <MysteryBanshee> ill wait until they reply till i go on the forums
824 2012-06-17 16:11:50 <gmaxwell> haha
825 2012-06-17 16:12:16 <[Tycho]> How did you lost that 1 BTC ?
826 2012-06-17 16:13:07 maaku has joined
827 2012-06-17 16:13:10 <Diapolo> sipa: Quick question in regards to Tor-support ... is IRC support possible when using a hidden-node? I'm asking myself if IPs that I don't want to get public are encoded into the IRC NICK there.
828 2012-06-17 16:13:13 eoss has joined
829 2012-06-17 16:13:21 eoss has quit (Changing host)
830 2012-06-17 16:13:21 eoss has joined
831 2012-06-17 16:14:24 <[Tycho]> Why do you need to use IRC then ?
832 2012-06-17 16:14:45 <Diapolo> no no ... just when someone has it enabled
833 2012-06-17 16:14:58 <Diapolo> I'm asking if that should be disabled then.
834 2012-06-17 16:15:25 <Diapolo> (IRC support when using Tor hidden nodes)
835 2012-06-17 16:20:00 <gmaxwell> sipa: https://github.com/bitcoin/bitcoin/pull/1477
836 2012-06-17 16:20:37 <gmaxwell> Diapolo: thats your irc issue.
837 2012-06-17 16:20:53 <Diapolo> wow ... that was a small bug with a big influence ^^
838 2012-06-17 16:20:58 <Diapolo> "big"
839 2012-06-17 16:21:24 <Diapolo> thanks for that quick fix, will try later :)
840 2012-06-17 16:21:37 maaku has quit (Quit: maaku)
841 2012-06-17 16:23:13 <gribble> New news from bitcoinrss: gmaxwell opened pull request 1477 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1477>
842 2012-06-17 16:23:33 <gmaxwell> as far as hidden services + irc goes.. only v4 addresses go out via IRC. If your real v4 gets leaked depends on a number of things.
843 2012-06-17 16:24:11 <gmaxwell> For HS discovery I'd like us to just have a seednodes set that goes out with bitcoin. They should be somewhat more stable than v4 seednodes because only dataloss or DOS attack forces someone to change hidden service addresses.
844 2012-06-17 16:25:58 <MysteryBanshee> [Tycho]: I put in too many digits in the BTC amount field and it wrapped around or something and sent the wrong amount
845 2012-06-17 16:26:21 <MysteryBanshee> [Tycho]: do you know if its possible to take the wallet backup from blockchain.info and use it in another online wallet?
846 2012-06-17 16:27:19 <[Tycho]> I know that blockchain.info allows exporting privkeys is standard (sipa) format.
847 2012-06-17 16:27:34 * wizkid057 yawns
848 2012-06-17 16:27:36 <wizkid057> what'd i miss?
849 2012-06-17 16:27:47 <Diapolo> gmaxwell: fix works, so ACK
850 2012-06-17 16:27:49 <MysteryBanshee> [Tycho]: so what online wallets would you recommend that can import those keys?
851 2012-06-17 16:27:49 <[Tycho]> You may send all your funds to one address and then export this privkey.
852 2012-06-17 16:28:02 <[Tycho]> I don't use any online wallets.
853 2012-06-17 16:28:13 jine has joined
854 2012-06-17 16:29:03 <[Tycho]> The only online bitcoin "banking" service that I may recommend is icbit.se, but it's not designed to work as a wallet.
855 2012-06-17 16:29:13 <Diapolo> gmaxwell: I just wanted to ensure IPv4 can't get leaked ... or at least should never be leaked for HS nodes.
856 2012-06-17 16:29:23 <Diapolo> I'm out ... bye.
857 2012-06-17 16:29:26 Diapolo has left ()
858 2012-06-17 16:30:03 <MysteryBanshee> oh
859 2012-06-17 16:32:34 <MysteryBanshee> anyone have any idea on good online wallets?
860 2012-06-17 16:32:38 <MysteryBanshee> is paytunia any good?
861 2012-06-17 16:33:02 <gmaxwell> Mtgox is the most trusted online wallet.
862 2012-06-17 16:33:13 <gmaxwell> And as far as I can tell the most competently run.
863 2012-06-17 16:33:28 <[Tycho]> Hacked not so many times.
864 2012-06-17 16:34:39 graingert has quit (Ping timeout: 245 seconds)
865 2012-06-17 16:34:41 <gmaxwell> MysteryBanshee: thoughâ why do you want an online wallet? all of them create exposures that you wouldn't have otherwise?
866 2012-06-17 16:35:03 <MysteryBanshee> its quick and easy to store small amounts and I can use it on my mobile
867 2012-06-17 16:35:19 <gmaxwell> Fair enough.
868 2012-06-17 16:35:30 <MysteryBanshee> gmaxwell: can I ask you a favor?
869 2012-06-17 16:35:47 <MysteryBanshee> or some ideas
870 2012-06-17 16:35:57 <gmaxwell> You an always ask. Though I might just point and laugh.
871 2012-06-17 16:36:05 <MysteryBanshee> im trying to send some btc to my paytunia account but it doesnt seem to allow importing sepa private keys
872 2012-06-17 16:36:09 <MysteryBanshee> what can I do ?
873 2012-06-17 16:36:37 <gmaxwell> send some btc to it instead of importing private keys?
874 2012-06-17 16:36:47 <MysteryBanshee> blockchain.info is being retarted and wont let me send anything
875 2012-06-17 16:37:23 graingert has joined
876 2012-06-17 16:37:58 MiningBuddy has quit (Remote host closed the connection)
877 2012-06-17 16:39:14 graingert has quit (Remote host closed the connection)
878 2012-06-17 16:39:49 graingert has joined
879 2012-06-17 16:41:18 <MysteryBanshee> anyone???
880 2012-06-17 16:42:02 <Diablo-D3> maybe their hot wallet went mepty
881 2012-06-17 16:42:05 <Diablo-D3> *empty
882 2012-06-17 16:42:09 <Joric> retarted lol
883 2012-06-17 16:42:30 <MysteryBanshee> lol
884 2012-06-17 16:42:45 <MysteryBanshee> i dont think it works like that
885 2012-06-17 16:42:53 <Diablo-D3> it does
886 2012-06-17 16:42:54 <MysteryBanshee> the wallets are stored client side and encrypted server side
887 2012-06-17 16:43:05 <Diablo-D3> MysteryBanshee: erm
888 2012-06-17 16:43:15 <Diablo-D3> that seems very retarded
889 2012-06-17 16:44:09 graingert has quit (Ping timeout: 240 seconds)
890 2012-06-17 16:44:31 <MysteryBanshee> ;;getrating michail1
891 2012-06-17 16:44:31 <gribble> User Michail1, rated since Thu May 31 21:15:23 2012. Cumulative rating 25, from 19 total ratings. Received ratings: 19 positive, 0 negative. Sent ratings: 17 positive, 0 negative. Details: http://bitcoin-otc.com/viewratingdetail.php?nick=Michail1 Currently authenticated from hostmask Michail1!~michail1@c-24-17-188-243.hsd1.wa.comcast.net
892 2012-06-17 16:44:43 <Joric> *wallets are stored encrypted server side and get decrypted client side
893 2012-06-17 16:46:13 <MysteryBanshee> Diablo-D3: its known as a hybrid ewallet, its designed to be secure against a potentially untrustworthy server
894 2012-06-17 16:46:29 <MysteryBanshee> the work is usually done clientside via javascript
895 2012-06-17 16:49:31 rdponticelli has quit (Ping timeout: 246 seconds)
896 2012-06-17 16:49:36 <MysteryBanshee> also... ive sent a transaction of 1 satoshi...
897 2012-06-17 16:49:58 <MysteryBanshee> e66397876b0e593b07391690dd8575dece3485f5391d3a20635b32e58b1c0951
898 2012-06-17 16:50:06 <MysteryBanshee> its been hours and it hasnt confirmed
899 2012-06-17 16:50:31 <MysteryBanshee> ive paid 0.0005 as a fee too
900 2012-06-17 16:51:52 <Diablo-D3> weird
901 2012-06-17 16:51:56 <Diablo-D3> I hope you get it figured out
902 2012-06-17 16:51:58 <Diablo-D3> Im going to bed
903 2012-06-17 16:51:59 <Diablo-D3> night all
904 2012-06-17 16:52:02 * wizkid057 blames SD
905 2012-06-17 16:53:01 <Joric> MysteryBanshee, i sent a few btc today, got first confirmation in 185 minutes
906 2012-06-17 16:53:43 <Joric> ctrl+f 1dice on http://bitcoincharts.com/bitcoin/txlist/
907 2012-06-17 16:53:46 plutonic has joined
908 2012-06-17 16:53:52 <Joric> kindof gives the overall picture
909 2012-06-17 16:54:04 <[Tycho]> 0.0005 fee may be not so effective currently due to 1dice
910 2012-06-17 16:54:15 <Joric> there's like 99% of satoshidice
911 2012-06-17 16:54:30 <[Tycho]> Try using 0.01, for example.
912 2012-06-17 16:55:13 <gmaxwell> yea, a full 100,000% fee should do it.
913 2012-06-17 16:55:20 <Joric> [Tycho], do you accept those satoshidice transactions?
914 2012-06-17 16:55:36 <[Tycho]> Joric: partially.
915 2012-06-17 16:55:49 Turingi has quit (Ping timeout: 244 seconds)
916 2012-06-17 16:56:33 <[Tycho]> But I'm planning to rise minimal 1dice fees to 0.01
917 2012-06-17 16:56:51 <Joric> i guess pools are free to reject whatever they want
918 2012-06-17 16:56:57 Diablo-D3 has quit (Ping timeout: 244 seconds)
919 2012-06-17 16:57:12 <[Tycho]> Not because I don't like 1dice, but to gave more chances to personal TXes.
920 2012-06-17 16:59:52 setkeh has quit (Ping timeout: 252 seconds)
921 2012-06-17 16:59:58 setkeh` has joined
922 2012-06-17 17:00:13 <wizkid057> [Tycho]: :)
923 2012-06-17 17:00:33 <Joric> i sent f8e0a0162f2eee7f233f1a87855d5021ec9b808f505d5ff385c2f7d56eaa6086 without being asked for a fee, took 185 minutes to get into block not sure who processed it
924 2012-06-17 17:00:58 setkeh` is now known as setkeh
925 2012-06-17 17:01:05 <Joric> frankly doesn't look like a tx-free transaction to me )
926 2012-06-17 17:01:14 <MysteryBanshee> :/
927 2012-06-17 17:01:56 <[Tycho]> Hmm, blockchain.info fails at this.
928 2012-06-17 17:02:01 <[Tycho]> http://blockchain.info/block-index/238665
929 2012-06-17 17:02:32 <MysteryBanshee> blockchain.info fails at pretty much everything
930 2012-06-17 17:02:45 <[Tycho]> Joric: why it doesn't ? Fee is 0.
931 2012-06-17 17:03:34 <Joric> [Tycho], idk it's a bunch of newly created tiny inputs and it weights 3kb
932 2012-06-17 17:04:19 <Joric> oh got it
933 2012-06-17 17:04:58 <Joric> A transaction can be sent without fees if both of these conditions are met: 1) It is smaller than 10 (SI) kilobytes (10.000 bytes). 2) All outputs are 0.01 BTC or larger.
934 2012-06-17 17:05:21 <Joric> mine has a bunch of 0.0001 inputs though
935 2012-06-17 17:06:09 <Joric> but formally i guess it is a free transaction
936 2012-06-17 17:06:18 <gmaxwell> where are you copying that from?
937 2012-06-17 17:06:29 <gmaxwell> because it's not an accurate reflection of the relaying rules.
938 2012-06-17 17:06:41 <[Tycho]> Depends on your client.
939 2012-06-17 17:06:42 <Joric> https://en.bitcoin.it/wiki/Transaction_fees
940 2012-06-17 17:07:01 smtmnyz has joined
941 2012-06-17 17:07:06 rdponticelli has joined
942 2012-06-17 17:07:19 <[Tycho]> Joric: inputs and outputs aren't the same
943 2012-06-17 17:07:30 <Joric> correct
944 2012-06-17 17:07:35 <gmaxwell> Joric: that page is widly out of date.
945 2012-06-17 17:07:46 <gmaxwell> Joric: in cryptic mishmashed ways.
946 2012-06-17 17:08:29 <gmaxwell> Joric: there are distinct rules for realying and for mining. The relaying ones are the ones that count, because there is a diversity in mining rules out there.. not meeting some particular mining rule isn't so bad so long as you get relayed.
947 2012-06-17 17:09:39 <gmaxwell> Joric: the relay rule is fee>=0.0001 or (no outputs <0.01 && priority>57600000). And thats it.
948 2012-06-17 17:10:10 <gmaxwell> A transaction can be big and have some young inputs and still have high priority, so long as at least one of the inputs is big/older.
949 2012-06-17 17:10:18 <Joric> that priority thing is not very clear
950 2012-06-17 17:10:52 <Joric> found it! priority = sum(input_value_in_base_units * input_age)/size_in_bytes
951 2012-06-17 17:11:06 <Joric> the same https://en.bitcoin.it/wiki/Transaction_fees
952 2012-06-17 17:11:17 <gmaxwell> Yes, indeed.
953 2012-06-17 17:11:26 <gmaxwell> age is the number of confirmations the input has.
954 2012-06-17 17:11:34 <gmaxwell> size is the total transaction size.
955 2012-06-17 17:11:46 <gmaxwell> the threshold is 1 BTC for 1 day, basically.
956 2012-06-17 17:12:22 <gmaxwell> So 2 BTC need about 12 hours worth of confirms, 0.5 BTC need about two days of confirms... at least when considering a single input.
957 2012-06-17 17:13:11 setkeh is now known as god
958 2012-06-17 17:13:38 god is now known as setkeh
959 2012-06-17 17:14:10 Turingi has joined
960 2012-06-17 17:14:26 setkeh is now known as god
961 2012-06-17 17:14:28 brwyatt is now known as brwyatt|Away
962 2012-06-17 17:14:36 god is now known as setkeh
963 2012-06-17 17:24:16 TD has quit (Quit: TD)
964 2012-06-17 17:24:56 hnz has quit (Ping timeout: 246 seconds)
965 2012-06-17 17:29:15 TD has joined
966 2012-06-17 17:32:59 plutonic has quit (Quit: plutonic)
967 2012-06-17 17:35:34 <luke-jr> https://github.com/luke-jr/bitcoin/commit/6607ccbb2d1a2a68f45d3fb355f18abe379a0680 <-- reviews plz
968 2012-06-17 17:41:47 <gmaxwell> luke-jr: that appears to accept diff 1 blocks with no body checking. Sounds like it would be fun flodding 100mbyte diff 1 blocks with that
969 2012-06-17 17:42:00 <luke-jr> gmaxwell: does it? O.o
970 2012-06-17 17:42:15 <luke-jr> return error("ProcessBlock() : block with too little proof-of-work");
971 2012-06-17 17:42:34 <gmaxwell> I mean accept for relay.
972 2012-06-17 17:42:43 <luke-jr> that check goes before relaying
973 2012-06-17 17:43:40 <gmaxwell> then whats this check for:
974 2012-06-17 17:43:41 <gmaxwell> + return DoS(50, error("CheckBlockHeader() : proof of work failed"));
975 2012-06-17 17:44:15 <luke-jr> checks that the hash is < the target in the heade
976 2012-06-17 17:44:17 <luke-jr> header*
977 2012-06-17 17:44:28 <gmaxwell> I guess I shouldn't just be reading the patch.
978 2012-06-17 17:44:35 <luke-jr> XD
979 2012-06-17 17:48:40 D34TH has joined
980 2012-06-17 17:48:50 <gmaxwell> So, without reading the the patched file what I think it should be checking before relaying is timestamp in allowed range (min and max), prev = current best, nbits = required difficulty exactly, header matches stated difficulty.
981 2012-06-17 17:49:13 <gmaxwell> if you relay before connecting (e.g. when you could check prev and the exact difficulty) then someone could flood blocks from old forks.
982 2012-06-17 17:49:39 minimoose has joined
983 2012-06-17 17:54:03 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
984 2012-06-17 17:56:21 <luke-jr> gmaxwell: max timestamp check is in the patch :p
985 2012-06-17 17:56:30 <luke-jr> prev = current best is the patch's condition for relaying preview at all
986 2012-06-17 17:56:46 graingert has joined
987 2012-06-17 17:56:51 <luke-jr> nbits = exact needs adding
988 2012-06-17 17:56:57 <luke-jr> min time too I guess
989 2012-06-17 17:59:58 minimoose_ has joined
990 2012-06-17 18:04:03 minimoose has quit (Ping timeout: 265 seconds)
991 2012-06-17 18:04:03 minimoose_ is now known as minimoose
992 2012-06-17 18:05:15 minimoose has quit (Quit: minimoose)
993 2012-06-17 18:05:16 wizkid057 has quit (Read error: Operation timed out)
994 2012-06-17 18:05:28 minimoose has joined
995 2012-06-17 18:06:28 wizkid057 has joined
996 2012-06-17 18:07:19 <luke-jr> https://github.com/luke-jr/bitcoin/commit/1cf8cefad7f0b4d876efe1032d0b1634c9eb8ee6 <-- new version
997 2012-06-17 18:08:19 D34TH has quit (Quit: Leaving)
998 2012-06-17 18:10:02 D34TH has joined
999 2012-06-17 18:11:48 <gmaxwell> Those new tests should probably be DoS no?
1000 2012-06-17 18:12:01 <luke-jr> true
1001 2012-06-17 18:12:50 <gmaxwell> I'm torn a bit... I'd like to keep all those old tests DoS when the difficulty is low, but I think that would make a mess of the patch.
1002 2012-06-17 18:13:00 <luke-jr> time-too-early wasn't DoS before
1003 2012-06-17 18:13:23 <luke-jr> gmaxwell: hmm
1004 2012-06-17 18:14:20 <gmaxwell> well time too early wasn't being tested there. It probably should be DoS when pblock->hashPrevBlock == pindexBest->GetBlockHash()
1005 2012-06-17 18:14:26 <gmaxwell> Becuase we can actually test it in that case.
1006 2012-06-17 18:14:59 <luke-jr> it was
1007 2012-06-17 18:15:17 <luke-jr> in AcceptBlock
1008 2012-06-17 18:15:58 <luke-jr> actually, clearing nDoS after CheckBlockBody/AcceptBlock looks easy enough - but I'm not so sure on the criteria for doing so
1009 2012-06-17 18:16:31 genjix has joined
1010 2012-06-17 18:19:55 <luke-jr> gmaxwell: what criteria do you think is safe? arbitrary difficulty level?
1011 2012-06-17 18:24:12 <gmaxwell> Thats the best I can come up with.
1012 2012-06-17 18:25:25 <gmaxwell> You can't do it based on prev because it might be orphan at the recipent. Requring the difficulty to be >100k or something is probably fine.
1013 2012-06-17 18:29:07 hnz has joined
1014 2012-06-17 18:31:48 Prattler has joined
1015 2012-06-17 18:32:14 MiningBuddy has joined
1016 2012-06-17 18:33:00 <TD> the FAQ entry on "Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin?"
1017 2012-06-17 18:33:03 <TD> doesn't actually make sense in english
1018 2012-06-17 18:33:10 <TD> i will rewrite it, also to include a reference to the ETH paper
1019 2012-06-17 18:35:56 minimoose_ has joined
1020 2012-06-17 18:37:26 minimoose_ has quit (Client Quit)
1021 2012-06-17 18:37:42 minimoose_ has joined
1022 2012-06-17 18:38:43 graingert has quit (Quit: graingert)
1023 2012-06-17 18:39:01 graingert has joined
1024 2012-06-17 18:39:24 minimoose_ has quit (Client Quit)
1025 2012-06-17 18:39:37 minimoose_ has joined
1026 2012-06-17 18:39:56 minimoose has quit (Ping timeout: 260 seconds)
1027 2012-06-17 18:39:56 minimoose_ is now known as minimoose
1028 2012-06-17 18:40:49 d4de has quit (Ping timeout: 244 seconds)
1029 2012-06-17 18:42:23 Slix` has joined
1030 2012-06-17 18:42:29 minimoose has quit (Client Quit)
1031 2012-06-17 18:45:32 osmosis has quit (Remote host closed the connection)
1032 2012-06-17 18:46:51 osmosis has joined
1033 2012-06-17 18:52:16 twmz has joined
1034 2012-06-17 18:56:41 osmosis has quit (Quit: Leaving)
1035 2012-06-17 18:57:36 <luke-jr> gmaxwell: https://github.com/luke-jr/bitcoin/commit/0ce6f590dc2b9cbb46ceecd7320220f55d814bca
1036 2012-06-17 18:58:05 <TD> what's the rationale for that?
1037 2012-06-17 18:58:19 <TD> what can you do with a preview block?
1038 2012-06-17 18:58:34 <TD> decide to build on it?
1039 2012-06-17 18:59:04 <gmaxwell> TD: pass it on to other nodes, so the whole network can decide to build on it at once.
1040 2012-06-17 18:59:30 <TD> if nodes sync their mempools at startup and blocks are distributed as header+hashes, is it nearly equivalent?
1041 2012-06-17 18:59:44 <TD> given that it amortizes sig checking cost over time
1042 2012-06-17 19:00:25 <gmaxwell> TD: assuming they have equal memory pools but they don't because of differential relaying policy, mempool ageouts, etc.
1043 2012-06-17 19:00:48 <TD> yes, the delta would not be exactly zero, but you'd just have to request the missing ones
1044 2012-06-17 19:00:55 <TD> should be faster
1045 2012-06-17 19:01:02 <gmaxwell> It's also really a zero code change.. doesn't require adding more caching infrastructure etc. The substance of the change is really just turning back some anti DOS tests.
1046 2012-06-17 19:01:03 <TD> and it reduces redundant bandwidth usage too
1047 2012-06-17 19:01:06 <luke-jr> TD: the goal is to remove the huge incentive for miners to make 1-txn blocks
1048 2012-06-17 19:01:11 osmosis has joined
1049 2012-06-17 19:01:20 <Prattler> luke-jr, without looking at the code, this sounds like it's begging to be exploited as an attack vector.
1050 2012-06-17 19:01:35 <gmaxwell> TD: though I generally agree. doing that isn't mutually exclusive with previews.
1051 2012-06-17 19:01:36 <luke-jr> Prattler: the inverse attack vector is already being exploited
1052 2012-06-17 19:01:43 <gmaxwell> Prattler: its not.
1053 2012-06-17 19:01:44 <TD> yeah, that incentive exists because of propagation time. if the vast majority of transactions in a block were seen and verified already, blocks are distributed as header+hashes, they should propagate much faster
1054 2012-06-17 19:01:58 <luke-jr> Prattler: this trades that attack vector for a much more expensive one
1055 2012-06-17 19:02:12 <Prattler> luke-jr, I know, I'm just quoting you
1056 2012-06-17 19:02:12 <TD> it also solves the issue on the Scalability wiki page whereby huge tx volumes end up requiring you to have insane upload capacities to broadcast the blocks
1057 2012-06-17 19:02:19 <TD> well. "solves" -> reduces
1058 2012-06-17 19:02:27 <luke-jr> Prattler: oh, that's p2pool-related
1059 2012-06-17 19:02:43 ThomasV has joined
1060 2012-06-17 19:02:58 <luke-jr> TD: yes, I'd like to see that implemented too - but this part was a lot easier and more important IMO
1061 2012-06-17 19:03:00 phma has joined
1062 2012-06-17 19:03:03 <TD> fair enough
1063 2012-06-17 19:03:34 <luke-jr> TD: for some background, Eligius has had 6 blocks orphaned in the past week where the competing block had about half as many txns
1064 2012-06-17 19:03:57 <TD> you think it's deliberate? or just some weird artifact of miners restarting their nodes
1065 2012-06-17 19:04:16 <gmaxwell> eligus has a more permissive than default mining policy.
1066 2012-06-17 19:04:20 <luke-jr> TD: it seems that the block propagation time is a real problem
1067 2012-06-17 19:04:28 <luke-jr> gmaxwell: not relevant here tho
1068 2012-06-17 19:04:30 * TD nods
1069 2012-06-17 19:04:36 <TD> yes, seems so, from the p2pool change
1070 2012-06-17 19:04:38 <gmaxwell> amusingly there might have been a double hit from txins being cold cache because they weren't in nodes memory pools.
1071 2012-06-17 19:04:41 <genjix> i know how to increase block propagation time
1072 2012-06-17 19:04:41 <Prattler> from my quick tests with p2pool... some 250kB blocks take more than a minute to propagate
1073 2012-06-17 19:04:49 <luke-jr> TD: other pools are seeing higher orphan and stale rates too, just not at the same extreme
1074 2012-06-17 19:04:54 <genjix> i was thinking about doing this months ago but decided it wasnt worth the investment
1075 2012-06-17 19:05:35 <genjix> someone could make and maintain a backbone for miners
1076 2012-06-17 19:05:35 datagutt has quit (Quit: kthxbai)
1077 2012-06-17 19:05:40 <genjix> sell miners access to it
1078 2012-06-17 19:05:57 <luke-jr> genjix: â¦
1079 2012-06-17 19:05:59 <Prattler> like.. centralize it? :)
1080 2012-06-17 19:06:16 <gmaxwell> genjix: you can't get miners to _voluntarily_ connect to _free_ hubs. This has been tried before.
1081 2012-06-17 19:06:17 <genjix> no a backbone for message transferrance
1082 2012-06-17 19:06:27 <genjix> i see. hah
1083 2012-06-17 19:06:40 <gmaxwell> (because better miner interconnection closes attacks where the attackers isolate miners and use them to mine forks)
1084 2012-06-17 19:06:45 <TD> software optimizations seem a better aproach for now
1085 2012-06-17 19:06:53 <TD> approach*
1086 2012-06-17 19:07:43 <gmaxwell> Unfortunately the signature cache is so low level that it doesn't appear to help all that much. :(
1087 2012-06-17 19:07:45 <genjix> fast-push for miners?
1088 2012-06-17 19:08:07 <MC1984> gonna paste some lines
1089 2012-06-17 19:08:25 <MC1984> MC1984> so is it me or is the high orphan rate "problem" merely a side effect of the abberation of mining pools?
1090 2012-06-17 19:08:26 <TD> it doesn't help?
1091 2012-06-17 19:08:35 <luke-jr> MC1984: no, it'd be worse without pools
1092 2012-06-17 19:08:37 <TD> i'd think it'd at least spread cpu load
1093 2012-06-17 19:08:57 <MC1984> <MC1984> as in, its only a problem because there are "nodes" with like >20% of the network, which is the abberation
1094 2012-06-17 19:08:57 <MC1984> <MC1984> and then, its only a problem for those nodes
1095 2012-06-17 19:08:57 <MC1984> <MC1984> IE the pool ops
1096 2012-06-17 19:08:57 <MC1984> <MC1984> so
1097 2012-06-17 19:08:57 <MC1984> <MC1984> isnt this just another good reason why pools are bad
1098 2012-06-17 19:09:03 <MC1984> MC1984> yeah i know
1099 2012-06-17 19:09:03 <MC1984> <MC1984> and its only noticable to them because theyre losing so many blocks because they have so much hashpower
1100 2012-06-17 19:09:04 <MC1984> <MC1984> which is the abberation
1101 2012-06-17 19:09:06 <MC1984> <MC1984> would this be a problem, on everage, if everyone was on p2pool
1102 2012-06-17 19:09:07 <gmaxwell> TD: it only saves the ECDSA validations... which aren't free.. but it looks like the worst case delays are the IO.
1103 2012-06-17 19:09:15 <luke-jr> MC1984: ok, that much is asking for a kick
1104 2012-06-17 19:09:16 <TD> right
1105 2012-06-17 19:09:34 <MC1984> its like 50 words
1106 2012-06-17 19:09:44 <MC1984> anyway, am i wrong or what
1107 2012-06-17 19:09:52 <luke-jr> MC1984: yes, it'd be worse without pools
1108 2012-06-17 19:10:00 <luke-jr> MC1984: also, p2pool is just another pool
1109 2012-06-17 19:10:03 <MC1984> yes but would that be a problem
1110 2012-06-17 19:10:21 <luke-jr> MC1984: of course?
1111 2012-06-17 19:10:25 <MC1984> pools only notice because they have so many potential bloks to lose
1112 2012-06-17 19:10:29 <genjix> is the high orphan rate a result of the increase in mining power due to fees from satoshidice?
1113 2012-06-17 19:10:35 <gmaxwell> MC1984: you can be pretty sure that some solo miners in a world of solo miners would also optimize this stuff.
1114 2012-06-17 19:10:43 <luke-jr> genjix: it's an increase in transactions
1115 2012-06-17 19:10:43 <gmaxwell> genjix: @#$@#$@#(
1116 2012-06-17 19:10:44 <MC1984> no doubt
1117 2012-06-17 19:11:06 <luke-jr> genjix: and the slowness of blocks traversing the network
1118 2012-06-17 19:11:10 d4de has joined
1119 2012-06-17 19:11:10 d4de has quit (Changing host)
1120 2012-06-17 19:11:10 d4de has joined
1121 2012-06-17 19:11:11 <TD> gmaxwell: the IO is pretty well optimized by now, right?
1122 2012-06-17 19:11:12 <genjix> that's cool
1123 2012-06-17 19:11:12 <gmaxwell> genjix: there is no increase in mining power. And the fees only about to 0.02 BTC/block, so I wouldn't expect one. (Also, most pools don't pass the fees onto their miners in any case)
1124 2012-06-17 19:11:14 <luke-jr> due to verfying those transactions before passing them of
1125 2012-06-17 19:11:15 <luke-jr> on*
1126 2012-06-17 19:11:36 <genjix> hmm ok
1127 2012-06-17 19:11:38 <sturles> luke-jr: What is your pool's priority when findind a block? Getting it out to all connected nodes, or pushing out new work to clients? It would probably be a good idea to hold back new work until the new block is out of the house.
1128 2012-06-17 19:11:47 <genjix> oh right validation + propagation
1129 2012-06-17 19:11:50 <luke-jr> sturles: both?
1130 2012-06-17 19:11:53 <MC1984> it seems like the people making by far the loudest noise about it are pool ops
1131 2012-06-17 19:12:05 <luke-jr> MC1984: because we see it first
1132 2012-06-17 19:12:13 <gmaxwell> TD: IO is mostly the black box of bdb. We think it's well optimized then someone finds another switch that makes it 4x faster.
1133 2012-06-17 19:12:21 <luke-jr> MC1984: notably, the first pool to make noise about it was p2pool
1134 2012-06-17 19:12:49 <genjix> maybe write a custom db system
1135 2012-06-17 19:12:49 <TD> gmaxwell: i wonder if LevelDB would work better. for these kinds of workloads it might well do.
1136 2012-06-17 19:12:55 <genjix> bitcoin doesnt even use bdb fully
1137 2012-06-17 19:13:08 <genjix> only for indexing really
1138 2012-06-17 19:13:09 <sturles> If distribution of the new block is delayed by getting new work out to workers, your priority is wrong. Better having a few stales than an orphaned block.
1139 2012-06-17 19:13:18 <genjix> txs are stored in pagefiles
1140 2012-06-17 19:13:23 <luke-jr> I hate bdb as much as the next guy, but⦠please don't pull a KDE and expect desktop users to run MySQL >_<
1141 2012-06-17 19:13:35 <TD> leveldb is a c++ lib you can just link in
1142 2012-06-17 19:13:42 <TD> it's a refactored out part of BigTable
1143 2012-06-17 19:13:42 <gmaxwell> genjix: jeff has a patch to change it to use bdb correctlyâ multiple tables and such. Unfortunately it tanks performance.
1144 2012-06-17 19:13:48 <luke-jr> sturles: why do you assume it's either/or?
1145 2012-06-17 19:13:49 <genjix> yes ofc
1146 2012-06-17 19:13:54 <genjix> i had this with libbitcoin
1147 2012-06-17 19:13:55 <TD> which is pretty fast
1148 2012-06-17 19:14:00 <genjix> ACID on is slooow
1149 2012-06-17 19:14:03 <genjix> ACID off is reasonable
1150 2012-06-17 19:14:13 <genjix> (using bdb)
1151 2012-06-17 19:14:20 <sturles> luke-jr: Becuase bandwidht and CPU are limited resources.
1152 2012-06-17 19:14:21 <TD> the way we use BDB is basically a key/value store, right? is there anything else on top?
1153 2012-06-17 19:14:33 <luke-jr> sturles: the problem with the block propagation is across the network, not the originating node
1154 2012-06-17 19:14:34 <genjix> TD: well kinda. some things uses BDB, others not
1155 2012-06-17 19:14:38 <gmaxwell> TD: we need transactions. for reorgs.
1156 2012-06-17 19:14:41 <genjix> for instance txs are serialised straight to disk
1157 2012-06-17 19:14:46 <genjix> but indexed using bdb
1158 2012-06-17 19:14:48 <MC1984> no one runs p2pool
1159 2012-06-17 19:14:49 <TD> yes
1160 2012-06-17 19:14:52 <genjix> which stored their position in the pagefile
1161 2012-06-17 19:14:54 <MC1984> so who/how did they make a noise
1162 2012-06-17 19:14:56 <TD> so, leveldb supports (database) transactions
1163 2012-06-17 19:15:02 <luke-jr> MC1984: forrestv runs p2pool
1164 2012-06-17 19:15:04 <TD> http://code.google.com/p/leveldb/
1165 2012-06-17 19:15:14 <gmaxwell> MC1984: same way bitcoin users make noise.
1166 2012-06-17 19:15:31 <MC1984> he codes it
1167 2012-06-17 19:15:35 <luke-jr> MC1984: same thing
1168 2012-06-17 19:15:35 <MC1984> he does not run it
1169 2012-06-17 19:15:36 <MC1984> right
1170 2012-06-17 19:15:40 <luke-jr> MC1984: yes he does run it :p
1171 2012-06-17 19:15:55 <Ukto> luke-jr: though it was 7 or 7+ blocks orphaned now?
1172 2012-06-17 19:16:10 <gmaxwell> TD: might be an interesting excerise. Things like sipa's txout db are probably more important first.
1173 2012-06-17 19:16:14 <luke-jr> Ukto: the last one doesn't seem related
1174 2012-06-17 19:16:19 <TD> yeah
1175 2012-06-17 19:16:27 <TD> i might have a play with it this week
1176 2012-06-17 19:16:32 <MC1984> if he runs it then what is the point of p2pool
1177 2012-06-17 19:16:39 <luke-jr> MC1984: the same as the point of any pool
1178 2012-06-17 19:16:43 <gmaxwell> MC1984: don't listen to luke's spin.
1179 2012-06-17 19:16:49 <luke-jr> gmaxwell: no u
1180 2012-06-17 19:16:55 <gmaxwell> MC1984: forrestv runs p2pool like gavin runs bitcoin.
1181 2012-06-17 19:17:08 <MC1984> thats what i mean
1182 2012-06-17 19:17:13 <MC1984> he codes it
1183 2012-06-17 19:17:39 <gmaxwell> MC1984: there are even forks of p2pool on old versions that find blocks from time to time... off isolated from the mothership.
1184 2012-06-17 19:17:48 <MC1984> good
1185 2012-06-17 19:18:08 <MC1984> so anyway, is this dice thing a problem for the average p2pool user
1186 2012-06-17 19:18:13 <MC1984> noticable problem
1187 2012-06-17 19:18:17 <luke-jr> gmaxwell: and someone could fork Eligius the same
1188 2012-06-17 19:18:29 <luke-jr> p2pool is just lacking in automatic updates in that sense
1189 2012-06-17 19:18:41 <gmaxwell> MC1984: well _something_ has been resulting in about 10% of p2pools blocks being orphaned. Though it's probably many factors.
1190 2012-06-17 19:18:47 <luke-jr> MC1984: it's not really a Dice thing.
1191 2012-06-17 19:18:47 toffoo has quit ()
1192 2012-06-17 19:18:54 <MC1984> ok
1193 2012-06-17 19:19:07 <MC1984> so again, its only the centralised pool ops that have a huge problem with it
1194 2012-06-17 19:19:12 rdponticelli has quit (Ping timeout: 252 seconds)
1195 2012-06-17 19:19:15 <luke-jr> MC1984: it affects all miners the same.
1196 2012-06-17 19:19:15 <gmaxwell> huh?
1197 2012-06-17 19:19:36 <gmaxwell> p2pool users have been spazzing out about the orphaning all month.
1198 2012-06-17 19:19:49 <MC1984> it affects are spread out amongst all miners so as to be probably not noticable
1199 2012-06-17 19:19:55 <MC1984> except if youre running a pool
1200 2012-06-17 19:20:10 <luke-jr> â¦
1201 2012-06-17 19:20:13 <gmaxwell> People absolutely have noticed it.
1202 2012-06-17 19:20:16 <luke-jr> pools spread the affects out among miners too
1203 2012-06-17 19:20:18 <MC1984> so im thinking the "problem" is a side effect of the abberation of entralised mining pools
1204 2012-06-17 19:20:23 <luke-jr> other pools*
1205 2012-06-17 19:20:38 <gmaxwell> MC1984: then explain why p2pool users have been up in arms all month?
1206 2012-06-17 19:21:10 <MC1984> you said only the dev raised it?
1207 2012-06-17 19:21:14 <MC1984> or luke said
1208 2012-06-17 19:21:25 <luke-jr> MC1984: it's mostly been the users I think
1209 2012-06-17 19:21:26 <Prattler> the problem is that it takes more than a minute for a huge block to propagate.
1210 2012-06-17 19:21:46 <MC1984> how big ar ethe blocks now
1211 2012-06-17 19:21:48 <luke-jr> forrestv recently added a workaround to p2pool, but I think it asks for trouble
1212 2012-06-17 19:21:50 <gmaxwell> MC1984: he didn't say that, â and yea, it's not been forrest raising that.
1213 2012-06-17 19:25:40 <MC1984> okw ell my point is
1214 2012-06-17 19:25:46 <MC1984> if everyone was a solominer
1215 2012-06-17 19:25:59 <MC1984> and the effects of this dice thing where spread out like that
1216 2012-06-17 19:26:09 <MC1984> would it be a problem
1217 2012-06-17 19:26:23 <luke-jr> yes
1218 2012-06-17 19:26:25 <MC1984> because orphans have always happened, they were viewed as the cost of doing business right
1219 2012-06-17 19:26:29 <gmaxwell> MC1984: if it costs you 10% of your income it costs you 10% of your income, it doesn't matter how its cut up.
1220 2012-06-17 19:26:37 <luke-jr> MC1984: no
1221 2012-06-17 19:26:53 <luke-jr> orphans were viewed as a necessary evil that nobody had any control over
1222 2012-06-17 19:27:04 <gmaxwell> sure but orphans are normally <1%. And when I solomined you can bet I investigated every orphan I got.
1223 2012-06-17 19:27:09 <MC1984> =cost of doing business
1224 2012-06-17 19:27:09 <luke-jr> now we know that fewer transactions reduces your chance of an orphan
1225 2012-06-17 19:27:28 <gmaxwell> ^ maybe.
1226 2012-06-17 19:27:29 <luke-jr> so it's more profitable to hurt Bitcoin by not processing any transactions
1227 2012-06-17 19:28:32 Aetitiae_ has joined
1228 2012-06-17 19:28:37 Joric_ has joined
1229 2012-06-17 19:28:37 Joric_ has quit (Changing host)
1230 2012-06-17 19:28:37 Joric_ has joined
1231 2012-06-17 19:28:43 Joric has quit (Ping timeout: 240 seconds)
1232 2012-06-17 19:29:24 Joric_ is now known as Joric
1233 2012-06-17 19:29:49 imsaguy has quit (Ping timeout: 246 seconds)
1234 2012-06-17 19:30:04 imsaguy has joined
1235 2012-06-17 19:31:11 <MC1984> gmaxwell you dont run a pool do you?
1236 2012-06-17 19:32:43 <gmaxwell> MC1984: No.
1237 2012-06-17 19:33:09 <gmaxwell> You'll have to try a bit harder to find an ad hominem.
1238 2012-06-17 19:33:36 <MC1984> what?
1239 2012-06-17 19:33:37 <genjix> gmaxwell: why are you so defensive/aggressive all the time?
1240 2012-06-17 19:33:40 <MC1984> geniuine question
1241 2012-06-17 19:33:45 <genjix> i'm sure he was harmlessly asking
1242 2012-06-17 19:33:51 <MC1984> i know luke runs one
1243 2012-06-17 19:34:28 <sturles> If the orphans are spread out equally, they do not cost you 10%. They make difficulty go down 10%, compensating for the loss. If there is a way to make the orphan rate go lower for yourself by behaving badly, it is a problem for Bitcoin.
1244 2012-06-17 19:34:52 <gmaxwell> sturles: Right, the advantage is the advantage.
1245 2012-06-17 19:35:19 <gmaxwell> In any case, as I argued earlier I think luke's over inflating this particular issue but it's hard to tell.
1246 2012-06-17 19:36:34 <sturles> Some of the p2pool nodes may not be well connected. If you are behind a NAT and only connected to 8 peers, you will have a higher orphan rate.
1247 2012-06-17 19:37:33 <gmaxwell> MC1984: Sorry, I've burned many an hour arguing against centralization in pools, sharing basically the kind of concer you're trying to argue here. Perhaps nothing else irritates me as much as someone arguing my own position poorly, and I thought you were looking for an excuse to dismis my position as you were dismissing Luke.
1248 2012-06-17 19:38:00 <gmaxwell> There are many reasons that centeralized pools are bad, but I don't think greedy optimization is one of them.
1249 2012-06-17 19:38:18 RazielZ has quit (Ping timeout: 265 seconds)
1250 2012-06-17 19:38:56 <gmaxwell> sturles: having large numbers of connections is not by itself productive.. you'll burn more time relaying that way and be less responsive.
1251 2012-06-17 19:39:05 <MC1984> dont worry, i generally know your position and its cool
1252 2012-06-17 19:39:29 <MC1984> luke might be biased though as a pool op, and has been known to spin things before lol
1253 2012-06-17 19:40:12 <gmaxwell> sturles: before cut down my local node policy I was seeing multiminute delay, and my nodes peer with eligius, btcguild, deepbit, emc, my public node etc. and I have a seperate public node with typically a few hundred connections.
1254 2012-06-17 19:40:29 <MC1984> i think maybe sturles might have my answer, the orphans are not a problem if truely decentralised, but the incentive to not include txns are a problem for sure
1255 2012-06-17 19:40:46 <gmaxwell> And my nodes run out of tmpfs on 3.6ghz sandy bridges, there is basically no faster node.
1256 2012-06-17 19:40:55 Raziel_ has joined
1257 2012-06-17 19:41:13 <gmaxwell> MC1984: thats two ways of representing the same statement. Orphans are never a problem if everyone has them equally.
1258 2012-06-17 19:41:25 <gmaxwell> And yea, luke is a spin master.
1259 2012-06-17 19:42:16 <MC1984> yes the orphans would be fair if everyone got equally screwed
1260 2012-06-17 19:42:20 <MC1984> lol that sounds bad
1261 2012-06-17 19:42:56 <MC1984> what preventing that is a) pools and b) the incentive to not include dice txn which is the real flaw prob?
1262 2012-06-17 19:43:55 <gmaxwell> I don't see why you keep invoking pools.
1263 2012-06-17 19:44:35 <MC1984> just as the most pertinent example of centralised mining
1264 2012-06-17 19:44:41 <gmaxwell> (Or really dice, â that site is problematic because it crowds out the transactions of regular useâ but thats a seperate issue)
1265 2012-06-17 19:45:18 <MC1984> and dice as the most pertinent example of a causal factor of huge blocks
1266 2012-06-17 19:45:20 <gmaxwell> MC1984: But centeralized mining isn't relevant to this. The incentives with respect to this are the same no matter how mining is arranged.
1267 2012-06-17 19:45:43 <gmaxwell> (okay, I'll grant you the dice)
1268 2012-06-17 19:45:56 <MC1984> yes thats a real flaw
1269 2012-06-17 19:46:37 <MC1984> but maybe it wouldnt be (so much of) a problem without centralised mining
1270 2012-06-17 19:46:49 <MC1984> but the incentive to not mine txn, as a separeate issue, is a problem
1271 2012-06-17 19:47:19 <gmaxwell> I don't see why you keep saying that centeralized mining matters. I don't see it.
1272 2012-06-17 19:47:20 <[Tycho]> You are thinking about centralized mining too much :)
1273 2012-06-17 19:47:55 <gmaxwell> And when you've got _me_ agreeing with [Tycho] that you are thinking about centralized mining too much: thats good evidence you actually are! :)
1274 2012-06-17 19:47:58 <[Tycho]> Without pools our total hashrate would be many times lower.
1275 2012-06-17 19:48:36 <MC1984> still, i would rather pools not be nessecary
1276 2012-06-17 19:49:02 <gmaxwell> well payment pooling doesn't require centralized mining, but whatever. It's not here nor there.
1277 2012-06-17 19:49:32 <[Tycho]> I can't even imagine someone mining with normal rig of few GPUs now, not even knowing if he will find any block this month at all or not.
1278 2012-06-17 19:49:48 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
1279 2012-06-17 19:50:40 <MC1984> be that as it may
1280 2012-06-17 19:50:56 <MC1984> i wont lie [Tycho] i hope p2pool destroys deepbit
1281 2012-06-17 19:51:03 <MC1984> and thats not out of malice to you
1282 2012-06-17 19:51:09 <MC1984> all of them
1283 2012-06-17 19:51:09 <[Tycho]> How can it ?
1284 2012-06-17 19:51:09 Joric has quit (Ping timeout: 240 seconds)
1285 2012-06-17 19:51:31 <MC1984> i dont know
1286 2012-06-17 19:51:36 <MC1984> growing
1287 2012-06-17 19:51:47 <[Tycho]> I think that most miners do this for profit, so large-scale miners won't use p2pool.
1288 2012-06-17 19:52:00 <gmaxwell> [Tycho]: er. thats the second time you've said something like that.
1289 2012-06-17 19:52:09 <[Tycho]> gmaxwell: yes.
1290 2012-06-17 19:52:17 <gmaxwell> I'm now wondering if there is some amusing misconception you have about p2pool?
1291 2012-06-17 19:52:18 <[Tycho]> Well, may be except you.
1292 2012-06-17 19:52:23 <[Tycho]> May be.
1293 2012-06-17 19:52:48 <[Tycho]> At least someone in p2pool will always get lower-than-expected rewards.
1294 2012-06-17 19:52:53 <gmaxwell> I mean, there are something like 500GH/s on p2pool, including some fairly large miners.
1295 2012-06-17 19:53:22 <[Tycho]> May be they are doing this because they support decentralization ?
1296 2012-06-17 19:54:00 Raziel_ has quit (Quit: Leaving)
1297 2012-06-17 19:54:08 <gmaxwell> There isn't any fundimental reason for large discrepancies in returnsâ It's not PPS, so you have varience, but compared to 10% off the top PPS there is room for varience instability.
1298 2012-06-17 19:54:23 RazielZ has joined
1299 2012-06-17 19:54:23 <gmaxwell> variance*
1300 2012-06-17 19:54:26 <[Tycho]> http://i.imgur.com/Bx5Fx.png
1301 2012-06-17 19:54:44 <[Tycho]> Who pays for this "lack of luck" ?
1302 2012-06-17 19:55:18 <gmaxwell> yes, indeed. And this wasn't true in the past, something is borked. We think it's fixed now but it'll be a bit before we know for sure.
1303 2012-06-17 19:55:56 <[Tycho]> We'll see.
1304 2012-06-17 19:57:04 Joric has joined
1305 2012-06-17 19:57:04 Joric has quit (Changing host)
1306 2012-06-17 19:57:04 Joric has joined
1307 2012-06-17 19:57:13 <MC1984> i never thought id see a chart with luck on the y axis
1308 2012-06-17 19:57:24 <[Tycho]> Why not ?
1309 2012-06-17 19:57:37 <[Tycho]> Luck is frequently on y-axis.
1310 2012-06-17 19:57:46 <MC1984> its just funny
1311 2012-06-17 19:58:03 <[Tycho]> So you can literally see it low :)
1312 2012-06-17 20:01:00 rdponticelli has joined
1313 2012-06-17 20:06:19 Joric_ has joined
1314 2012-06-17 20:06:19 Joric_ has quit (Changing host)
1315 2012-06-17 20:06:19 Joric_ has joined
1316 2012-06-17 20:07:58 Joric has quit (Ping timeout: 252 seconds)
1317 2012-06-17 20:09:02 Joric has joined
1318 2012-06-17 20:09:02 Joric has quit (Changing host)
1319 2012-06-17 20:09:02 Joric has joined
1320 2012-06-17 20:10:38 c_k has quit (Quit: brb)
1321 2012-06-17 20:10:56 Joric_ has quit (Ping timeout: 260 seconds)
1322 2012-06-17 20:12:00 <TD> this database code is messed up
1323 2012-06-17 20:12:06 <TD> it sort of looks superficially object oriented
1324 2012-06-17 20:12:20 <TD> it's just not though
1325 2012-06-17 20:12:28 wizkid057 has quit (Read error: Operation timed out)
1326 2012-06-17 20:13:29 wizkid057 has joined
1327 2012-06-17 20:16:07 minimoose has joined
1328 2012-06-17 20:16:46 c_k has joined
1329 2012-06-17 20:18:38 mcorlett is now known as milton_corlettes
1330 2012-06-17 20:18:48 milton_corlettes is now known as mcorlett
1331 2012-06-17 20:22:56 <MysteryBanshee> are there any online tools that let you put messages in the blockchain?
1332 2012-06-17 20:25:10 <[Tycho]> bitcoind ?
1333 2012-06-17 20:25:46 <MysteryBanshee> i mean any web based tools
1334 2012-06-17 20:25:53 <[Tycho]> Yes.
1335 2012-06-17 20:26:04 <[Tycho]> I think so.
1336 2012-06-17 20:26:23 <[Tycho]> What kind of messages ?
1337 2012-06-17 20:37:57 <MysteryBanshee> Just a short message
1338 2012-06-17 20:38:01 <MysteryBanshee> ah nevermind
1339 2012-06-17 20:39:52 Bwild has quit (Ping timeout: 246 seconds)
1340 2012-06-17 20:46:32 <TD> gmaxwell: any idea why CTxDB is created and destroyed so often? AFAICT that doesn't provide any benefit other than forcing a db flush very frequently
1341 2012-06-17 20:47:03 dvide has quit ()
1342 2012-06-17 20:50:07 <MC1984> dont start that shit again.......
1343 2012-06-17 20:51:27 <TuxBlackEdo> MysteryBanshee, how big of a message are you talking?
1344 2012-06-17 20:54:44 Joric_ has joined
1345 2012-06-17 20:55:09 Joric has quit (Ping timeout: 240 seconds)
1346 2012-06-17 20:56:57 Diapolo has joined
1347 2012-06-17 20:57:35 <genjix> TD: yeah it's terrible lol
1348 2012-06-17 20:57:44 <genjix> i love the stack based transactions
1349 2012-06-17 20:57:58 <genjix> and the db / non-db mixing
1350 2012-06-17 20:59:19 Joric_ has quit (Ping timeout: 252 seconds)
1351 2012-06-17 21:00:10 ThomasV has quit (Ping timeout: 246 seconds)
1352 2012-06-17 21:02:02 O2made has joined
1353 2012-06-17 21:02:15 O2made has quit (Remote host closed the connection)
1354 2012-06-17 21:04:48 <jgarzik> TD: RAII
1355 2012-06-17 21:05:17 <TD> RAII makes me go raah
1356 2012-06-17 21:05:57 <TD> the problem is it assumes opening and closing a db is super cheap, but it's not, so we end up with this weird CDbEnv and global state hack
1357 2012-06-17 21:06:34 <jgarzik> TD: yep
1358 2012-06-17 21:07:04 <jgarzik> TD: (I've been in the midst of cleaning up that code, so I know how annoyingly awful it all is)
1359 2012-06-17 21:07:19 <jgarzik> TD: it's so bad, you even have code instantiating a CTxDB _inside_ a CTxDB method!
1360 2012-06-17 21:07:30 <TD> lol
1361 2012-06-17 21:07:33 Turingi has quit (Read error: Connection reset by peer)
1362 2012-06-17 21:07:34 <TD> yeah
1363 2012-06-17 21:08:22 <sipa> jgarzik: i'm working on a change that does tx validation purely using txouts stored in bdb, to support pruning
1364 2012-06-17 21:09:06 <jgarzik> sipa: yeah, I've been following the txid+txout discussion in the background. Sounds interesting
1365 2012-06-17 21:09:25 <sipa> i think there's a reasonable chance rhat it ends up speeding up validation/synching even if you don't prune at all
1366 2012-06-17 21:10:26 minimoose has quit (Ping timeout: 260 seconds)
1367 2012-06-17 21:14:15 <graingert> anyone know what this icon set is? https://s3.amazonaws.com/i.imm.io/t45v.png
1368 2012-06-17 21:14:17 <sipa> TD: CTxDB is much more a db accessor objrlect than a database handle itself; destroying a CTxDB does not close the db
1369 2012-06-17 21:14:20 <graingert> default on bitcoin
1370 2012-06-17 21:14:28 <graingert> -qt
1371 2012-06-17 21:14:30 <TD> indeed
1372 2012-06-17 21:14:33 <graingert> on ubuntu
1373 2012-06-17 21:14:41 <TD> sipa: i'm trying to bring up a leveldb based CTxDB implementation, that's why i'm asking
1374 2012-06-17 21:15:01 <TD> i'm not sure it'll make much difference on my laptop as it's ssd based, but i'm curious to see if it's faster on a hard disk
1375 2012-06-17 21:15:42 <sipa> TD: i see
1376 2012-06-17 21:17:07 <sipa> but yes indeed, it's ugly
1377 2012-06-17 21:19:47 Prattler has quit (Quit: Ex-Chat)
1378 2012-06-17 21:20:01 ovidiusoft has joined
1379 2012-06-17 21:25:20 <Diapolo> sipa: can you comment on https://github.com/bitcoin/bitcoin/pull/1475/files#L7R507 via https://github.com/Diapolo/bitcoin/blob/de85dc35a1af9a758f57b3d07db5489f89aebc1d/src/wallet.cpp#L886 vs. https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L886
1380 2012-06-17 21:29:16 <luke-jr> graingert: there's a txt in doc/
1381 2012-06-17 21:29:24 <luke-jr> graingert: they're from a KDE theme I think
1382 2012-06-17 21:30:15 <sipa> Diapolo: looks correct
1383 2012-06-17 21:31:19 dwon has joined
1384 2012-06-17 21:31:48 <Diapolo> sipa: which one would you prefer? is any of the functions better / cleaner / faster, what do you think.
1385 2012-06-17 21:33:54 <sipa> oh, i missed that you gave two links
1386 2012-06-17 21:34:14 <sipa> i think the first is cleaner, hiding the immaturity logic in the coins
1387 2012-06-17 21:35:28 <Diapolo> thanks for taking a look
1388 2012-06-17 21:37:06 <sipa> TD: does leveldb have abortable transactions?
1389 2012-06-17 21:37:18 <sipa> i read it has little transactionality
1390 2012-06-17 21:37:54 <sipa> if not, you'll need to rewrite most of the block connection mechanism, as it relies on aborting transactions
1391 2012-06-17 21:38:07 <TD> ys
1392 2012-06-17 21:38:08 <TD> yes
1393 2012-06-17 21:38:12 <TD> http://leveldb.googlecode.com/svn/trunk/doc/index.html
1394 2012-06-17 21:38:13 <sipa> ok, good
1395 2012-06-17 21:38:16 <TD> see WriteBatch
1396 2012-06-17 21:38:20 Joric has joined
1397 2012-06-17 21:39:22 <sipa> yes, i see
1398 2012-06-17 21:40:14 <sipa> can you read from the batch as well?
1399 2012-06-17 21:40:55 <sipa> i'm not entirely sure, but i think the block connection logic may rely on reading data written during its own uncommitted transaction
1400 2012-06-17 21:41:43 <TD> hmm
1401 2012-06-17 21:41:52 Slix` has quit (Remote host closed the connection)
1402 2012-06-17 21:41:54 <TD> you can iterate over the contents of the batch
1403 2012-06-17 21:42:04 <TD> doing a read won't check the batches, as far as i know
1404 2012-06-17 21:42:21 dwon has quit (Quit: Leaving)
1405 2012-06-17 21:42:28 <TD> so that might require some extra glue
1406 2012-06-17 21:42:56 <sipa> as we currently have cached prefetched inputs and a map of changed transactions, it may not be depending on such functionality anymore
1407 2012-06-17 21:43:04 <sipa> but i'd have to look
1408 2012-06-17 21:44:38 <TD> yeah, testing this might be tricky ....
1409 2012-06-17 21:48:24 PK has quit ()
1410 2012-06-17 21:49:01 Diapolo has left ()
1411 2012-06-17 21:53:41 RazielZ has quit (Quit: Leaving)
1412 2012-06-17 21:59:44 <amiller> ;;seen etotheipi
1413 2012-06-17 21:59:44 <gribble> etotheipi was last seen in #bitcoin-dev 1 year, 0 weeks, 5 days, 19 hours, 38 minutes, and 35 seconds ago: <etotheipi> should I report it in #bitcoin instead?
1414 2012-06-17 21:59:59 <amiller> eh? am i missing something..
1415 2012-06-17 21:59:59 <sipa> eh, what?
1416 2012-06-17 22:00:14 <sipa> i think the bot suffers from amnesia
1417 2012-06-17 22:00:45 <genjix> ;;seen etotheipi_
1418 2012-06-17 22:00:45 <gribble> etotheipi_ was last seen in #bitcoin-dev 2 weeks, 0 days, 21 hours, 44 minutes, and 5 seconds ago: <etotheipi_> well, it's basically the same thing for both signing and verification... just watch out for the endianness
1419 2012-06-17 22:00:45 <sipa> or its clock was/is wrong
1420 2012-06-17 22:00:52 <sipa> ah!
1421 2012-06-17 22:01:44 <TD> seems that it does indeed read whilst a db tx is pending
1422 2012-06-17 22:10:29 Pasha has joined
1423 2012-06-17 22:10:55 Cory has quit (Disconnected by services)
1424 2012-06-17 22:10:57 Pasha is now known as Cory
1425 2012-06-17 22:12:17 ovidiusoft has quit (Ping timeout: 252 seconds)
1426 2012-06-17 22:12:46 TheSeven has quit (Disconnected by services)
1427 2012-06-17 22:12:47 [7] has joined
1428 2012-06-17 22:13:12 _Fireball has quit (Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :))
1429 2012-06-17 22:17:00 hnz_ has joined
1430 2012-06-17 22:19:01 MiningBuddy- has joined
1431 2012-06-17 22:31:00 phma has quit (Remote host closed the connection)
1432 2012-06-17 22:52:05 maaku has joined
1433 2012-06-17 22:52:10 erle- has quit (Quit: erle-)
1434 2012-06-17 22:53:46 maaku has quit (Client Quit)
1435 2012-06-17 22:54:45 maaku has joined
1436 2012-06-17 22:55:55 genjix has quit (Ping timeout: 252 seconds)
1437 2012-06-17 22:59:45 <gmaxwell> #@$*(*$@ the heck, gitian builder is _still_ broken for me in lxc mode on a fresh ubuntu 12.04 install.
1438 2012-06-17 23:00:34 <sipa> /poke devrandom
1439 2012-06-17 23:02:22 knotwork_ has joined
1440 2012-06-17 23:03:42 maaku has quit (Quit: maaku)
1441 2012-06-17 23:04:19 knotwork has quit (Ping timeout: 244 seconds)
1442 2012-06-17 23:15:31 <jgarzik> wow
1443 2012-06-17 23:15:49 <jgarzik> averaged over last 24h, there has been almost 1 transaction every 2 seconds
1444 2012-06-17 23:18:22 <sipa> 40k transactions / day? :o
1445 2012-06-17 23:18:51 <gmaxwell> I wouldn't be surprised to see the rate of txn actually declining if we could exclude a couple top users from that figure.
1446 2012-06-17 23:19:23 <jgarzik> sipa: 43,588 transactions in past 24 hours
1447 2012-06-17 23:19:49 maaku has joined
1448 2012-06-17 23:23:31 <sipa> gmaxwell: one in particular?
1449 2012-06-17 23:24:11 <TD> it's alive
1450 2012-06-17 23:24:23 <[Tycho]> Transactions are fun :)
1451 2012-06-17 23:24:30 <TD> now to figure out if it's actually faster
1452 2012-06-17 23:24:34 <TD> that can wait
1453 2012-06-17 23:24:56 <gmaxwell> TD: that fast? cool!
1454 2012-06-17 23:25:10 <TD> yes. leveldb is very easy to work with. of course it's not optimized yet
1455 2012-06-17 23:25:16 <TD> it just runs and starts syncing the chain
1456 2012-06-17 23:26:00 graingert has quit (Remote host closed the connection)
1457 2012-06-17 23:26:06 <sipa> TD: -loadblock=/path/to/old/blk0001.dat is useful for benchmarking :)
1458 2012-06-17 23:26:09 <gmaxwell> another metric is storage.. bdb is somewhat inefficient.
1459 2012-06-17 23:26:18 <TD> sipa: what does that do?
1460 2012-06-17 23:26:23 <gmaxwell> Yea, loadblock is absolutely what you want to do for benchmarking.
1461 2012-06-17 23:26:39 <sipa> TD: scan for blocks in that file, and process them as if they were received from network
1462 2012-06-17 23:26:41 <gmaxwell> Otherwise you're at the whim of whatever peer you're pulling from.
1463 2012-06-17 23:26:43 <TD> cool
1464 2012-06-17 23:26:49 <TD> that does sound better indeed
1465 2012-06-17 23:26:54 <sipa> including reorganisations, if the file coins several branches
1466 2012-06-17 23:27:00 <sipa> *contains
1467 2012-06-17 23:27:14 maaku has quit (Quit: maaku)
1468 2012-06-17 23:27:58 coblee has quit (Ping timeout: 244 seconds)
1469 2012-06-17 23:28:37 <TD> 1.7G of chain
1470 2012-06-17 23:29:39 abracadabra has quit (Read error: Connection reset by peer)
1471 2012-06-17 23:30:06 maaku has joined
1472 2012-06-17 23:31:12 <sipa> TD: is that an observation, or a progress report?
1473 2012-06-17 23:31:25 <TD> that's how big my regular blk0001.dat is
1474 2012-06-17 23:31:35 <TD> i thought it was smaller, somehow
1475 2012-06-17 23:31:43 <sipa> before satoshidice, it was
1476 2012-06-17 23:31:54 <gmaxwell> It's growing fairly fast now. :(
1477 2012-06-17 23:32:22 <gmaxwell> Someone was saying earlier that at the current rate we'll do in less than two months what we'd previously done in almost four years.
1478 2012-06-17 23:32:43 <TD> re-org failed. guess there's still some bugs left to fix
1479 2012-06-17 23:33:14 <sipa> blk0001.dat files with reorgs in it are very useful testing material :)
1480 2012-06-17 23:33:31 <jgarzik> TD: I downloaded this from eu1.bitcoincharts.com around May 20th, it's full of reorgs: http://gtf.org/garzik/bitcoin/blk0001.dat.bz2
1481 2012-06-17 23:33:40 <jgarzik> 1.0G compressed
1482 2012-06-17 23:33:43 kakobrekla has joined
1483 2012-06-17 23:33:50 <kakobrekla> any advice here
1484 2012-06-17 23:33:50 <kakobrekla> EXCEPTION: 11DbException
1485 2012-06-17 23:33:50 <kakobrekla> Db::put: Not enough space
1486 2012-06-17 23:33:50 <kakobrekla> C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe in Runaway exception
1487 2012-06-17 23:33:50 <kakobrekla> EnvShutdown exception: DbEnv::close: Invalid argument (22)
1488 2012-06-17 23:33:59 <TD> thanks
1489 2012-06-17 23:34:01 <jgarzik> kakobrekla: add more disk space?
1490 2012-06-17 23:34:10 <kakobrekla> thats not the issue
1491 2012-06-17 23:34:41 genjix has joined
1492 2012-06-17 23:35:36 <sipa> seems it is
1493 2012-06-17 23:36:52 abracadab has joined
1494 2012-06-17 23:36:52 abracadab has quit (Changing host)
1495 2012-06-17 23:36:52 abracadab has joined
1496 2012-06-17 23:37:36 coblee has joined
1497 2012-06-17 23:39:51 mmoya has quit (Ping timeout: 244 seconds)
1498 2012-06-17 23:40:47 <guruvan> can you not write to the space?
1499 2012-06-17 23:42:31 OneFixt has quit (Ping timeout: 246 seconds)
1500 2012-06-17 23:42:46 OneFixt has joined
1501 2012-06-17 23:44:04 dk5 has joined
1502 2012-06-17 23:46:12 <kakobrekla> yep
1503 2012-06-17 23:46:45 <DBordello> Is there something about this transaction the mners don't like? chain
1504 2012-06-17 23:46:45 <DBordello> * abracadabra has quit (Read error: Connection reset by peer)
1505 2012-06-17 23:46:45 <DBordello> * maaku (~maaku@50-0-36-54.dsl.dynamic.sonic.net) has joined #bitcoin-dev
1506 2012-06-17 23:46:45 <DBordello> <sipa> TD: is that an observation, or a progress report?
1507 2012-06-17 23:46:45 <DBordello> <TD> that's how big my regular blk0001.dat is
1508 2012-06-17 23:46:46 <DBordello> <TD> i thought it was smaller, somehow
1509 2012-06-17 23:46:48 <DBordello> <sipa> before satoshidice, it was
1510 2012-06-17 23:47:08 <DBordello> Sorry for the spam :/
1511 2012-06-17 23:47:58 <DBordello> Is there something about this transaction that miners don't like?: http://blockchain.info/tx-index/9617208/61ffb48747ee374237219d9731e2057dac0917ce93d32a4688b003746eddc9c3
1512 2012-06-17 23:48:23 <dk5> is it safe to assume that if the number 0x02/0x03/0x04 follows a field length in a script, this is the key?
1513 2012-06-17 23:49:50 <gmaxwell> dk5: no, not at all.
1514 2012-06-17 23:50:08 <gmaxwell> And⦠The key? there could be zero to N keys.
1515 2012-06-17 23:50:15 <sipa> the script language has no data types, what is pushed are just byte sequences
1516 2012-06-17 23:50:29 <gmaxwell> DBordello: nope.
1517 2012-06-17 23:50:47 <dk5> there are a variety of script types, it seems. is there documentation on the fields as they are on the wire? there's an image on the transactions wiki, but that only covers the older ones
1518 2012-06-17 23:50:53 <DBordello> gmaxwell, okay :)
1519 2012-06-17 23:51:02 <sipa> DBordello: if you see a push of 33 bytes that starts with 0x02 or 0x03, or 65 bytes and it starts with 0x04, chances are very high (in the current chain probably always) that it is a public key
1520 2012-06-17 23:51:07 <sipa> eh, dk5: ^
1521 2012-06-17 23:51:08 <gmaxwell> dk5: script is effectively a programming language.
1522 2012-06-17 23:51:59 AntKinGTube has joined
1523 2012-06-17 23:52:17 <gmaxwell> dk5: so your question is a little bit like "if I see 'printf' in a program is the string that follows the usage instructions?", except the majority of transactions a pretty uniform.
1524 2012-06-17 23:54:13 <genjix> dk5: yeah check the template scripts in script.cpp
1525 2012-06-17 23:54:55 <genjix> there are 4 or 5 iirc
1526 2012-06-17 23:56:08 <dk5> yeah, i'm looking at it now. i was just wondering if there was an easy way to identify the public key part.
1527 2012-06-17 23:56:19 <dk5> or lack thereof
1528 2012-06-17 23:57:10 <genjix> yeah the position in the script unless the eval type
1529 2012-06-17 23:57:41 <genjix> in which case, it's sigs and pubkeys
1530 2012-06-17 23:57:44 <gmaxwell> dk5: you can match basically the entire script (except for the variable part).
1531 2012-06-17 23:57:50 <gmaxwell> Anything else would be unsafe.
1532 2012-06-17 23:59:57 <dk5> you mean match it to one of the templates in script.cpp?