1 2013-10-24 00:04:36 <Ascendion> Luke-Jr said something to me earlier that got me worried -- how does a wallet client tell (from a cold start) what transactions apply to the addresses in the wallet -- both inbound and outbound ??
2 2013-10-24 00:05:14 <Luke-Jr> Ascendion: wallets look specifically for transactions to addresses pointing at them
3 2013-10-24 00:05:35 <Luke-Jr> and they also notice if transactions consume coins/outputs they control/contain
4 2013-10-24 00:05:36 <Ascendion> as the destination ??
5 2013-10-24 00:05:43 <Luke-Jr> addresses are only destinations
6 2013-10-24 00:05:45 <Luke-Jr> ever
7 2013-10-24 00:06:26 <Ascendion> but if you have to sign something to prove your right to spend an output, doesnt that imply using a key for the signature ??
8 2013-10-24 00:07:25 <jegz> how can I just create a new wallet?
9 2013-10-24 00:07:28 <Ascendion> and shouldnt that private key used match the public key of the destination in the output ??
10 2013-10-24 00:07:29 <jegz> remove the old one and restart the server?
11 2013-10-24 00:07:30 <Luke-Jr> Ascendion: yes, the wallet contains numerous keys
12 2013-10-24 00:08:32 <Luke-Jr> Ascendion: the output is just 2 hashes and an index
13 2013-10-24 00:08:44 <Luke-Jr> first hash + index identify the coin publicly
14 2013-10-24 00:09:17 <Luke-Jr> second hash points at the destination wallet and user
15 2013-10-24 00:09:26 <Luke-Jr> (which may be distinct entities)
16 2013-10-24 00:11:11 <Ascendion> ok -- lemme rephrase then -- I'm about to start pulling blockchain and transaction data from a bitcoind with jsonrpc -- I need to be able to reconstruct account balances -- can I do that just knowing a public key... or do I also have to have the private for each address in the wallet
17 2013-10-24 00:11:35 <Luke-Jr> Ascendion: you can't do that.
18 2013-10-24 00:11:49 <Luke-Jr> there is no public information about accounts
19 2013-10-24 00:12:04 <Ascendion> not even bitcoin-qt can do that given both keys ??
20 2013-10-24 00:12:18 <Luke-Jr> if you could guess the structure of a wallet, you could potentially figure out the wallet balance, but that's getting harder and harder
21 2013-10-24 00:12:31 <Luke-Jr> both keys? wallets have hundreds of keys usually
22 2013-10-24 00:12:46 <Ascendion> I wont have the wallet data file -- at most I will have the blockchain and the keys
23 2013-10-24 00:12:49 <Luke-Jr> and no, even if you have every key with 100% certainty, you know nothing about accounts
24 2013-10-24 00:13:27 <Ascendion> so bitcoin has zero recoverability if the wallet is lost but you still have the keys
25 2013-10-24 00:13:49 <Luke-Jr> if you have the keys, you can recover the money, but not accounting info
26 2013-10-24 00:14:47 <Ascendion> if I can recover the money -- there has to be some way to identify what money in the chain currently belongs to the key then... or I'm completely lost
27 2013-10-24 00:14:49 <Luke-Jr> unless it's a HD wallet master key
28 2013-10-24 00:14:55 <Luke-Jr> you can probably recover accounts from that
29 2013-10-24 00:15:05 <Luke-Jr> but you'd need to provide the metadata still
30 2013-10-24 00:15:20 <Luke-Jr> Ascendion: money doesn't belong to keys, it belongs to people
31 2013-10-24 00:16:23 <Luke-Jr> Ascendion: there's a number of concepts in play:
32 2013-10-24 00:16:28 <Apocalyptic> Luke-Jr, technically speaking he's right
33 2013-10-24 00:16:38 <Ascendion> dont play semantics with me -- a keypair has to own the money -- a person/wallet is just a collection of keypairs :)
34 2013-10-24 00:16:48 <Apocalyptic> where the hell do people come in play here ?
35 2013-10-24 00:17:09 <sipa> Ascendion: coins (unsoent transaction outouts) are assigned to outout scripts
36 2013-10-24 00:17:20 <Luke-Jr> wallets control coins; accounts track balances; people own account(s); addresses point to a specific wallet+account
37 2013-10-24 00:17:38 <sipa> Ascendion: some outout scriots are recognizable by your wallet as being spendable by the keys you have
38 2013-10-24 00:17:58 <Ascendion> right -- I got that (though I think embedded scripting in the transaction is crazy)... and usually that script has a key in it -- the destination of the output
39 2013-10-24 00:18:29 <sipa> well the script IS the destination
40 2013-10-24 00:18:43 <sipa> addresses are shorthand templates for specific scripts
41 2013-10-24 00:18:51 <Luke-Jr> the address is used to form the output's scriptPubKey, but the account the address points to is NOT necessarily related to the account sending the transaction that consumes it
42 2013-10-24 00:19:32 <sipa> Luke-Jr is talking about how there can be multiple owners for money in a wallet
43 2013-10-24 00:19:45 <sipa> he's right, but i don't think it is relevant here
44 2013-10-24 00:20:21 <Luke-Jr> sipa: Ascendion wants to prove "from addresses"
45 2013-10-24 00:20:27 <Luke-Jr> so all the usual points apply
46 2013-10-24 00:21:02 <sipa> unsure
47 2013-10-24 00:21:32 <sipa> so if you're looking for incoming transactions: notice transaction outputs that you recignize as spendable
48 2013-10-24 00:21:33 <CodeShark> sipa: not much shorterhand than the actual scripts themselves :p
49 2013-10-24 00:21:42 <Ascendion> I want to reconstruct a transaction history for a given pool of addresses -- I should be able to track through finding all pays to an address, and then if those pays have been spent
50 2013-10-24 00:22:01 <Ascendion> I dont need a from address per-se -- just be able to reconstruct the balance
51 2013-10-24 00:22:14 <sipa> if you want outgoing transactions: those that spend the coins that were spendable
52 2013-10-24 00:22:30 <sipa> that's all
53 2013-10-24 00:23:18 <Ascendion> thats all that are needed really -- I seriously doubt by this time that anyone owns a bitcoin that hasnt passed through several transactions
54 2013-10-24 00:23:36 <sipa> of course
55 2013-10-24 00:23:45 <Luke-Jr> Ascendion: addresses don't have balances, just wallets and accounts; you can't get the balance of an account, but you can of a wallet if you know *all* its addresses (many of which are hidden by the wallet software)
56 2013-10-24 00:23:46 <sipa> any coin mined is fresh...
57 2013-10-24 00:24:07 <CodeShark> there are loads of early mined coins that have never been spent
58 2013-10-24 00:24:09 <sipa> right, he wants the balance of a set of addresses
59 2013-10-24 00:24:14 <sipa> that's a wallet
60 2013-10-24 00:24:20 <sipa> that's perfectly wel
61 2013-10-24 00:24:24 <sipa> defined
62 2013-10-24 00:24:26 <Luke-Jr> Ascendion: if you send me 5 BTC, that coin may become spent even if I haven't done anything with the money you sent me
63 2013-10-24 00:24:29 <Ascendion> ok -- semantics again -- when I say account I mean address (though I did see something about accounts within a wallet -- dont understand what those are all about yet)
64 2013-10-24 00:24:54 <Luke-Jr> addresses don't have balances
65 2013-10-24 00:25:00 <Luke-Jr> they receive coins once, that's it.
66 2013-10-24 00:25:10 <Luke-Jr> a coin*
67 2013-10-24 00:25:13 <sipa> Ascendion: the reason for the distinction between wallet and address is that you shouldn't reuse addresses
68 2013-10-24 00:25:14 <CodeShark> argh, when are we going to retire the term "address" to avoid this type of confusion for good? :)
69 2013-10-24 00:25:27 <sipa> CodeShark: impossible now
70 2013-10-24 00:25:40 <Luke-Jr> CodeShark: when the payment protocol prevails?
71 2013-10-24 00:25:46 <CodeShark> we can't really go mainsteam until we get this right
72 2013-10-24 00:26:06 <Luke-Jr> sipa: maybe we could get away with "destination" ;)
73 2013-10-24 00:26:16 <Ascendion> when you send money to an address, that address recieves the money even if its credited to a containing wallet -- how could coinbase figure out that I just sent them coins if they couldnt detect that coins were sent to the address they provided
74 2013-10-24 00:26:17 <Luke-Jr> although that doesn't express the one-time use
75 2013-10-24 00:26:42 <Luke-Jr> Ascendion: no, the address doesn't receive it; the wallet (and user) does - this is semantics, but it's *important* semantics
76 2013-10-24 00:26:44 <Ascendion> and they manage to do it within a minute of when I send coins
77 2013-10-24 00:26:58 <petertodd> CodeShark: the best part is that with the payment protocol what will actually happen is the word address will get overloaded with URL, furthering user confusion. ("So why can't I make my webbrowser open up 1DNHCc5rzjYdYxynFvH8aEtnCAP3dif6La?")
78 2013-10-24 00:27:08 <Luke-Jr> Ascendion: the address is just a pointer
79 2013-10-24 00:27:22 <CodeShark> they listen to the network and filter transactions by output script, ascendion
80 2013-10-24 00:27:26 <sipa> Ascendion: coins are assigned to addresses
81 2013-10-24 00:27:33 <Luke-Jr> sipa: facepalm
82 2013-10-24 00:27:47 <Luke-Jr> they're assigned to scriptPubKeys, which are created from (but are not) addresses
83 2013-10-24 00:27:56 <sipa> right, ok
84 2013-10-24 00:28:29 <Ascendion> ok -- so how does someone like coinbase verify that a scriptPubKey refers to a specific recieving address ??
85 2013-10-24 00:28:48 <sipa> every address corresponds to a particular script
86 2013-10-24 00:28:54 <CodeShark> all you care about is the output script, ascendion
87 2013-10-24 00:28:56 <Luke-Jr> Ascendion: they keep an index of every possible scriptPubKey they control
88 2013-10-24 00:28:58 <Ascendion> would I need just the pub key of the address, or both pub and priv ??
89 2013-10-24 00:29:03 <sipa> (though not the other way around)
90 2013-10-24 00:29:15 <CodeShark> addresses, as sipa was saying, are just representations of specific output script types
91 2013-10-24 00:29:31 <Ascendion> ok -- so there is a unique scriptPubKey for any given address ??
92 2013-10-24 00:29:35 <CodeShark> the output script specifies the conditions under which the coins can be redeemed
93 2013-10-24 00:29:35 <sipa> you only need the privkey to spend a coin that is assigned to a script that involves a particular corresponding pubkey
94 2013-10-24 00:29:41 <CodeShark> and the input script redeems them
95 2013-10-24 00:29:42 <sipa> Ascendion: yes
96 2013-10-24 00:29:49 <Luke-Jr> Ascendion: yep
97 2013-10-24 00:30:07 <sipa> Ascendion: a script that says "require a valid signature, and a public key whose hash is X"
98 2013-10-24 00:30:14 <Luke-Jr> ACTION wonders if we should be adopting BIP 19 terminology here to make things clearer, but meh
99 2013-10-24 00:30:19 <sipa> with X different for every address
100 2013-10-24 00:30:24 <Ascendion> dont bother :)
101 2013-10-24 00:30:29 <CodeShark> an address is a hash
102 2013-10-24 00:30:31 <Luke-Jr> BIP 18*
103 2013-10-24 00:30:52 <CodeShark> an address is just a base58-encoded hash
104 2013-10-24 00:31:02 <Ascendion> so if I have a list of pubkeys from one of my users, I can generate the scriptPubKeys, scan transactions, and reconstruct the transaction history
105 2013-10-24 00:31:22 <CodeShark> yes
106 2013-10-24 00:31:26 <BlueMatt> yes, assuming all their txn were on the chain
107 2013-10-24 00:31:28 <sipa> you can find incoming transactions to those addresses, ues
108 2013-10-24 00:31:32 <Ascendion> dont need the privkeys at all
109 2013-10-24 00:31:33 <Luke-Jr> Ascendion: if the user is using a dedicated wallet with one account, yes
110 2013-10-24 00:31:42 <CodeShark> the privkeys are only needed to sign transaction
111 2013-10-24 00:31:47 <Luke-Jr> heck, you don't even need the pubkeys
112 2013-10-24 00:31:51 <Luke-Jr> you could do it with just the addresses
113 2013-10-24 00:32:05 <sipa> for outgoing ones, you need to find the transactions that spend the outputs created by the crediting transactions
114 2013-10-24 00:32:21 <CodeShark> Luke-Jr - you would need either the pubkeys or a redeemscript for multisigs :)
115 2013-10-24 00:32:22 <Ascendion> and the address is all that I need to validate a signed message from a privkey ??
116 2013-10-24 00:32:27 <Luke-Jr> "for outgoing ones" is where things will break if there are multiple accounts using the wallet
117 2013-10-24 00:32:40 <Ascendion> sipa -- I got that part hours ago :)
118 2013-10-24 00:32:45 <sipa> ok
119 2013-10-24 00:32:51 <Luke-Jr> Ascendion: no
120 2013-10-24 00:33:00 <sipa> Ascendion: you're talking about message signing?
121 2013-10-24 00:33:12 <Luke-Jr> well, I guess you could reverse the pubkey out of the signatures
122 2013-10-24 00:33:36 <sipa> that's what we do
123 2013-10-24 00:33:39 <Luke-Jr> Ascendion: if you have the address, you *don't* have the pubkey.
124 2013-10-24 00:33:41 <Ascendion> sipa -- yes -- to validate that a user owns an address before I reconstruct the history and display the information to them
125 2013-10-24 00:33:42 <Luke-Jr> sipa: bitcoin doesn't
126 2013-10-24 00:34:09 <sipa> Luke-Jr: you know i wrote it?
127 2013-10-24 00:34:29 <Luke-Jr> sipa: signed messages are something different
128 2013-10-24 00:34:53 <sipa> Luke-Jr: that is what we're talking about now, apparently
129 2013-10-24 00:34:58 <Luke-Jr> Ascendion: you're going to ask for a signed message from every address in the wallet?
130 2013-10-24 00:35:28 <Ascendion> Luke-Jr -- I dont have a choice -- if they want all or part of their wallet replicated on my system, I've got to validate ownership
131 2013-10-24 00:35:45 <Ascendion> for people that create addresses on a whim that might be a problem :)
132 2013-10-24 00:35:48 <Luke-Jr> Ascendion: why?
133 2013-10-24 00:35:55 <Luke-Jr> Ascendion: bitcoin requires you to create addresses on a whim
134 2013-10-24 00:36:00 <Luke-Jr> you need a new address for every transaction
135 2013-10-24 00:36:16 <sipa> it's best practice for sure
136 2013-10-24 00:36:25 <Ascendion> huh ?? I've got only 4 recieve addresses -- why do I need more ??
137 2013-10-24 00:36:34 <sipa> Ascendion: privacy
138 2013-10-24 00:36:39 <Luke-Jr> Ascendion: because they're only correct to use once
139 2013-10-24 00:36:42 <sipa> yours and everyone else's
140 2013-10-24 00:36:58 <Luke-Jr> it works right now by coincidence, but it breaks the design of the system and makes you (and others!) more vulnerable
141 2013-10-24 00:37:02 <CodeShark> "addresses" are not identifiers of recipients - they are one-time scripts
142 2013-10-24 00:37:15 <sipa> thwy ought to be, indeed
143 2013-10-24 00:37:24 <Luke-Jr> Ascendion: people have had lots of money stolen because they used addresses more than once
144 2013-10-24 00:37:25 <sipa> unfortunately, not much software makes that easy
145 2013-10-24 00:37:26 <CodeShark> they should be called "payment scripts"
146 2013-10-24 00:37:27 <CodeShark> :)
147 2013-10-24 00:37:37 <CodeShark> send me a payment script, not send me an address
148 2013-10-24 00:37:39 <Luke-Jr> CodeShark: invoice id :p
149 2013-10-24 00:37:49 <CodeShark> or invoice script is fine too
150 2013-10-24 00:37:49 <sipa> Luke-Jr: i like!
151 2013-10-24 00:38:30 <CodeShark> invoice is good - it suggests one-time use
152 2013-10-24 00:38:41 <Apocalyptic> <Luke-Jr> Ascendion: people have had lots of money stolen because they used addresses more than once // care to elaborate on that ?
153 2013-10-24 00:39:00 <sipa> that was still because of other mistakes too
154 2013-10-24 00:39:17 <sipa> the only real reason is privacy properties of the system
155 2013-10-24 00:39:21 <Luke-Jr> ACTION shrugs, those mistakes would have been harmless (in some cases) had the users been using bitcoin correctly.
156 2013-10-24 00:39:30 <Ascendion> and here I though of addresses only as a way to track where income was coming from
157 2013-10-24 00:39:45 <Luke-Jr> Ascendion: that too
158 2013-10-24 00:39:58 <Luke-Jr> sipa: knowing what the payment is from/for is also a real reason :D
159 2013-10-24 00:40:02 <sipa> d
160 2013-10-24 00:40:04 <sipa> yes
161 2013-10-24 00:40:20 <sipa> though using a different one each time implies that already :)
162 2013-10-24 00:40:30 <sipa> ACTION zZzZ
163 2013-10-24 00:42:09 <Ascendion> you still havent elaborated on how reusing addresses can cause a loss -- makes me worry about having used the same address in eligius all this time :)
164 2013-10-24 00:42:24 <CodeShark> it's a single point of failure, ascendion
165 2013-10-24 00:42:38 <Ascendion> but what are the failure modes ??
166 2013-10-24 00:42:45 <CodeShark> you lose it/someone steals it
167 2013-10-24 00:42:58 <BlueMatt> if you're tracking things by address and your software is fucked up beyond all repair you may create transactions invalidly or something
168 2013-10-24 00:43:07 <Ascendion> someone has to get a copy of my wallet then to get the keys behind that address
169 2013-10-24 00:43:14 <BlueMatt> in any case, you gotta fuck up bad to do that, but mostly its just you're an idiot if you have lots of coins behind one key
170 2013-10-24 00:43:19 <BlueMatt> or behind a set of keys stored in the same place
171 2013-10-24 00:43:50 <CodeShark> the main reason you don't want to use a single address for all your transactions is privacy
172 2013-10-24 00:43:54 <Belxjander> BlueMatt: I "push forward" to a new address at random times and don't mind collecting dust :)
173 2013-10-24 00:43:56 <BlueMatt> there have been lots of cases of a vps provider getting owned and then someone using that to drain btc out of server wallets
174 2013-10-24 00:44:27 <CodeShark> the issue is more storage in one place than it being just one key (as far as theft)
175 2013-10-24 00:45:29 <Luke-Jr> Ascendion: ECDSA weaknesses
176 2013-10-24 00:45:33 <CodeShark> even if you have two keys stored in a single place, it
177 2013-10-24 00:45:36 <Ascendion> ok -- so its all based on theft of wallet data more than anything else
178 2013-10-24 00:45:41 <CodeShark> it's no more secure than one key stored in a single place
179 2013-10-24 00:45:57 <Luke-Jr> Ascendion: if someone figures out the K value in your signature, they can figure out your private key
180 2013-10-24 00:46:32 <Luke-Jr> Ascendion: the more signatures exist, the easier that becomes; if you use the same K twice, you're screwed
181 2013-10-24 00:46:34 <Ascendion> hmmm sounds like time to write a GPU or FPGA algo to exploit that :)
182 2013-10-24 00:47:00 <Luke-Jr> Ascendion: don't bother, people are already automating it by now
183 2013-10-24 00:47:19 <CodeShark> although assuming you use a decent RNG, the chances of finding a K collision are still astronomically tiny
184 2013-10-24 00:48:05 <CodeShark> that sort of attack is only practical against buggy software
185 2013-10-24 00:48:26 <BlueMatt> or buggy hardware wallets, which I would not be surprised to see fuck up k selection
186 2013-10-24 00:48:34 <BlueMatt> ^ can we have deterministic k yet?
187 2013-10-24 00:48:50 <Ascendion> ok -- so requiring a signed message to validate an address could possibly cost me some users of this specific feature if they are address-happy :) but for people with just a few addresses, they may choose to go through the hassle
188 2013-10-24 00:49:28 <Luke-Jr> CodeShark: BlueMatt: is it really buggy, if proper use is not vulnerable? :P
189 2013-10-24 00:49:45 <Luke-Jr> Ascendion: if they use bitcoin correctly*
190 2013-10-24 00:49:52 <sipa> Luke-Jr: yes
191 2013-10-24 00:50:05 <BlueMatt> Luke-Jr: ^
192 2013-10-24 00:50:25 <sipa> if they have broken k selection, who knows what other vulnerabilities exist
193 2013-10-24 00:50:34 <Ascendion> I never read anywhere that the right way to use bitcoin was to generate 100s of addresses -- no user guide told me to do that :)
194 2013-10-24 00:51:13 <CodeShark> there are user guides?
195 2013-10-24 00:51:38 <BlueMatt> bitcoin-qt does that for you magically
196 2013-10-24 00:51:41 <Ascendion> Luke-Jr is the user guide apparently :)
197 2013-10-24 01:02:27 <swulf--> InvalidChainFound: current best=000000000000000ba58737621a993232c9ece0913476866ce78d45289d130d9b height=265565 log2_work=73.090655 date=2013-10-23 17:22:52
198 2013-10-24 01:02:27 <swulf--> InvalidChainFound: invalid block=000000000000000a606604978609119b8452336eddb3377a3f91f8233af3e6e0 height=265603 log2_work=73.09691 date=2013-10-23 21:05:12
199 2013-10-24 01:02:27 <swulf--> InvalidChainFound: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
200 2013-10-24 01:02:48 <swulf--> I've now restarted this process about 8 times, and *every* time it dies at block 265565
201 2013-10-24 01:11:57 <sipa> swulf--: what version?
202 2013-10-24 01:12:09 <swulf--> tried both 0.8.3 and 0.8.5, same thing happens
203 2013-10-24 01:15:33 <BlueMatt> swulf--: drive corruption possible (smart data showing anything?)
204 2013-10-24 01:17:48 <skinnkavaj> Even assuming the hash rate is always rising, there is still a chance that it will require 100 years to generate the block, isn't it?
205 2013-10-24 01:18:53 <sipa> swulf--: always at the same block?
206 2013-10-24 01:19:01 <sipa> that is suspicious
207 2013-10-24 01:19:13 <sipa> and may mean there is an actual bug
208 2013-10-24 01:19:28 <sipa> skinnkavaj: yes
209 2013-10-24 01:19:44 <skinnkavaj> sipa: isnt that scary
210 2013-10-24 01:19:45 <Ascendion> or he keeps connecting to and syncing from a peer trying a fork attack :)
211 2013-10-24 01:20:02 <sipa> skinnkavaj: not if you understand how ridiculously small that chance is
212 2013-10-24 01:20:31 <skinnkavaj> sipa: but maybe 24 hours for a block is more possible and that could do a lot of damage i guess
213 2013-10-24 01:21:54 <sipa> skinnkavaj: not if you understand how ridiculously small that chance is :)
214 2013-10-24 01:22:00 <gribble> Error: '1h' is not a valid positive integer.
215 2013-10-24 01:22:00 <sipa> ;;tblb 1h
216 2013-10-24 01:22:16 <sipa> ;;tblb 3600
217 2013-10-24 01:22:17 <gribble> The expected time between blocks taking 1 hour and 0 seconds to generate is 10 weeks, 2 days, 5 hours, 11 minutes, and 52 seconds
218 2013-10-24 01:22:29 <sipa> ;;tblb 7200
219 2013-10-24 01:22:30 <gribble> The expected time between blocks taking 2 hours and 0 seconds to generate is 3337 years, 35 weeks, 0 days, 16 hours, 42 minutes, and 21 seconds
220 2013-10-24 01:23:13 <sipa> ;;tblb 10800
221 2013-10-24 01:23:14 <gribble> The expected time between blocks taking 3 hours and 0 seconds to generate is 56312041 years, 33 weeks, 4 days, 11 hours, 58 minutes, and 42 seconds
222 2013-10-24 01:28:18 <Luke-Jr> Ascendion: bitcoin.pdf does
223 2013-10-24 01:57:55 <super3> hello
224 2013-10-24 02:27:31 <warren> jgarzik_: gmaxwell: http://193.28.235.60/~warren/openssl/fedora-19/ GPG signed and tested
225 2013-10-24 02:52:44 <super3> jgarzik: there?
226 2013-10-24 03:38:25 <PRab> Is there an official policy on merging Pull Requests into master?
227 2013-10-24 03:48:54 <gmaxwell> PRab: they're pulled into master by those who can according to informally specified behavior which is satisfactory to all the committers.
228 2013-10-24 03:49:12 <super3> my new pull: https://github.com/bitcoin/bitcoin/pull/3138
229 2013-10-24 03:49:57 <super3> just cutting out some unneeded stuff since I want to add more to that file later
230 2013-10-24 03:49:59 <PRab> gmaxwell: Ok, I was guessing that there needed to be a certain number of "acks" before it got pulled.
231 2013-10-24 03:50:35 <PRab> I see some changes get merged faster than I would expect and other seem to linger for a very long time.
232 2013-10-24 03:50:59 <gmaxwell> PRab: no, we normally like to see that (acks are positive confirmation of some level of review), and like to see more on trickier things. But there isn't a bright line requirement.
233 2013-10-24 03:51:16 <PRab> Fair enough.
234 2013-10-24 03:51:26 <gmaxwell> PRab: generally the timing of most things is not surprising to me. It depends a lot on how hard the change is to review.
235 2013-10-24 03:51:53 <gmaxwell> So simple stuff often goes in fastâ unless it seems pointless, because it takes no review effort.
236 2013-10-24 03:53:16 <super3> PRab: when you start off try to keep it small, also it might take a day or two get people to look at it
237 2013-10-24 03:53:30 <super3> they are way faster now than they were with pulls
238 2013-10-24 03:54:25 <PRab> I guess specifically, I am surprised that your change https://github.com/bitcoin/bitcoin/pull/2945 got pulled without any explicit "acks".
239 2013-10-24 03:55:17 <PRab> Personally I really like the concept of the change, but don't have enough experience on the code itself to comment.
240 2013-10-24 03:56:21 <PRab> It seemed to float for about a month, my guess was that it was to controversial, then just got merged.
241 2013-10-24 04:01:26 <jegz> holy shit