1 2014-06-06 00:05:29 <cfields> sipa: PASS: test/test_bitcoin
  2 2014-06-06 00:05:41 <cfields> looks like your rebase held up
  3 2014-06-06 00:06:09 <cfields> sipa: want me to pull that into my branch?
  4 2014-06-06 00:17:00 <sipa> cfields: go ahead
  5 2014-06-06 00:17:50 <cfields> ok. will get it cleaned up and pushed out tomorrow. thanks for the quick rebase
  6 2014-06-06 04:39:06 <petertodd> ooh! I found another varient of the OP_RETURN bug! so in early bitcoin the scriptSig and scriptPubKey were concatenated bytewise, rather than as opcodes, which meant the scriptSig could end with a PUSHDATA opcode that encompassed all or part of the scriptPubKey. if all in most cases you could trivially return true. then as is now there's nothing that actually checks that either scriptSig or scriptPubKey is well formed except EvalScript()
  7 2014-06-06 04:40:53 <petertodd> 
ACTION wonders if LukeJr's CHECKHASHVERIFY made that same mistake...

  8 2014-06-06 04:46:49 <petertodd> ...and no, too bad
  9 2014-06-06 04:49:03 <Belxjander> Heya petertodd
 10 2014-06-06 04:49:09 <petertodd> hi
 11 2014-06-06 04:56:46 <jgarzik> petertodd, yet another data point in favor of my desire to make sure scripts are well formed.  Sadly, byte-wise is what OP_IF and friends want
 12 2014-06-06 04:58:10 <justanotheruser> petertodd: what are the arguments for BIP16 over 17?
 13 2014-06-06 04:59:45 <petertodd> jgarzik: what do you mean by "what OP_IF and friends want"? pushdata's are evaluated inside unevaluated OP_IF branches; a >520byte pushdata in such a branch makes the whole script invalid
 14 2014-06-06 05:02:28 <petertodd> justanotheruser: bip16 was argued to be dead simple, bip17 would have avoided some nasty limits, like the 520byte redeemscript limit, and could have let you specify multiple possible redeemscripts
 15 2014-06-06 05:04:04 <justanotheruser> petertodd: dead simple to interact with right? Implementation ignored
 16 2014-06-06 05:04:58 <petertodd> justanotheruser: both are dead simple to use for applications
 17 2014-06-06 05:05:26 <petertodd> justanotheruser: however P2SH has some nasty limitations if you want to do more complex stuff; IMO we should have spent the extra time to implement OP_EVAL
 18 2014-06-06 05:05:57 <justanotheruser> petertodd: that would be a softfork right?
 19 2014-06-06 05:06:00 <petertodd> yup
 20 2014-06-06 05:06:16 <justanotheruser> petertodd: replacing an OP_NOC?P
 21 2014-06-06 05:06:20 <justanotheruser> *NOP?
 22 2014-06-06 05:06:23 <petertodd> justanotheruser: yup
 23 2014-06-06 05:06:44 <justanotheruser> petertodd: hmm, some #bitcoin users were trying to convince me all new opcodes would be hardforks
 24 2014-06-06 05:07:12 <justanotheruser> but I was under the impression that it could be made to it evaluated to true on new clients
 25 2014-06-06 05:07:15 <justanotheruser> *old clients
 26 2014-06-06 05:07:16 <petertodd> they're dead wrong, in fact it's surprisingly hard to come up with ideas that *can't* be implemented as a softfork
 27 2014-06-06 05:08:02 <justanotheruser> petertodd: would new opcodes have to put true on the top of the stack after they did whatever new stuff they did?
 28 2014-06-06 05:08:36 <petertodd> justanotheruser: they have to act like NOP's, that is, don't touch the stack at all. However you can implement OP_EVAL_ENTIRELY_NEW_SCRIPTING_LANGUAGE instead
 29 2014-06-06 05:10:03 <justanotheruser> petertodd: like <relevant data> <relevant data> <relevant data> <true> OP_EVAL_IGNORE_THE_TRUE_BUT_DO_SOMETHING_WITH_RELEVANT_DATA?
 30 2014-06-06 05:10:37 <petertodd> yup
 31 2014-06-06 05:11:18 <justanotheruser> makes sense
 32 2014-06-06 05:11:46 <Luke-Jr> petertodd: you know, OP_EVAL was actually implemented and merged before P2SH came around.. :p
 33 2014-06-06 05:12:31 <petertodd> Luke-Jr: yes I know, then it got yanked prior to the "turn-on" date
 34 2014-06-06 05:12:39 <petertodd> writing the code is the easiest part of implementing a soft-fork :)
 35 2014-06-06 05:15:44 <SomeoneWeird> wo
 36 2014-06-06 05:15:45 <SomeoneWeird> a
 37 2014-06-06 05:31:04 <justanotheruser> Weird questions. Merkle trees need to be be balanced for a block to be valid right?
 38 2014-06-06 07:14:54 <maaku> justanotheruser: question doesn't make sense
 39 2014-06-06 07:15:29 <michagogo> justanotheruser: huh?
 40 2014-06-06 07:15:57 <justanotheruser> h(tx1, h(tx2, h(tx3)))
 41 2014-06-06 07:16:01 <michagogo> In the merkle trees, if any step has an odd number of elements, you hash the odd element out with itself
 42 2014-06-06 07:16:10 <justanotheruser> oh...
 43 2014-06-06 07:16:32 <justanotheruser> I thought it was just hashed with the hash of its brother node
 44 2014-06-06 07:16:42 <justanotheruser> which might have children
 45 2014-06-06 07:17:12 <maaku> merkle trees in general can be arbitrarily complex
 46 2014-06-06 07:17:20 <maaku> merkle trees as used in bitcoin are really merkle lists
 47 2014-06-06 07:17:27 <maaku> there is no concept of an unbalanced tree
 48 2014-06-06 07:17:36 <maaku> all transactions are at the same depth
 49 2014-06-06 07:17:42 <michagogo> So if you have 3 transactions, their root is H(H(H(TX1)|H(TX2))|H(H(TX3)|H(TX3)))
 50 2014-06-06 07:17:46 <michagogo> (I think)
 51 2014-06-06 07:25:51 <justanotheruser> michagogo: oh I see. Makes sense
 52 2014-06-06 07:25:58 <justanotheruser> thanks maaku too
 53 2014-06-06 07:41:10 <shadowbroker> is there a summary of the bitcoin core roadmap i can read?
 54 2014-06-06 07:41:17 <shadowbroker> or does such a thing even exist? lol
 55 2014-06-06 07:45:41 <wumpus> shadowbroker: closest would be looking at the unmerged pulls on github
 56 2014-06-06 07:46:04 <shadowbroker> heh i thought that might be the case
 57 2014-06-06 07:46:10 <shadowbroker> it just seems that there would be a more...
 58 2014-06-06 07:46:16 <shadowbroker> coordinated effort? lol
 59 2014-06-06 07:46:33 <wumpus> I'm sure there is, in the minds of the people that contribute
 60 2014-06-06 07:47:06 <wumpus> I mean you could do a mailing list post "what are you working on or intend to work on"
 61 2014-06-06 07:47:46 <shadowbroker> people still use mailing lists? jeez
 62 2014-06-06 07:49:42 <wumpus> everyone serious about bitcoin development should at least follow the bitcoin development list
 63 2014-06-06 07:49:52 <wumpus> long-term proposals are posted there, too
 64 2014-06-06 07:50:34 <shadowbroker> link please?
 65 2014-06-06 07:51:31 <Jouke> people still use irc?
 66 2014-06-06 07:51:49 <maaku> shadowbroker: this isn't the type of project that has a roadmap
 67 2014-06-06 07:51:54 <dsnrk> shadowbroker: http://lmgtfy.com/?q=bitcoin+mailing+list&l=1
 68 2014-06-06 07:52:47 <wumpus> if you want to browse the archives, http://dir.gmane.org/gmane.comp.bitcoin.devel  is more convenient than the sourceforge interface
 69 2014-06-06 10:07:02 <gdm85> devrandom: it turns out SendEnv= doesn't really do what it advertizes. see also https://bugzilla.mindrot.org/show_bug.cgi?id=1285
 70 2014-06-06 10:24:22 <gdm85> for now in those docker container templates I maintain I unset the LC_* variables in .bash_profile, it's the easiest workaround for newbies
 71 2014-06-06 10:46:24 <Hasimir> decisions, decisions ... do I try 0.9.2rc1 or not?  Guys, how flakey is this thing compared to 0.9.1?
 72 2014-06-06 10:47:25 <sipa> what do you plan to use it for?
 73 2014-06-06 10:48:18 <Hasimir> well, I was going to see how it went with my little linux vm setup ...
 74 2014-06-06 10:48:43 <Hasimir> but with a question like that, my guess is the answer is don't use it near a live wallet ...
 75 2014-06-06 10:49:54 <sipa> testnet is fine :)
 76 2014-06-06 10:50:45 <Hasimir> ah-ha, does it whinge if there's another active qt instance running at the same time?
 77 2014-06-06 10:51:11 <sipa> if you want to run two bitcoind/bitcoin-qt's, they need a separate p2p port, separate rpc port, separate datadir
 78 2014-06-06 10:51:56 <Hasimir> separate datadir ... yes, that's the catch I overlooked, the rest is all default config
 79 2014-06-06 10:52:09 <Hasimir> ok, I'll play with it later.
 80 2014-06-06 11:27:49 <gdm85> devrandom: also another improvement I added is that I verify md5 hashes of the downloaded source inputs before calling any gbuild
 81 2014-06-06 11:28:38 <gdm85> wumpus: also in your guide: in theory a MiTM'ed input file could do something nasty during the build process..like overriding PATH. thus I think it's a good improvement
 82 2014-06-06 11:28:54 <gdm85> (but again: probably in the domain of gitian-builder)
 83 2014-06-06 11:29:57 <Hasimir> gdm85, why md5 and not one of the sha variants?
 84 2014-06-06 11:30:10 <Hasimir> surely that's not all there is ...
 85 2014-06-06 11:30:41 <gdm85> Hasimir: indeed. but this is just a first approach, improvements can be done. for example I'd go for 2 hashes (md5sum + sha256sum)  TBH
 86 2014-06-06 11:31:06 <gdm85> but the problem is that whatever approach, is better to implement it in gitian-builder
 87 2014-06-06 11:31:18 <Hasimir> not paranoid enough, I'd go for sha256+ and gpg sig checking
 88 2014-06-06 11:31:26 <sipa> md5 is still preimage secure
 89 2014-06-06 11:32:07 <gdm85> Hasimir: no. you are validating that no MiTM sources are being used for the gbuild. you are validating *who* has built the same only at the end, last stage (gsign)
 90 2014-06-06 11:34:53 <Hasimir> 
ACTION sighs ...

 91 2014-06-06 11:38:12 <gdm85> aside from the deterministic VM security, it also prevents you from waiting the whole time of compiling before knowing you had wrong sources
 92 2014-06-06 11:39:26 <azariah4> what's a good source/example of how to get ElGamal key components from a EC key?
 93 2014-06-06 11:40:58 <sipa> the EC public key is the public key, and the EC private key is the private key...
 94 2014-06-06 11:41:12 <sipa> (assuming you mean EC ElGamal, which i don't know how much is used)
 95 2014-06-06 11:43:23 <azariah4> hmm, right. what I want to try is to get a pycrypto ElGamal key object from a bitcoin EC key: https://www.dlitz.net/software/pycrypto/api/current/Crypto.PublicKey.ElGamal-module.html
 96 2014-06-06 11:44:05 <sipa> that doesn't look like it's EC ElGamal, so it's not over the same group
 97 2014-06-06 11:44:07 <sipa> that won't work
 98 2014-06-06 11:44:39 <sipa> well, you can convert the key of course, but it won't have any advantage over any other piece of secret data
 99 2014-06-06 11:44:48 <sipa> in particular, you won't be able to use the bitcoin public key to verify
100 2014-06-06 11:46:37 <azariah4> the use case is asym enc of a message with a bitcoin pubkey; after googling ElGamal seems like a good choice
101 2014-06-06 11:47:25 <azariah4> for the particular case I can't use ECIES as there is only a single pubkey, not two keypairs
102 2014-06-06 11:48:00 <sipa> that won't work
103 2014-06-06 11:48:13 <sipa> and uh, ECIES only needs a single public key
104 2014-06-06 11:49:16 <sipa> the other key is ephemeral, generated at encryption time
105 2014-06-06 11:49:53 <azariah4> oh :O
106 2014-06-06 11:50:17 <azariah4> I thought ECIES needed one privkey and one pubkey to generate the shared secret which then is used to derive the enc key?
107 2014-06-06 11:56:23 <azariah4> ah, hmm. so given bob's EC key (d,Q), one can generate a ephemeral key (d2, Q2) and get the secret d2*Q, derive a key from it, encrypt message m with it to get ciphertext c
108 2014-06-06 11:56:46 <azariah4> then publich c and Q2, so bob can later decrypt using d*Q2 to derive the secret key?
109 2014-06-06 13:02:50 <wumpus> gdm85: the gitian descriptors verify all the inputs
110 2014-06-06 13:03:20 <gdm85> wumpus: ah, didn't notice this
111 2014-06-06 13:03:21 <wumpus> gdm85: it's not needed to check them at download (though that can be added if you download them using a script, of course)
112 2014-06-06 13:03:36 <gdm85> yes I added it that way
113 2014-06-06 13:32:13 <dgenr8> wumpus: thank you for that gmane link
114 2014-06-06 13:48:42 <michagogo> 13:51:23 <sipa> if you want to run two bitcoind/bitcoin-qt's, they need a separate p2p port, separate rpc port, separate datadir <--Well, not strictly true
115 2014-06-06 13:48:53 <michagogo> Separate datadir, yes.
116 2014-06-06 13:49:15 <michagogo> But you don't need a separate p2p port if one of them isn't listening
117 2014-06-06 13:49:42 <michagogo> And you don't need a separate rpc port if one of them is server=0
118 2014-06-06 13:49:54 <michagogo> (Can bitcoind do server=0?)
119 2014-06-06 13:50:28 <michagogo> I know someone talked about making it able to do that at some point, don't remember if it actually happened
120 2014-06-06 14:46:37 <gavinandresen> jgarzik wumpus sipa: if pull-tester is happy I’m going to pull the smartfee changes. I’m tired of rebasing them, and they’ve been ready for weeks.
121 2014-06-06 14:48:04 <jgarzik> gavinandresen, PR#?
122 2014-06-06 14:48:24 <gavinandresen> jgarzik: 3959
123 2014-06-06 14:48:42 <gavinandresen> jgarzik: and 4250
124 2014-06-06 14:56:04 <wumpus> gavinandresen: ack on 3959 at least, I think all remarks (such as storing the mempool) have been solved
125 2014-06-06 14:56:57 <gavinandresen> great. I’m rebasing 4250 right now (and writing release notes to go along with it)
126 2014-06-06 15:02:15 <cfields> sipa: https://github.com/theuni/bitcoin/tree/secp256k1-integration
127 2014-06-06 15:03:41 <cfields> sipa: I've still got some testing to do, making sure it plays nice with the cross-builds. But afaik if it doesn't, it'll be a bug in libsecp256k1 that we'll address there.
128 2014-06-06 15:09:32 <t7> will the deconstructor ever get called if its a static variable?
129 2014-06-06 15:10:41 <wumpus> michagogo: yes, that's possible
130 2014-06-06 15:10:57 <wumpus> t7: when the program exits
131 2014-06-06 15:11:34 <t7> oh wow
132 2014-06-06 15:12:28 <t7> deconstructor = destructor
133 2014-06-06 15:12:54 <gavinandresen> hearn (et al): I’m in the middle of setting up a web page to track fees over time: http://bitcoincore.org/smartfee/
134 2014-06-06 15:13:07 <hearn> cool
135 2014-06-06 15:13:19 <gavinandresen> bitcoind (without a wallet) is running on bitcoincore, re-indexing the blockchain.....
136 2014-06-06 15:13:20 <hearn> i tried the 0.9 fee level the other day, wrote a program to measure confirmation time
137 2014-06-06 15:13:58 <hearn> it took quite a long time. seems most miners didn't upgrade. though from polling one of them (slush) the reason seemed more to be "if it ain't broke don't fix it" rather than any well planned out fee maximisation strategy
138 2014-06-06 15:14:02 <hearn> 0.9 was not a big release for miners
139 2014-06-06 15:14:28 <gavinandresen> 0.9.2 has a DoS fix that they should get.
140 2014-06-06 15:15:44 <gavinandresen> hearn: any brilliant insights on how SPV clients can get smarter about fees?
141 2014-06-06 15:16:10 <hearn> i was thinking a two step plan
142 2014-06-06 15:16:14 <hearn> first step, just poll and average
143 2014-06-06 15:17:03 <gavinandresen> poll meaning new “tell me about fees” network messages (and maybe service bit)?
144 2014-06-06 15:17:21 <hearn> second step, spv wallets remember bloom filter false positives and track them over time, to measure how fast they confirm. this is hard though because it requires the remote node to be able to tell you what the input values were for a now spent transaction
145 2014-06-06 15:17:26 <hearn> which is not currently recorded anywhere
146 2014-06-06 15:17:28 <cfields> wumpus: do you have some conflicting arm/x86 databases you could share with me to save me the trouble (re #2293)? That's my kind of bug :)
147 2014-06-06 15:17:46 <hearn> yes exactly a getfees message. no service bits please.
148 2014-06-06 15:18:36 <hearn> bitcoinj can't use them as it relies on DNS seeds and that is unlikely to change any time soon due to the general churn rate in the network making it hard to bootstrap quickly using just remembered sets of IPs.
149 2014-06-06 15:18:47 <hearn> we'd have to solve the decentralised bootstrap problem first
150 2014-06-06 15:19:19 <hearn> anyway all nodes with a mempool and watching the block chain should be calculating floating fees
151 2014-06-06 15:19:23 <hearn> it doesn't take much
152 2014-06-06 15:20:45 <petertodd> hearn: if you're going to rely on centralized DNS seeds anyway, why aren't you just running some fee calculating servers that implement an algorithm you control in a trusted way?
153 2014-06-06 15:20:58 <hearn> the other complication with the second step is that currently input values would be unauthenticated. so it'd require etothepi's suggested change to include input value along with script in the signature calculation
154 2014-06-06 15:22:02 <hearn> because decentralisation is a journey, petertodd. write more code and you'll understand that. i'm hoping someone smart will figure out a way we can have our cake and eat it, at which point, we can drop it in and benefit. until then making things as decentralised as possible but no more so is the way forward
155 2014-06-06 15:22:25 <petertodd> hearn: that requires wallet software to upgrade; you'd easily take two years to implement that on a big # of the tx volume
156 2014-06-06 15:22:47 <hearn> what does? putting value in sighash?
157 2014-06-06 15:23:14 <petertodd> yes, lots and lots of users aren't going to touch critical tx creation code if they don't have to
158 2014-06-06 15:23:57 <gavinandresen> ummm, lots and lots of transactions come from SPV wallets
159 2014-06-06 15:24:08 <hearn> yes, though it's not a difficult change. the false positives collected to measure fee levels would have to be filtered to be v2 transactions, i.e. it might have to overcollect for a while
160 2014-06-06 15:24:10 <gavinandresen> … which have a clear incentive to upgrade if it means better fee estimation
161 2014-06-06 15:24:27 <cfields> gavinandresen: while you're rebasing and switching around branches, could you please verify that #3070 is fixed as of this morning?
162 2014-06-06 15:24:38 <cfields> gavinandresen: clicky: https://github.com/bitcoin/bitcoin/issues/3070
163 2014-06-06 15:25:27 <gavinandresen> cfields: I’ll check…
164 2014-06-06 15:25:27 <hearn> but "step 2" is a bigger project. to get authenticated value amounts is a forking change, for example. and we need to figure out a database structure that would allow the node to attach values to the input fields.
165 2014-06-06 15:25:47 <petertodd> gavinandresen: my point is there do exist other proposals that authenticate value amounts without sighash hacks
166 2014-06-06 15:25:54 <hearn> or maybe v2 transactions actually duplicate the value amount in their data structure. i guess satoshi didn't do that for simplicity and to reduce byte size
167 2014-06-06 15:26:01 <cfields> thanks
168 2014-06-06 15:26:04 <gavinandresen> petertodd: links?
169 2014-06-06 15:26:19 <hearn> however if there's a good enough reason we could always adjust the serialization format of v2 to include them
170 2014-06-06 15:26:53 <petertodd> gavinandresen: UTXO/TXO commitment proposals do that
171 2014-06-06 15:27:23 <hearn> i don't see how it helps. are nodes expected to keep every UTXO tree for every block?
172 2014-06-06 15:27:37 <gavinandresen> petertodd: links?
173 2014-06-06 15:27:37 <wumpus> cfields: nah, no need, I'm already working on it
174 2014-06-06 15:28:04 <gavinandresen> petertodd: last I asked, there was no consensus on WHICH UTXO/TXO commitment proposal was best
175 2014-06-06 15:28:10 <hearn> the step2 idea is: SPV node connects, syncs to the chain, once it's caught up it asks for a filtered mempool. false positives are stored to disk
176 2014-06-06 15:28:37 <hearn> next time it connects it catches up with the chain again, this time finding where they confirmed
177 2014-06-06 15:28:44 <hearn> oh, actually, thinking about it, maybe there's no need for db adjustments
178 2014-06-06 15:29:26 <hearn> the getutxo patch i have written for lighthouse is enough: you get the mempool FPs, request the relevant UTXOs and if we have hard forked to include the value in the sighash, that proves the fee on those txns
179 2014-06-06 15:29:28 <hearn> then you wait until they confirm
180 2014-06-06 15:30:28 <petertodd> gavinandresen: no there isn't, although per-block TXO indexes is relatively uncontroversial
181 2014-06-06 15:30:34 <hearn> in step1.5 the fee values can be unauthenticated. it's still laying the groundwork for full trustlessness: the protocol would be the same, until the txv2 upgrade at which point the remote nodes UTXO answers can be authenticated
182 2014-06-06 15:31:17 <hearn> gavinandresen: i talked with maaku at the conference a bit. the main question mark is cost:  he is claiming a 20% performance hit. i find it difficult to judge the value of these UTXO commitment proposals, so am not sure if that's worth it or not
183 2014-06-06 15:32:41 <petertodd> hearn: what's the alternative to UTXO/TXO commitments if you want authenticated SPV?
184 2014-06-06 15:33:02 <hearn> authenticated in what sense
185 2014-06-06 15:33:09 <hearn> you mean for mempool transactions?
186 2014-06-06 15:33:14 <petertodd> no, for blockchain data
187 2014-06-06 15:33:20 <cfields> gdm85: around?
188 2014-06-06 15:33:26 <gdm85> cfields: yep
189 2014-06-06 15:33:34 <petertodd> authenticating mempool transactions is obviously impossible at one level
190 2014-06-06 15:33:38 <cfields> gdm85: quick chat in #bitcoin-build ?
191 2014-06-06 15:33:42 <gdm85> k
192 2014-06-06 15:35:20 <hearn> i guess i've forgotten how that is supposed to work. perhaps someone should fork bitcoinj and make it implement these protocols, then it'd be easier to judge the tradeoffs involved.
193 2014-06-06 15:37:42 <petertodd> Well, with a miner TXO index commitment miners would build a per-block binary radix tree of every txout indexed by H(scriptPubKey), then SPV clients would query servers by prefix and block and be given proofs from that tree that their queries had been answered honestly and nothing was being hidden from them. Solves the problem that bloom filters are unauthenticated.
194 2014-06-06 15:38:30 <hearn> ah right, you mean to avoid lying-by-omission in filter queries
195 2014-06-06 15:38:42 <petertodd> yup
196 2014-06-06 15:39:24 <hearn> i like the idea in the abstract but as it's not a problem that's been observed, nor is it obvious what such an attack buys the remote nodes, i like it but not at any cost. the cost on the server side is critical. i guess maaku will show up with a deeper analysis at some point
197 2014-06-06 15:40:38 <hearn> gavinandresen: so what are your thoughts on the incremental spv smartfees path?
198 2014-06-06 15:41:26 <gavinandresen> hearn: seems reasonable.
199 2014-06-06 15:43:04 <petertodd> hearn: there's a very large class set of protocols for which that kind of attack is worth pulling off
200 2014-06-06 15:44:50 <gavinandresen> hearn:  maybe a step zero is to just update hard-coded fees in new releases, based on http://bitcoincore.org/smartfee/ ….
201 2014-06-06 15:45:20 <hearn> gavinandresen: is it really so hard to add a getfees message? it should be about 100 lines of code i'd hope. plus a small BIP.
202 2014-06-06 15:45:54 <gavinandresen> no, not hard.  Speaking of small BIPs, I still have writing up the ‘reject’ message on my TODO
203 2014-06-06 15:45:56 <hearn> but sure
204 2014-06-06 15:46:16 <hearn> as long as fees are relatively stable, we can do hard-coded updates until querying is moved into the protocol
205 2014-06-06 15:46:27 <petertodd> there's no reason to add more unauthenticated features to the protocol for clients that depend on central servers anyway...
206 2014-06-06 15:47:09 <hearn> gavinandresen: and i still have to plumb it through to the API instead of just logging it :)
207 2014-06-06 15:47:14 <hearn> so much to do, so much to do ....
208 2014-06-06 15:51:39 <hearn> the good news is there's been a step-change in the number of contributions i'm getting. averaging multiple pull requests per day, at the moment
209 2014-06-06 15:52:24 <hearn> so hopefully someone else will implement getfees and stuff :)
210 2014-06-06 15:54:11 <sipa> gavinandresen, hearn: i dont think the spv querying problem for fees is worse than it querying for exchange rates
211 2014-06-06 15:55:14 <gavinandresen> sipa: good point
212 2014-06-06 15:56:07 <hearn> worse in what sense?
213 2014-06-06 15:56:29 <gavinandresen> If you’re querying one or more exchange servers to show the user “you’re sending $11” … querying one or more ‘give me fee estimates’ servers makes sense
214 2014-06-06 15:57:09 <hearn> and what's wrong with querying the 8000 servers that are already calculating it?
215 2014-06-06 15:57:26 <gmaxwell> Because they're all the same server, giving you a cooked result. :)
216 2014-06-06 15:57:54 <gmaxwell> would be pretty reasonable to ask exchange data sources to also provide fee suggestions, perhaps?
217 2014-06-06 15:58:19 <hearn> but i can't meaningfully verify the identities and ownerships and independence of more than say, two or three servers. and even that takes ongoing effort. i'd rather solve the "bad internet connection" problem by just using Tor, the work for which is mostly already done
218 2014-06-06 15:58:38 <hearn> for exchange rates, there isn't much choice because exchange rates are all calculated based on centralised services already
219 2014-06-06 16:04:21 <petertodd> in any case, worth reminding people that with replace-by-fee you can afford to bias your initial fee estimates on the low side and bump them as needed - much less need for hour to hour estimates anyway. additionally estimates by definition can't see into the future, unless gavin was onto something with that satoshi costume...
220 2014-06-06 16:04:45 <hearn> http://research.microsoft.com/apps/pubs/default.aspx?id=217984
221 2014-06-06 16:05:21 <petertodd> permacoin + tree chains is a very interesting, and scalable, model
222 2014-06-06 16:06:36 <hearn> gmaxwell:
223 2014-06-06 16:06:38 <hearn> oops
224 2014-06-06 17:33:37 <wumpus> I'm going to tag 0.9.2rc2 with #4282 (cwallet init fix) #4295 (upgrade OpenSSL to 1.0.1h) #4261 (Use pnode->nLastRecv as sync score directly) and translation update
225 2014-06-06 17:33:55 <gmaxwell> wumpus: ack
226 2014-06-06 17:35:58 <gavinandresen> wumpus: ack
227 2014-06-06 17:38:46 <wumpus> ok
228 2014-06-06 17:39:22 <wumpus>  * [new tag]         v0.9.2rc2 -> v0.9.2rc2
229 2014-06-06 17:40:25 <torokun> can someone give me a basic idea or link to info about how the network operates?  e.g. how a node connects to a first node, what verification there is, how data is exchanged...
230 2014-06-06 17:40:35 <Luke-Jr> torokun: #bitcoin
231 2014-06-06 17:40:47 <torokun> i mean in the code
232 2014-06-06 17:40:55 <torokun> e.g., is a first node hard coded?
233 2014-06-06 17:41:03 <torokun> how does the networking protocol work
234 2014-06-06 17:42:31 <justanotheruser> torokun: ,,(bc,wiki node discovery)