1 2012-11-02 00:01:20 <MC1984> heh i like the little warning
2 2012-11-02 00:01:39 <MC1984> seems like bootstrap.dat is working in this one
3 2012-11-02 04:27:00 <jgarzik> BlueMatt: CBloomFilter imported and working... thanks for the jumpstart ;p
4 2012-11-02 06:47:59 <xenland> Where is LOCK() originally located at in the Bitcoin source code?
5 2012-11-02 07:54:56 <ThomasV> in which case does getrawtransaction return error: {"code":-5,"message":"No information available about transaction"} ?
6 2012-11-02 08:12:58 <sipa> when it does not know that transaction
7 2012-11-02 08:13:37 <sipa> in git head, that can happen if it was already completely spent
8 2012-11-02 08:21:04 <ThomasV> sipa: I am using your ultraprune branch
9 2012-11-02 08:21:08 <robbak> Is there a working testnet block explorer? blockexplorer.com/testnet hasn't had any updates for weeks.
10 2012-11-02 08:22:03 <sipa> ThomasV: my branch, or git head? it was merged and has had a lot of fixes since
11 2012-11-02 08:22:30 <ThomasV> sipa: oh ok, let me checkout head
12 2012-11-02 08:23:09 <ThomasV> sipa: so, head now uses levelDB?
13 2012-11-02 08:25:12 <sipa> yes
14 2012-11-02 08:26:06 <ThomasV> sipa: is there a way I can configure it not to prune spent transactions?
15 2012-11-02 08:26:16 <sipa> it does not prune anything
16 2012-11-02 08:26:28 <sipa> it just doesn't keep an index of every transaction around
17 2012-11-02 08:26:38 <ThomasV> so why would getrawtransaction return that error?
18 2012-11-02 08:26:59 <sipa> because it cannot find the transaction
19 2012-11-02 08:27:13 <sipa> i plan to add that as an optional index somewhere in the future, for debugging purposes
20 2012-11-02 08:27:41 <ThomasV> it cannot find it because it does not have an index for tx hashes?
21 2012-11-02 08:27:46 <sipa> indeed
22 2012-11-02 08:28:00 <ThomasV> hmm, when do you plan to add that?
23 2012-11-02 08:30:51 <ThomasV> sipa: ^
24 2012-11-02 08:37:59 <sipa> ThomasV: sorry, too many todo's right now; can't promise anything
25 2012-11-02 08:38:35 <ThomasV> sipa: if you can give me a brief description of how to do it, I can try
26 2012-11-02 08:41:50 <sipa> ThomasV: you need a database (txdb.h) to store it (or reuse ccoins, but its caching infrastructure may make it harder), add transactions to it when connecting blocks, have a method to read a transaction from a given position on disk, and add that to GetTransaction
27 2012-11-02 08:42:17 <sipa> you'll probably want something like CDiskBlockPos (though the name becomes overloaded then)
28 2012-11-02 08:51:01 <sipa> ThomasV: just a question - you need to lookup by txid - where does that txid come from?
29 2012-11-02 08:51:17 <ThomasV> what do you mean?
30 2012-11-02 08:51:30 <sipa> you want to call getrawtransaction <txid>
31 2012-11-02 08:51:35 <ThomasV> yes
32 2012-11-02 08:51:36 <sipa> where do you get that txid?
33 2012-11-02 08:51:48 <ThomasV> it can be any txid
34 2012-11-02 08:51:56 <sipa> that's not an answer :)
35 2012-11-02 08:52:24 <ThomasV> are you asking why I need it?
36 2012-11-02 08:52:30 <sipa> because if you also know what block it belongs to, there is not really a problem
37 2012-11-02 08:54:24 <sipa> anyway, have to go
38 2012-11-02 08:54:25 <ThomasV> I need that for Electrum servers. I currently know what block the tx belongs to, although it would be nice if I could do it without knowing
39 2012-11-02 08:54:49 <sipa> well, i dislike the idea of keeping ever-growing indexes in general
40 2012-11-02 08:56:00 <sipa> and i don't think bitcoin infrastructure should rely on those - especially things that are intended to be run by the public (the claim "you can run your own electrum server if you don't trust another" for example, becomes harder if the resources to do so keep growing)
41 2012-11-02 08:56:21 <sipa> you need an address-to-transaction index, even, i believe?
42 2012-11-02 08:56:36 <ThomasV> yes that too
43 2012-11-02 08:56:59 <ThomasV> I want to get rid of abe
44 2012-11-02 08:57:04 <sipa> is there any chance you can do with just one for non-spent transactions? that is enough for everyone to see their balance and create transactions, but not for seeing your history
45 2012-11-02 08:57:46 <sipa> but history is stored in wallets, or not?
46 2012-11-02 08:58:30 <ThomasV> history is stored in wallets, but it is also convenient to restore your wallet from seed
47 2012-11-02 08:59:03 <sipa> yes, the "the blockchain is your wallet" idea - it's attractive, but i don't like it because of scalability concerns
48 2012-11-02 08:59:28 <sipa> anyway, you do what you think is best for your userbase of course
49 2012-11-02 09:01:48 <ThomasV> I think we could adapt to a pruning server, if users accept that some of their transactions are not going to be recovered during a restore
50 2012-11-02 09:02:04 <ThomasV> but that's not a short term concern
51 2012-11-02 09:02:15 <ThomasV> for the moment my concern is abe's poor performance
52 2012-11-02 09:03:47 <sipa> the most interesting index imho, is a non-spent-transactions-address-to-txid, as it would allow fast sweeping of an address
53 2012-11-02 09:06:58 <ThomasV> sipa: if I know the block number and tx_id, did you say I can get the raw tx already from RPC?
54 2012-11-02 09:07:13 <ThomasV> or do I still need to read from disk?
55 2012-11-02 09:07:28 <sipa> no, but that'd be very easy to implement (it would mean reading the entire block from disk, though)
56 2012-11-02 09:07:42 <ThomasV> yes, that's what abe already does
57 2012-11-02 09:08:22 <sipa> anyway, have to go
58 2012-11-02 09:08:25 <ThomasV> maybe I'll stick with that for the moment
59 2012-11-02 09:08:30 <ThomasV> thanks, see you
60 2012-11-02 09:46:55 <robbak> ReQ - Is there a working testnet block explorer? blockexplorer.com/testnet hasn't had any updates for weeks.
61 2012-11-02 11:52:11 <gmaxwell> sipa: ThomasV will also need an address to txid index, I expect that could be changed to an address -> {height,txid} index and then he wouldnt need the txid index anymore.
62 2012-11-02 11:58:17 <sipa> gmaxwell: if he wants to send tx + merkle path for SPV, he needs the entire block the transaction is contained in anyway
63 2012-11-02 11:58:26 <sipa> so a txid -> diskpos index isn't very useful
64 2012-11-02 11:59:14 <gmaxwell> Just so.
65 2012-11-02 11:59:37 <gmaxwell> robbak: What do you need it for? You know you can do many explorer like things from bitcoin itself, right?
66 2012-11-02 12:13:03 <ThomasV> gmaxwell: what would be the benefit of having height and txid in the same index?
67 2012-11-02 12:23:48 <gmaxwell> ThomasV: because if you're only ever fetching the transaction id with the height at the same time you don't need a seperate index of txids.
68 2012-11-02 12:25:02 <ThomasV> I understand, but that does not answer my question. what do we gain from it? performance?
69 2012-11-02 12:27:37 <sipa> well, i'm worried about needing to implement 37 different indexes, because some people require whole-history ones, some need only unspent ones, some need to be address based, some need txid-based, some need to find just a txout, some need entire transactions, some need the entire block it's in, and i somehow want a minimum cover :)
70 2012-11-02 12:29:34 <ThomasV> sure, but if that's your concern, you should be sensitive to the fact that a address->{height, txid} index is much more limited in what it can do than two indexes. I would go for the more universal design
71 2012-11-02 12:30:40 <gmaxwell> ThomasV: what do we gain from it? half the disk space and still being able to do the sorts of lookups you need.
72 2012-11-02 12:31:43 <sipa> some concern is for example a txid->diskpos index has 32-byte keys, and 4-5 byte values... that is a relative waste
73 2012-11-02 12:31:48 <ThomasV> why would that be half the diskspace?
74 2012-11-02 12:32:01 <sipa> you could add for example height to the value without getting any significant relative increase of size
75 2012-11-02 12:32:28 <ThomasV> gmaxwell: you'd have redundancy in it, it would actually waste space
76 2012-11-02 12:32:31 <sipa> as a separate database for the heights would need all those 32-byte keys again, with only 3-byte values
77 2012-11-02 12:34:40 <gmaxwell> ThomasV: just because addr->txid and txid->block is two indexes with similar key sizes.
78 2012-11-02 12:36:25 <ThomasV> gmaxwell: addr->txid will have many entries with different addresses having the same txid, so for all those entries you will repeat the height
79 2012-11-02 12:37:57 <sipa> depends whether it's all-history or just unspent
80 2012-11-02 12:38:05 <ThomasV> true
81 2012-11-02 12:38:36 <gmaxwell> ThomasV: repeating the height is a very small amount of data compared to another index. (the size of an additional key is greater than the key itself)
82 2012-11-02 12:39:12 <ThomasV> gmaxwell: sure. in fact abe uses an internal id instead og the hash
83 2012-11-02 12:39:19 <ThomasV> *of*
84 2012-11-02 12:39:49 <ThomasV> but I agree that if you use the hash as key, then the key takes most of the space
85 2012-11-02 12:39:51 <gmaxwell> ThomasV: though I agree, having a txid->block index is more general. My comment was just related to what should be possible for your needs.
86 2012-11-02 12:40:58 <ThomasV> for my needs it's perfectly fine to have address-> block, txid. I was just suggesting to go for the most general design
87 2012-11-02 12:41:13 <sipa> right - if you expect many txid based indexes, you could opt for having one txid->txnumber index, and have all other indexes be txnumber based
88 2012-11-02 12:42:55 <gmaxwell> or really address-> block to be honest, since you can always just scan the block.
89 2012-11-02 12:43:11 <ThomasV> heh,I was just gonna say that :)
90 2012-11-02 12:44:04 <sipa> and if you're going to send merkle paths, you need to scan the entire block
91 2012-11-02 12:44:15 <sipa> ... unless we'd store the merkle tree for blocks
92 2012-11-02 12:44:20 <sipa> which in your case may be worth it
93 2012-11-02 12:44:49 <ThomasV> well, I think it may even be worth storing merkle paths for txids, so that you don't need to rehash them
94 2012-11-02 12:45:25 <ThomasV> for an electrum server, space is not really a concern
95 2012-11-02 12:45:26 <gmaxwell> Not useful for someone doing efficient merkle tree transmission.
96 2012-11-02 12:45:54 <gmaxwell> ThomasV: it is something of a concern if "you can run your own instead of trusting someone else" isn't to be pretext.
97 2012-11-02 12:46:01 <sipa> merkle paths will frequently be larger than the txs
98 2012-11-02 12:46:34 <sipa> you really want those deduplicated by storing the per-block tree
99 2012-11-02 12:46:40 <ThomasV> sipa: they will only frow logarithmically with block size
100 2012-11-02 12:46:51 <MC1984> good evening gentlemen
101 2012-11-02 12:46:53 <gmaxwell> assuming users aren't constantly nuking their wallets you should only read a single txn ~ once, and most never.
102 2012-11-02 12:46:54 <ThomasV> *grow*
103 2012-11-02 12:47:07 <MC1984> i mean afternoon
104 2012-11-02 12:47:13 <ThomasV> gmaxwell: true
105 2012-11-02 12:47:45 <gmaxwell> ThomasV: they're _already_ larger than the txn in many cases.
106 2012-11-02 12:48:15 <ThomasV> gmaxwell: yes, but as I said, I don't consider space storage to be a concern
107 2012-11-02 12:48:58 <ThomasV> "you can run your own" is not a pretext
108 2012-11-02 12:49:40 <ThomasV> what I mean by that is that users are not dependent from a company or single entity
109 2012-11-02 12:49:43 <gmaxwell> ThomasV: uh, so you'd be willing to make the storage 2-4x larger. So 200 GBytes/year new storage needed at full rates? Thats pretty inhibiting to running your own, i think.
110 2012-11-02 12:50:06 <gmaxwell> It also will discourage people with honest and altruistic motivations from running a server.
111 2012-11-02 12:50:50 <ThomasV> heh, I believe there will be people with commercial motivations :)
112 2012-11-02 12:51:22 <sipa> i'm sure we can right now build an electrum-like server that does what you need and has lower cpu/mem/disk requirements than a 0.7.1 full node
113 2012-11-02 12:51:30 <sipa> with enough engineering effort
114 2012-11-02 12:51:42 <gmaxwell> Hope that they're simply charging for usage rather than getting paid to block transactions and spy on their users. :(
115 2012-11-02 12:52:17 <jeremias> ThomasV: are the electrum servers making money right now?
116 2012-11-02 12:52:20 <gmaxwell> sipa: I agree.
117 2012-11-02 12:52:21 <jeremias> with fees or something?
118 2012-11-02 12:52:32 <jeremias> eg. is there a business model for running an electrum server?
119 2012-11-02 12:52:32 <ThomasV> jeremias: no, except through donations
120 2012-11-02 12:53:03 <jeremias> ok
121 2012-11-02 12:53:27 <gmaxwell> jeremias: I don't see how fees could be sticky. A electrum client could happily get free access, but send txns out via another path.
122 2012-11-02 12:53:28 <ThomasV> but it would be possible to add user authentication, and have a paying model
123 2012-11-02 12:54:01 <jeremias> gmaxwell: most people would probably pay out the fees for laziness
124 2012-11-02 12:54:13 <jeremias> not everyone optimizes their money usage to full extent
125 2012-11-02 12:54:24 <gmaxwell> jeremias: until someone forks the software and ships a nofeeclient and it becomes the most popular. ::shrugs::
126 2012-11-02 12:54:37 <jeremias> well, you are always controlling the server
127 2012-11-02 12:54:50 <jeremias> if you are not making enough money, you take the server down
128 2012-11-02 12:54:51 <gmaxwell> jeremias: Huh? That has nothing to do with it.
129 2012-11-02 12:54:54 <ThomasV> gmaxwell: I don't think it makes sense to charge fees per transaction. fees would be charged for requests to the database
130 2012-11-02 12:54:55 <gmaxwell> Well sure.
131 2012-11-02 12:54:58 <jeremias> or add authentication
132 2012-11-02 12:55:25 <ThomasV> yes, through authentication
133 2012-11-02 12:55:54 <ThomasV> but as I said, no server is doing that at the moment
134 2012-11-02 12:57:06 <ThomasV> as a user, I think I would trust more a server with paying access than an altruistic one
135 2012-11-02 12:57:25 <ThomasV> but that's a personal opinion
136 2012-11-02 12:57:26 <jeremias> same here
137 2012-11-02 12:57:46 <ThomasV> and I guess the price could be less than miners fees
138 2012-11-02 12:58:04 <gmaxwell> people don't generally reason well about that sort of thing. "I've not _heard_ of death and distruction yet from untrusted servers"
139 2012-11-02 12:58:49 <sipa> distruction? like removing stuff from a truck? </pedantry>
140 2012-11-02 12:59:16 <gavinandresen> no, that is distrucking, not distruction
141 2012-11-02 12:59:41 <ThomasV> gmaxwell: no, but since my free server has limited resources, I impose a limit on my sql requests, so clients that have vaynert-style histories will get an error if they try to use my server
142 2012-11-02 12:59:42 <gavinandresen> (not to be confused with distraction, which is when you lose your footing and fall on your ass)
143 2012-11-02 12:59:58 <gmaxwell> ahah
144 2012-11-02 13:01:15 <ThomasV> the same server could even provide a free service and a paying one, depending on usage
145 2012-11-02 13:02:42 <jeremias> or some freemium model
146 2012-11-02 13:02:54 <jeremias> but you should have a business model for developing electrum as well
147 2012-11-02 13:02:59 <jeremias> make it closed source, lol
148 2012-11-02 13:03:22 <jeremias> or make the server closed source, and the client is open
149 2012-11-02 13:03:35 <ThomasV> since pruning has the same effect, I guess that a server that prunes spent outputs could be free or cheaper than a server providing full histories
150 2012-11-02 13:03:38 <jeremias> and sell the server to those who want to make money running an electrum server
151 2012-11-02 13:04:08 <jeremias> or provide open source server which has no business model, and charge for the server which makes you money
152 2012-11-02 13:06:31 <gmaxwell> ThomasV: please don't conflate pruning with only having indexes to unspent txouts.
153 2012-11-02 13:06:55 <ThomasV> gmaxwell: indeed
154 2012-11-02 13:07:10 <gmaxwell> In the context of electrum the latter could also be the former... but generall they're not the same thing. :)
155 2012-11-02 13:07:20 <gmaxwell> yyy yyy y darnit.
156 2012-11-02 13:07:54 <sipa> actually, head right now does not even have an index to unspent txouts
157 2012-11-02 13:08:40 <ThomasV> sipa: so why does getrawtransaction fail in some cases?
158 2012-11-02 13:13:23 <sipa> ThomasV: the only thing we have is a blkid->diskpos index, and txid->utxo database; but as the utxo data contains the height, you can find which block unspent transactions are in; that's a hack really
159 2012-11-02 13:14:59 <ThomasV> ok :)
160 2012-11-02 14:13:06 <an3k> is that a bug in the bitcoin-qt client? i set "pay transaction fee" to 0.00000000 BTC and when i want to send all of my btc to an address i get a popup saying "The total exceeds your balance when the 0.0015 BTC transaction fee is included."
161 2012-11-02 14:15:27 <ThomasV> an3k: I think that bitcoin-qt does not allow you to set a zero fee
162 2012-11-02 14:15:33 <ThomasV> (not sure though)
163 2012-11-02 14:16:59 <gmaxwell> an3k: It's not a bug. Your transaction looks too much like a DOS attack by the objective criteria used by most of the network.
164 2012-11-02 14:17:29 <an3k> then the client or at least the description is wrong. it says "Optional transaction fee ..."
165 2012-11-02 14:17:31 <sipa> an3k: the setting is your voluntary fee per kilobyte; regardless, some transactions require a fee to prevent them from being considered spam by the network
166 2012-11-02 14:17:43 <gmaxwell> an3k: because of that your peers wouldn't relay or mine it unless it includes a small fee (0.0005 BTC/kb). Your node knows this, so instead of creating a transaction which will just get stuck, it lets your abort or asks you if it can add a fee.
167 2012-11-02 14:17:44 <an3k> oh, ok. thanks sipa
168 2012-11-02 14:18:14 <an3k> and gmaxwell ;)
169 2012-11-02 14:18:26 <gmaxwell> an3k: if you recently recieved coins and wait a bit you may be able to send without a fee.
170 2012-11-02 14:19:29 <gmaxwell> (a bit being about 144/input_btc_value confirmations)
171 2012-11-02 14:20:13 <gmaxwell> e.g. 1 bitcoin waits 1 day. 0.1 bitcoin waits 10 days. Keeping a standing balance in your wallet generally enables it to avoid respending recently recieved coins.
172 2012-11-02 14:25:09 <ThomasV> gmaxwell: oh I see, that's an evil plan to incentivize hoarding :)
173 2012-11-02 14:26:20 <sipa> what fee policy does electrum use?
174 2012-11-02 14:26:23 <aurigae> anybody here who can make an importable command from this line for PSQL??
175 2012-11-02 14:27:22 <aurigae> or some other useful information to get this up as PSQ table
176 2012-11-02 14:27:29 <ThomasV> sipa: the user can set whatever fee they want, but since the tx is forwarded to a bitcoind, it may be rejected
177 2012-11-02 14:27:38 <aurigae> PSQL*
178 2012-11-02 14:28:39 <gmaxwell> ThomasV: nah, it's just an unfortunate compromise ... about the only thing we can use to distinguish a dos attack from normal usage is that dos attacks tend to rapidly recirculate coins. So basically we use coin immobility as priority, since immobility is something attackers lack for sure.
179 2012-11-02 14:29:06 <TD> unfortunate indeed
180 2012-11-02 14:29:10 <ThomasV> gmaxwell: sure, I was just kidding
181 2012-11-02 14:30:43 <gmaxwell> TD: ::shrugs:: absent it, one dweeb running while true ; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.01 ; done makes free transactions useless and adds tons of bloat to the chain, network traffic, etc.
182 2012-11-02 14:30:57 <gmaxwell> Better alternatives welcome!
183 2012-11-02 14:30:59 <TD> yeah. i still see DoS as a prioritization problem
184 2012-11-02 14:31:13 <TD> that is, you have fixed CPU and block capacity, now order transactions by size, fee, coin age, etc
185 2012-11-02 14:31:21 <TD> throw out any that don't fit into the available capacity
186 2012-11-02 14:31:32 <TD> so as the network grows and becomes more powerful the thresholds go down automatically
187 2012-11-02 14:32:20 <gmaxwell> TD: you can only do that sort after already consuming the bandwidth. This would also maximally spend our 'startup capital' by causing the network to have maximum load right away.
188 2012-11-02 14:32:53 <TD> anyone can send you tx messages that you have to download anyway, so bandwidth is already a resource easily consumed by DoS attackers
189 2012-11-02 14:32:57 <TD> (or indeed block messages)
190 2012-11-02 14:33:15 <gmaxwell> TD: thats O(1) for the attacker. He has to spend one unit of bandwidth for one unit consumed.
191 2012-11-02 14:33:16 <TD> well, it'd cause the network to have max load during DoS attacks. but if the attack doesn't achieve denial, then the attackers should eventually get bored and go away
192 2012-11-02 14:33:27 <gmaxwell> A relayed transaction has a factor of tens of thousand gain.
193 2012-11-02 14:33:45 <gmaxwell> TD: why would they get bored it's free and a one liner shell script.
194 2012-11-02 14:34:29 <TD> they just do, trust me. dealing with various kinds of attack (dos and spam) is my job. if the attack has no effect then it goes away. i've never seen an attack that just pointlessly wastes the attackers resources for no outcome
195 2012-11-02 14:34:34 <gmaxwell> And, it would achieve denial fine??? it would make sure bitcoin transactions were ~never free.
196 2012-11-02 14:34:52 <TD> nope, the dos txns would get sorted lower than the regular free transactions because of input age
197 2012-11-02 14:34:54 <TD> same as today
198 2012-11-02 14:35:03 <TD> it's not a big change from what we do, just minus the arbitrary hard-coded magic numbers
199 2012-11-02 14:35:23 <TD> needs node operators to set some basic config params, but they already are requesting them anyway (like bandwidth caps)
200 2012-11-02 14:35:28 <gmaxwell> TD: I'll personally attack it then. Argument settled.
201 2012-11-02 14:35:35 <gmaxwell> :P
202 2012-11-02 14:35:50 <TD> well, you'll get old and die eventually :)
203 2012-11-02 14:35:59 <gmaxwell> TD: says you! :P
204 2012-11-02 14:36:01 <TD> hah
205 2012-11-02 14:36:57 <aurigae> i hae formulated my question here again, may somebody got the time and knowledge to hel out^^ https://bitcointalk.org/index.php?topic=122075.msg1313122#msg1313122
206 2012-11-02 14:37:41 <gmaxwell> td: your work attacks still aren't things that give the attacker potentially factors of tens of thousands amplification, or result in eternal storage.
207 2012-11-02 14:38:11 <gmaxwell> TD: if everything got realyed we would expect an ultra low transaction 'anonymous' file transfer tool to show up pretty much right away.
208 2012-11-02 14:39:15 <gmaxwell> But you're right, regardless of the threshold we should facilitate the prioritization stuff more.
209 2012-11-02 15:17:11 <jgarzik> ohhh
210 2012-11-02 15:17:20 <jgarzik> have we invented a bitcoin-funded transit network?
211 2012-11-02 16:26:17 <Matt_von_Mises> Is the levelDB being used for the new block-chain storage? And Berkeley will still be used for wallet files?
212 2012-11-02 16:27:32 <Matt_von_Mises> I was looking at levelDB and it doesn't look like it implements ACID transactions, so how does bitcoin not protect against data corruption?
213 2012-11-02 16:38:15 <sipa> Matt_von_Mises: it doesn't have ACID transactions no, but it has batch writes that are guaranteed to either be completed entirely, or not at all
214 2012-11-02 16:38:57 <sipa> so the only difference is really that if you read while building a batch commit, you won't read the uncommitted data but the old data
215 2012-11-02 16:39:05 <sipa> so if you don't do that, you're fine
216 2012-11-02 16:42:03 <sipa> you basically get everything you need, as long as you do the transaction isolation part yourself, which is quite easy in practice
217 2012-11-02 16:43:08 <Matt_von_Mises> sipa: That sounds all good then.
218 2012-11-02 16:45:40 <D34TH> i think blockchain.info derped on percentages
219 2012-11-02 16:45:46 <D34TH> Network Propagation
220 2012-11-02 16:45:47 <D34TH> lol
221 2012-11-02 16:46:02 <Matt_von_Mises> It seems that with my bitcoin code I'm basically implementing my own version of levelDB.
222 2012-11-02 17:01:53 <sipa> Matt_von_Mises: why? if you're going for the flexibility of being able to abstract the crypto library, why not the db library?
223 2012-11-02 17:03:03 <jgarzik> Matt_von_Mises: btw, some competition :) https://github.com/jgarzik/picocoin
224 2012-11-02 17:03:47 <jgarzik> ACTION wound up implementing his own leveldb in python, too: https://github.com/jgarzik/pagedb
225 2012-11-02 17:03:57 <D34TH> time to pull picocoin and see what its all aboot
226 2012-11-02 17:04:06 <D34TH> crap
227 2012-11-02 17:04:06 <Matt_von_Mises> sipa: I was looking for libraries that could do what I wanted. I didn't find any at the time (I didn't want a relational database for sure) so I've created my own code. Luckily it's not too difficult and it's an interesting learning experience. Also by implementing it myself it's all contained within my code and I can optimise it for my purposes. Also my code is powerful and low level and can be reused whenever I need to do output operations safe
228 2012-11-02 17:04:09 <D34TH> no windows make
229 2012-11-02 17:04:13 <jgarzik> D34TH: it's a big lib of nothing at the moment :)
230 2012-11-02 17:04:30 <Matt_von_Mises> sipa: I've only just looked at levelDB.
231 2012-11-02 17:04:31 <jgarzik> D34TH: eventually an SPV client. Definitely Linux-only right now, too.
232 2012-11-02 17:04:47 <D34TH> jgarzik, ill make it work ish
233 2012-11-02 17:06:03 <Matt_von_Mises> jgarzik: Always nice to have some competition.
234 2012-11-02 17:08:45 <sipa> Matt_von_Mises: alternatives could be sqlite, kyotocabinet, ...
235 2012-11-02 17:09:33 <jouke> I heard there was some sort of a checkpoint in the client. What does it do?
236 2012-11-02 17:10:00 <sipa> signature checking is disabled before block 193000
237 2012-11-02 17:10:11 <sipa> and its hash is fixed by the software
238 2012-11-02 17:10:28 <Matt_von_Mises> "pagedb is a lightweight key/value database library." Well, my code allows you to more than just associative arrays or whatever. My code allows you to safely process various output operations (overwrites, appendages, renames, deletions, replace entire files and truncate files) in a recoverable manner. So really it's more low-level and powerful than a database library.
239 2012-11-02 17:10:49 <jouke> So when I download the bootstrap.dat it doesn't need to verify everything again?
240 2012-11-02 17:11:30 <gmaxwell> jouke: It verfies most things... just not the signatures.
241 2012-11-02 17:12:57 <sipa> Matt_von_Mises: hope you enjoyed writing all that
242 2012-11-02 17:13:05 <gmaxwell> jouke: Otherwise a malicious bootstrap.dat could make you believe an invalid chain. The signature data is all past??? e.g. you don't need it to validate future transactions??? and in general isnt needed to ensure the non-inflationary property.
243 2012-11-02 17:14:02 <sipa> gmaxwell: btw, some time to give reindex your worst once more?
244 2012-11-02 17:15:13 <gmaxwell> sipa: sure, I mentioned that it was on longer exploding after that last change.. ... I need to remember to run valgrind more often and not just the first time I test something, at least when it's being changed! :P
245 2012-11-02 17:15:32 <jgarzik> kyotocabinet is really quite nice
246 2012-11-02 17:16:12 <jgarzik> Matt_von_Mises: oh pagedb is definitely more a toy than serious choice. it's written in python, for pete's sake! :)
247 2012-11-02 17:17:03 <sipa> ok, who is pete?
248 2012-11-02 17:17:13 <jgarzik> sipa: Satoshi's real name
249 2012-11-02 17:17:20 <sipa> sssssh!
250 2012-11-02 17:17:39 <sipa> Pete Nakamote, lead us!
251 2012-11-02 17:19:25 <jgarzik> gmaxwell: any chance you could run picocoin's "make check" under valgrind, on BE?
252 2012-11-02 17:21:35 <gmaxwell> "Pete Nakamote, You're the only"
253 2012-11-02 17:21:49 <gmaxwell> jgarzik: sure.
254 2012-11-02 17:23:57 <Matt_von_Mises> sipa: I've written most of it in less than a week. All that is needed is to write to a log backup file of all the information to revert changes, and then go through the operations. If there is a failure the code can simply go through the log file to restore the data. It's actually simple when you think about it, though it will need a lot of testing. And it was interesting to write it. I haven't implemented the truncation yet which I will do now.
255 2012-11-02 17:24:16 <jgarzik> gmaxwell: thanks
256 2012-11-02 17:24:30 <jgarzik> ACTION needs to figure out how to disambiguate valgrind results through a fork(2)
257 2012-11-02 17:25:03 <gmaxwell> All 10 tests passed
258 2012-11-02 17:25:03 <Matt_von_Mises> jgarzik: I once thought it was a good idea to write a game in python??? bad idea. Python is rubbish for anything more than basic scripts. It's no good for writing applications in my experience.
259 2012-11-02 17:25:09 <jgarzik> Matt_von_Mises: do you use O_DIRECT? do you look at st_blksize?
260 2012-11-02 17:25:11 <gmaxwell> jgarzik: wasn't watching for leaks.
261 2012-11-02 17:25:53 <jgarzik> gmaxwell: you should be able to run the test executables directly. 'block' and 'blkdb' probably exercise the most lib machinery.
262 2012-11-02 17:26:44 <gmaxwell> jgarzik: ? sure.
263 2012-11-02 17:27:09 <gmaxwell> they all pass under valgrind with no errors, but the default doesn't throw an error code for leaked memory iirc.
264 2012-11-02 17:27:26 <gmaxwell> (you're aware you can do 'make check TESTS_ENVIRONMENT=valgrind' right?)
265 2012-11-02 17:29:21 <jgarzik> gmaxwell: neat, wasn't aware of that
266 2012-11-02 17:29:24 <Matt_von_Mises> jgarzik: "do you use O_DIRECT? ??do you look at st_blksize?". Is that important? For optimisation purposes that can be done later. At the moment the code mostly uses the standard library (with POSIX only where needed) and flushes data to the disk.
267 2012-11-02 17:29:32 <Diablo-D3> https://www.youtube.com/redirect?q=http%3A%2F%2Fbit.ly%2FPy0DyK&session_token=IzluJfXnllJjLE2Q1-kmCf94yV98MTM1MTk2NzI3MEAxMzUxODgwODcw
268 2012-11-02 17:29:37 <Diablo-D3> and now we all take a break.
269 2012-11-02 17:29:37 <jgarzik> Matt_von_Mises: it is important for avoiding basic corruption
270 2012-11-02 17:30:02 <gmaxwell> Matt_von_Mises: if you try to do a write intent log you _must_ have some kind of barrier to make sure the log makes it to disk before your changes.
271 2012-11-02 17:30:15 <gmaxwell> That stuff is all really painful to test.
272 2012-11-02 17:30:20 <jgarzik> Matt_von_Mises: BDB pays particular attention to performing I/O on block and sector boundaries, because that is the level of atomicity provided by the hard drive.
273 2012-11-02 17:30:30 <Matt_von_Mises> Doesn't fflush() guarantee data is written?
274 2012-11-02 17:30:34 <jgarzik> no
275 2012-11-02 17:30:55 <Matt_von_Mises> Well why has no place ever said that ever?
276 2012-11-02 17:31:08 <sipa> Matt_von_Mises: that just forces the userspace buffer in libc to flush to the OS
277 2012-11-02 17:31:18 <jgarzik> " For output streams, fflush() forces a write of all user-space buffered
278 2012-11-02 17:31:22 <jgarzik> it is well documented
279 2012-11-02 17:31:28 <jgarzik> fflush flushes the internal buffer to the OS
280 2012-11-02 17:31:54 <jgarzik> fsync(fileno(FILE*)) or fdatasync(fileno(FILE*)) will flush the underlying data, post-fflush(3)
281 2012-11-02 17:31:56 <jgarzik> HOWEVER
282 2012-11-02 17:32:13 <Matt_von_Mises> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=67240
283 2012-11-02 17:32:58 <Matt_von_Mises> fsync??? however?
284 2012-11-02 17:33:03 <jgarzik> you must be aware of how the underlying filesystem and hard drive behave... fdatasync() across a block boundary may cause a non-atomic read-modify-write cycle, and in very rare cases, may corrupt old data
285 2012-11-02 17:33:36 <sipa> i don't think even leveldb cares about that
286 2012-11-02 17:33:42 <jgarzik> Matt_von_Mises: short version: call fsync() after fflush(). that gets you most of the way there.
287 2012-11-02 17:33:57 <sipa> (though it checksums its data, so corruption would be harder)
288 2012-11-02 17:34:19 <jgarzik> sipa: yeah, side consequence of checksumming + Google's use case means they throw away one server in favor of another, worst case
289 2012-11-02 17:34:23 <D34TH> jgarzik, compiling libevent what a PITA
290 2012-11-02 17:35:07 <jgarzik> BDB and all the big database engines (ORacle, sybase, db2, ...) pay very close attention to block and sector boundaries, and track very closely what the OS has flushed
291 2012-11-02 17:35:23 <Matt_von_Mises> jgarzik: I will just use fsync for now but I will make a note to come back to this and ask for some advice on how to remove the risk of data corruption as far as possible.
292 2012-11-02 17:35:24 <jgarzik> the bigger database engines practically implement their own writeback and flushing engines
293 2012-11-02 17:35:47 <jgarzik> but that's overkill for a small key/value database
294 2012-11-02 17:35:53 <Matt_von_Mises> I do think the documentation for fflush is misleading, it always says it saves the data to disk and returns on error. What am I supposed to assume?
295 2012-11-02 17:36:29 <sipa> Matt_von_Mises: it's somewhat misleading if you're unfamiliar with the terminology, i guess
296 2012-11-02 17:36:33 <jgarzik> Matt_von_Mises: <shrug> I guess your fflush docs differ from the standard Linux man-pages project
297 2012-11-02 17:36:38 <jgarzik> ?
298 2012-11-02 17:36:53 <sipa> it does only mention flushing userspace data, and sending it to the underlying write function
299 2012-11-02 17:37:28 <jgarzik> NOTES
300 2012-11-02 17:37:28 <jgarzik> Note that fflush() only flushes the user space buffers provided by the
301 2012-11-02 17:38:04 <sipa> oh, i even missed that
302 2012-11-02 17:38:31 <Matt_von_Mises> "The function fflush() forces a write of all buffered data for the given output or update stream
303 2012-11-02 17:38:36 <Matt_von_Mises> It says that on OSX
304 2012-11-02 17:39:11 <Matt_von_Mises> jgarzik: The OSX man page has not NOTES section.
305 2012-11-02 17:39:35 <sipa> so, if you now read man 2 write, it should tell you that a succesful return from write does not guarantee the data hit disk
306 2012-11-02 17:39:52 <jgarzik> Matt_von_Mises: yep. the underlying write(2) function just pushes data to the OS kernel buffers, not disk.
307 2012-11-02 17:40:49 <Matt_von_Mises> jgarzik: I understand thanks. Obviously it is important the data is properly written to disk.
308 2012-11-02 17:41:19 <sipa> even fsync doesn't guarantee everything, as the disk itself may cache the data too, but typically only for a very short time
309 2012-11-02 17:41:30 <jgarzik> correct
310 2012-11-02 17:41:33 <sipa> and that is only an issue in case of power failure
311 2012-11-02 17:41:43 <sipa> not in case of software crash or other abnormal termination
312 2012-11-02 17:42:03 <Matt_von_Mises> I will make sure to look at further ways to protect against corruption, as you said databases use more elaborate mechanisms.
313 2012-11-02 17:42:26 <sipa> i like the idea of adding a checksum to every data block written
314 2012-11-02 17:42:39 <D34TH> jgarzik, just worked my ass off getting libevent working now its complaining about jansson
315 2012-11-02 17:42:40 <D34TH> D:
316 2012-11-02 17:42:40 <Matt_von_Mises> "Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent
317 2012-11-02 17:42:41 <Matt_von_Mises> storage device"), the drive itself may not physically write the data to the platters for quite
318 2012-11-02 17:42:52 <sipa> as it pretty much guarantees you're always reading consistent data
319 2012-11-02 17:42:54 <jgarzik> D34TH: README lists the deps :)
320 2012-11-02 17:43:04 <D34TH> jgarzik, i thought i had it
321 2012-11-02 17:43:10 <sipa> actually guaranteeing durability is much harder, but far less important
322 2012-11-02 17:43:17 <D34TH> turns out its included intree for the other thing that requires it
323 2012-11-02 17:43:26 <D34TH> what version do i need
324 2012-11-02 17:43:27 <jgarzik> D34TH: maybe CFLAGS needs -I/usr/local/include or LIBS needs -L/usr/local/lib or somesuch
325 2012-11-02 17:43:37 <sipa> (for example, we don't really care that the block database is a few blocks behind after a crash, as long it represents the correct state at that time)
326 2012-11-02 17:43:38 <jgarzik> D34TH: jansson2 2.x
327 2012-11-02 17:43:42 <jgarzik> D34TH: jansson 2.x
328 2012-11-02 17:43:49 <Matt_von_Mises> "For applications that require tighter guarantees about the integrity of their data, Mac OS X
329 2012-11-02 17:43:49 <Matt_von_Mises> provides the F_FULLFSYNC fcntl. The F_FULLFSYNC fcntl asks the drive to flush all buffered
330 2012-11-02 17:43:56 <Matt_von_Mises> Hmm, I wonder if this is an OSX only thing...
331 2012-11-02 17:44:11 <jgarzik> Matt_von_Mises: yes, that is largely OSX-only. Maybe some FreeBSD does it too.
332 2012-11-02 17:44:52 <jgarzik> Matt_von_Mises: note that fdatasync(2) is also available. fsync(2) does the inode + directory entry, IIRC, as well as the file data.
333 2012-11-02 17:45:16 <jgarzik> if you are simply updating the same file over and over, you want fdatasync(2)
334 2012-11-02 17:47:00 <Matt_von_Mises> jgarzik: OK
335 2012-11-02 17:47:58 <Matt_von_Mises> OSX does not implement fdatasync
336 2012-11-02 17:48:15 <Matt_von_Mises> ISn't that convenient!
337 2012-11-02 17:50:31 <jgarzik> sipa: yep
338 2012-11-02 17:51:57 <jgarzik> sipa: The main thing about fs & disk block boundaries is avoiding an expensive read-modify-write cycle, which may introduce a window to corrupt _old_ data. This is admittedly a very rare case, which is probably why -- along with checksumming -- leveldb doesn't care. Only the Big Data Boys tend to see boundary problems.
339 2012-11-02 17:52:41 <jgarzik> but corrupting old data sucks :)
340 2012-11-02 17:53:01 <jgarzik> usually the expectation is "my newly flushed data might die somewhere in flight, but old data remains intact"
341 2012-11-02 17:53:02 <gmaxwell> for us it would be better to just make sure we can do something to recover if the database is totally borked.
342 2012-11-02 17:54:48 <jgarzik> in the context of bitcoind, I do worry about block boundaries and wallet flushing
343 2012-11-02 17:55:27 <jgarzik> but the problem window is very small, and the solutions tend to be highly inefficient (writing a lot more data than current bitcoind)
344 2012-11-02 17:55:38 <jgarzik> the other databases can be rebuilt
345 2012-11-02 17:55:45 <jgarzik> so who cares
346 2012-11-02 18:10:20 <sipa> jgarzik: that problem does not exist if you're only appending, right?
347 2012-11-02 18:11:33 <gmaxwell> AFAIK, it does. You'll still rewrite the last sector if it didn't end on a sector boundary.
348 2012-11-02 18:12:03 <gmaxwell> This is invisble in the media. But I think the answer to that is: backup backup backup.
349 2012-11-02 18:14:17 <Matt_von_Mises> jgarzik: Does O_SYNC not work to ensure data has been written to disk?
350 2012-11-02 18:14:41 <sipa> Matt_von_Mises: writing with O_SYNC is similar to writing + calling fsync
351 2012-11-02 18:15:03 <Matt_von_Mises> And that includes the vulnerabilities of fsync?
352 2012-11-02 18:15:12 <sipa> yes
353 2012-11-02 18:15:16 <sipa> but those are very limited
354 2012-11-02 18:15:17 <Luke-Jr> gavinandresen: ++ on the forum idea
355 2012-11-02 18:15:43 <sipa> Matt_von_Mises: but O_SYNC will make every write synchronous, so it's very slow
356 2012-11-02 18:16:03 <Matt_von_Mises> sipa: Yes, best to sync only when needed.
357 2012-11-02 18:16:30 <sipa> indeed
358 2012-11-02 18:21:07 <D34TH> jgarzik, http://pastebin.com/0LBMsyPQ
359 2012-11-02 18:21:14 <D34TH> close but not quite
360 2012-11-02 18:22:03 <jgarzik> D34TH: does your system support ipv6?
361 2012-11-02 18:22:09 <D34TH> it does
362 2012-11-02 18:22:14 <jgarzik> hrm
363 2012-11-02 18:22:16 <D34TH> im not sure about mingw though
364 2012-11-02 18:24:33 <jgarzik> D34TH: the first bits are confusing. it appears to be choking on its own sys/socket.h.
365 2012-11-02 18:25:03 <D34TH> new choke
366 2012-11-02 18:25:21 <D34TH> oh wait
367 2012-11-02 18:25:24 <jgarzik> D34TH: what is mingw's sys/socket.h, lines 86-90?
368 2012-11-02 18:25:25 <D34TH> that was a different project
369 2012-11-02 18:25:36 <jgarzik> heh
370 2012-11-02 18:26:13 <D34TH> the different choke was from a different project
371 2012-11-02 18:26:18 <D34TH> im getting you the socket.h
372 2012-11-02 18:26:24 <D34TH> http://pastebin.com/H5t3uF47
373 2012-11-02 18:31:49 <D34TH> jgarzik, any ideas?
374 2012-11-02 18:34:22 <bitscotty> anyone buying
375 2012-11-02 18:34:43 <sipa> #bitcoin-otc
376 2012-11-02 18:37:28 <jgarzik> D34TH: that sys/socket.h wants struct sockaddr definition
377 2012-11-02 18:37:56 <jgarzik> D34TH: so the answer is finding out which mingw header defines struct sockaddr, and including that -before- sys/socket.h in dns.c
378 2012-11-02 18:38:30 <jgarzik> D34TH: additionally, the original paste indicate it was not finding struct addrinfo for getaddrinfo(), so need to find where that is defined too
379 2012-11-02 18:38:35 <jgarzik> D34TH: maybe winsock.h ?
380 2012-11-02 18:38:44 <jgarzik> ACTION peeks at bitcoind
381 2012-11-02 18:39:49 <jgarzik> D34TH: yeah, bitcoind's compat.h has the magic likely needed... http://pastebin.com/zzC9Zu0M
382 2012-11-02 18:40:32 <D34TH> heh, ill just throw that in dns.h
383 2012-11-02 18:40:33 <D34TH> :3
384 2012-11-02 18:41:40 <D34TH> or better yet
385 2012-11-02 18:41:45 <D34TH> picocoin-config.h
386 2012-11-02 18:43:35 <jgarzik> D34TH: probably a better place, indeed
387 2012-11-02 18:44:22 <jgarzik> D34TH: here's the full magic: https://github.com/bitcoin/bitcoin/blob/master/src/compat.h
388 2012-11-02 18:44:36 <jgarzik> D34TH: though picocoin doesn't use all that
389 2012-11-02 18:45:49 <jgarzik> and a tiny bit more WIN32 mingw magic in bitcoind's https://github.com/bitcoin/bitcoin/blob/master/src/util.h
390 2012-11-02 18:48:52 <Matt_von_Mises> Mentioning again the disk output problem??? what can be said about sync()? Supposedly flushes all output caches and blocks until all pending output operations are completed.
391 2012-11-02 18:49:17 <jgarzik> Matt_von_Mises: sync() is system-wide
392 2012-11-02 18:49:31 <jgarzik> Matt_von_Mises: obviously slower and more impactful than fsync()'ing a single file
393 2012-11-02 18:49:42 <jgarzik> Matt_von_Mises: however, sync() does enable lazy programming
394 2012-11-02 18:51:46 <Matt_von_Mises> jgarzik: I'm wondering if sync() provides a better guarantee than fsync()
395 2012-11-02 18:52:00 <sipa> no
396 2012-11-02 18:53:05 <bitscotty> someone help me?
397 2012-11-02 18:53:11 <sipa> bitscotty: please don't PM me - if you want to sell something, go to #bitcoin-otc
398 2012-11-02 18:53:18 <bitscotty> sipa
399 2012-11-02 18:53:19 <bitscotty> its nt
400 2012-11-02 18:53:24 <bitscotty> i need help i forgot how to auth
401 2012-11-02 19:14:43 <bitscotty> how do i decrypt a key
402 2012-11-02 19:24:53 <jgarzik> bitscotty: this is not a support channel. try #bitcoin or https://bitcointalk.org/
403 2012-11-02 19:32:16 <bitscotty> sorry
404 2012-11-02 19:43:10 <denisx> what is the estimated date of the blocksplit?
405 2012-11-02 19:43:16 <sipa> ?
406 2012-11-02 19:43:37 <sipa> do you mean the 50->25 BTC subsidy drop?
407 2012-11-02 19:43:38 <BlueMatt> ;;seen TD
408 2012-11-02 19:43:39 <gribble> TD was last seen in #bitcoin-dev 5 hours, 7 minutes, and 37 seconds ago: <TD> hah
409 2012-11-02 19:43:53 <denisx> yes
410 2012-11-02 19:44:47 <gribble> 206175
411 2012-11-02 19:44:47 <sipa> ;;bc,blocks
412 2012-11-02 19:44:56 <gribble> Alias bc,24hprc, Alias bc,avgprc, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btcguild, Alias bc,calc, Alias bc,calcd, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias bc,fx, Alias bc,gen, Alias bc,gend, Alias bc,halfreward, Alias bc,help, Alias bc,hextarget, Alias bc,intersango, Alias (2 more messages)
413 2012-11-02 19:44:56 <sipa> ;;bc,help
414 2012-11-02 19:45:02 <sipa> ;;bc,halfreward
415 2012-11-02 19:45:03 <gribble> Estimated time of bitcoin block reward halving: Thu Nov 29 02:15:00 2012 | Time remaining: 3 weeks, 5 days, 13 hours, 30 minutes, and 0 seconds
416 2012-11-02 19:46:54 <sipa> soon!
417 2012-11-02 19:51:56 <denisx> the thing is, when will I start to switch the amount a user gets per share?
418 2012-11-02 19:53:56 <sipa> at block 210000
419 2012-11-02 19:54:16 <denisx> sipa: no, that is too late
420 2012-11-02 19:54:28 <sipa> what payout model do you use?
421 2012-11-02 19:54:37 <denisx> sipa: PPS
422 2012-11-02 19:55:28 <sipa> so you pay per what the share will on average gain you
423 2012-11-02 19:55:34 <denisx> my user subit shares before the split and get 50/diff and then I find a block after the split
424 2012-11-02 19:55:55 <sipa> well if they mine on block 210000, they get 25/diff
425 2012-11-02 19:56:01 <denisx> then I would pay too much
426 2012-11-02 19:56:04 <sipa> if they mine on a block before 210000, they get 50/diff
427 2012-11-02 19:56:12 <sipa> i don't see how?
428 2012-11-02 19:56:45 <denisx> image they submit 3 million shares before the split but I find the block after the split
429 2012-11-02 19:56:46 <sipa> oh, by "mining on block 210000" i do mean "when they are working to produce 210000"
430 2012-11-02 19:56:49 <denisx> imagine
431 2012-11-02 19:57:09 <sipa> so as soon as the height becomes 209999, you change the payout
432 2012-11-02 19:58:46 <denisx> but I do not know if my next block will be before or after the blocksplit
433 2012-11-02 19:59:45 <sipa> how can you not know? you're building it?
434 2012-11-02 19:59:53 <sipa> ah, right
435 2012-11-02 20:00:02 <denisx> good! ;)
436 2012-11-02 20:00:49 <sipa> and please don't call it 'split' - that word scares me :p
437 2012-11-02 20:01:15 <denisx> how should I call it?
438 2012-11-02 20:01:35 <sipa> subsidy drop? reward halving?
439 2012-11-02 20:01:43 <sipa> never mind, i'm kidding :)
440 2012-11-02 20:01:58 <sipa> so, the shares that come in after the height reaches 209999 count only for 50%, i'd say
441 2012-11-02 20:02:44 <denisx> sipa: and then I find the block before and make some extra btc ;)
442 2012-11-02 20:03:14 <denisx> sipa: but I need some hours per block ;)
443 2012-11-02 20:08:36 <denisx> I think I will calculate how long I need for one block with my poolrate and then I will switch 50% of that time before the "reward halving" happens
444 2012-11-02 20:08:44 <denisx> this should be fair for all
445 2012-11-02 22:20:32 <phantomcircuit> -loadblock has a pretty amazing speed up
446 2012-11-02 22:20:42 <phantomcircuit> it's not nearly as much as you'd expect though
447 2012-11-02 22:20:55 <sipa1024> phantomcircuit: which code version?
448 2012-11-02 22:27:15 <phantomcircuit> sipa, stable verson from bitcoin.org
449 2012-11-02 22:27:26 <phantomcircuit> so
450 2012-11-02 22:27:27 <phantomcircuit> 0.7.1
451 2012-11-02 22:27:43 <phantomcircuit> there is like
452 2012-11-02 22:27:50 <phantomcircuit> a fucking hole in my pinky figner
453 2012-11-02 22:28:06 <phantomcircuit> sipa, roughly at block 120k
454 2012-11-02 22:28:16 <phantomcircuit> started about two hours ago
455 2012-11-02 22:28:53 <sipa> yeah, try the same with git head and be amazed :)
456 2012-11-02 22:28:55 <gmaxwell> phantomcircuit: <0.8 is mostly bound by bdb thrashing the disk.
457 2012-11-02 22:29:24 <phantomcircuit> this is for something marginally important
458 2012-11-02 22:29:25 <sipa> 120k blocks should take something like 3 minutes?
459 2012-11-02 22:29:36 <phantomcircuit> srsly?
460 2012-11-02 22:29:37 <phantomcircuit> damn
461 2012-11-02 22:29:44 <gmaxwell> yea, then don't run git master for that. :P
462 2012-11-02 22:29:58 <phantomcircuit> gmaxwell, hehe that's why i said it :)
463 2012-11-02 22:30:20 <phantomcircuit> it's funny
464 2012-11-02 22:30:28 <phantomcircuit> moving around 2GB files 10 MB/s feels slow
465 2012-11-02 22:30:32 <phantomcircuit> and yet i know it's not
466 2012-11-02 22:35:11 <sipa> 70s
467 2012-11-02 22:35:14 <sipa> 11/02/12 23:33:45 SetBestChain: new best=00000000839a8e6886ab height=1 work=8590065666 tx=2 date=01/09/09 02:54:25
468 2012-11-02 22:35:17 <sipa> 11/02/12 23:34:55 SetBestChain: new best=0000000000000e07595f height=120000 work=4404269158302965364 tx=435536 date=04/24/11 23:20:01
469 2012-11-02 22:37:39 <Diablo-D3> gmaxwell: would using C as an IL really be that bad?
470 2012-11-02 23:25:41 <phantomcircuit> sipa, running git HEAD on an ssd using loadblock segfaulted
471 2012-11-02 23:25:43 <phantomcircuit> lol
472 2012-11-02 23:26:04 <phantomcircuit> turn on core dumps and try again
473 2012-11-02 23:26:14 <gmaxwell> got a backtrace?
474 2012-11-02 23:26:19 <phantomcircuit> i suspect there's a race condition here someplace
475 2012-11-02 23:26:29 <phantomcircuit> had core dumps disabled :(
476 2012-11-02 23:27:23 <phantomcircuit> got it
477 2012-11-02 23:27:24 <phantomcircuit> one sec
478 2012-11-02 23:28:13 <phantomcircuit> http://pastebin.com/raw.php?i=Y55HZ68d
479 2012-11-02 23:28:43 <phantomcircuit> Program terminated with signal 11, Segmentation fault.
480 2012-11-02 23:29:19 <phantomcircuit> im guessing something is being freed before it's written