1 2014-10-11 00:01:55 <earlz> So, does the RPC interface for bitcore actually work in the browser? Documentation appears to say so, but I can't get it to make more than a single OPTIONS request
  2 2014-10-11 00:02:26 <earlz> https://github.com/bitpay/bitcore/issues/537
  3 2014-10-11 00:25:46 <lechuga_> earlz: there is #bitcore
  4 2014-10-11 00:26:30 <lechuga_> also the OPTIONS command is hitting 127.0.0.1:8332
  5 2014-10-11 00:27:09 <lechuga_> is 18332 intended?
  6 2014-10-11 00:28:24 <earlz> no
  7 2014-10-11 00:28:36 <earlz> I changed that in the code
  8 2014-10-11 00:29:58 <lechuga_> ?
  9 2014-10-11 00:59:04 <ruukasu> Luke-Jr: /go #theanimeclub
 10 2014-10-11 00:59:06 <ruukasu> fuc
 11 2014-10-11 00:59:09 <ruukasu> sorry
 12 2014-10-11 00:59:20 <ruukasu> how humiliating
 13 2014-10-11 01:00:04 <Adlai> "awkward" is only true once said out loud
 14 2014-10-11 01:00:44 <sipa> ?
 15 2014-10-11 01:01:29 <lechuga_> if ur going 2 troll at least have it make sense
 16 2014-10-11 02:43:18 <earlz> Why is getrawtransaction/vout/scriptPubKey/addresses an array?
 17 2014-10-11 02:43:43 <earlz> Can that be more than 1 for multisig?
 18 2014-10-11 02:44:56 <phantomcircuit> earlz, right
 19 2014-10-11 02:46:34 <earlz> ugh breaking my block explorer :(
 20 2014-10-11 02:48:52 <phantomcircuit> bad assumptions
 21 2014-10-11 02:48:55 <phantomcircuit> are bad
 22 2014-10-11 03:00:28 <CodeShark> the whole "address" thing was a bad idea from the start :p
 23 2014-10-11 03:01:01 <lechuga_> why
 24 2014-10-11 03:01:17 <CodeShark> an "address" is actually a specific encoding for a special type of script
 25 2014-10-11 03:01:21 <Rozal> I would like the developers to know this: https://m.youtube.com/watch?v=SmHeP9Sve48#
 26 2014-10-11 03:01:49 <lechuga_> sure so if a script matches the hash160 template is it not reaosnable to display the base58 encoded address
 27 2014-10-11 03:02:02 <CodeShark> a "bitcoin address" has little in common with post offices
 28 2014-10-11 03:02:44 <firelegend> CodeShark:What would you have replaced addresses with?
 29 2014-10-11 03:02:45 <CodeShark> "invoice script" is a far less confusing term - or "invoice id" if we don't want to get too technical
 30 2014-10-11 03:03:26 <firelegend> CodeShark:Mashing the keyboard and hoping the right person receives the bitcoins doesnt sound better to me.
 31 2014-10-11 03:03:53 <CodeShark> but the use model is significantly different from the way people are used to using "addresses"
 32 2014-10-11 03:04:19 <firelegend> not everybody needs to know how bitcoin works to use it
 33 2014-10-11 03:04:29 <lechuga_> hopefully not
 34 2014-10-11 03:04:30 <CodeShark> right - but there's no need to confuse them even more
 35 2014-10-11 03:05:28 <CodeShark> and the terminology isn't the only problem with the whole "bitcoin address" thing.
 36 2014-10-11 03:05:54 <lechuga_> ?
 37 2014-10-11 03:06:38 <CodeShark> there are also some technical issues - an "address" is a specific encoding for a datafield that comprises nearly the entire output script. So we gain very little by only encoding that datafield rather than just using the entire script
 38 2014-10-11 03:06:49 <CodeShark> and we lose generality
 39 2014-10-11 03:07:10 <firelegend> you are worrying over nothing
 40 2014-10-11 03:07:26 <firelegend> you should worry that the air inside your room doesnt gather in one corner :D
 41 2014-10-11 03:07:35 <CodeShark> it means implementations now need to have special cases to deal with different "address" types
 42 2014-10-11 03:07:48 <CodeShark> more special cases -> greater complexity -> more error-prone
 43 2014-10-11 03:07:54 <CodeShark> uglier code
 44 2014-10-11 03:07:56 <CodeShark> and harder to maintain code
 45 2014-10-11 03:08:54 <CodeShark> in retrospect, only supporting p2sh would have probably been a good idea…but we can only really say this with the benefit of hindsight
 46 2014-10-11 03:09:24 <CodeShark> p2sh preserves script generality while maintaining a consistent payment request format
 47 2014-10-11 03:12:55 <Luke-Jr> [03:01:52] <lechuga_> sure so if a script matches the hash160 template is it not reaosnable to display the base58 encoded address <-- display, yes. equate, no. equate to the scriptSig spending it, HECK NO.
 48 2014-10-11 03:12:57 <lechuga_> yeah it would've been nice if it were realized first
 49 2014-10-11 03:13:17 <lechuga_> luke-jr: nod
 50 2014-10-11 03:13:30 <Luke-Jr> payment protocol is the best we have today, and it's not really usable
 51 2014-10-11 03:13:55 <lechuga_> not usable how (im aware of shortcomings but curious)
 52 2014-10-11 03:14:55 <Luke-Jr> lechuga_: I have no way to request a payment using the payment protocol, short of setting up a webserver with who knows what PHP scripts and buying a SSL cert for it
 53 2014-10-11 03:15:06 <Luke-Jr> ie, on an individual-to-individual level
 54 2014-10-11 03:15:34 <lechuga_> true
 55 2014-10-11 03:15:38 <lechuga_> not very p2p friendly
 56 2014-10-11 03:16:06 <lechuga_> atm
 57 2014-10-11 03:17:29 <CodeShark> imo, trying to specify the message structures AND the transport layer in a single spec is not the way to go
 58 2014-10-11 03:17:55 <CodeShark> we want flexibility in how requests are transmitted
 59 2014-10-11 03:17:56 <lechuga_> the transport layer isnt explicit except for bip72 right
 60 2014-10-11 03:18:21 <lechuga_> i think it's assumed it wont just be used with https
 61 2014-10-11 03:18:33 <lechuga_> or else why bother embedding x509 in it
 62 2014-10-11 03:20:16 <CodeShark> point is you can define message structures independently of the specific workflows for payment requests. the workflow could be different in different contexts
 63 2014-10-11 03:20:32 <lechuga_> protocol seems transport agnostic 2 me
 64 2014-10-11 03:21:11 <CodeShark> well, even deciding to use protobuf specifically seems too much
 65 2014-10-11 03:21:28 <Luke-Jr> ._.
 66 2014-10-11 03:21:40 <CodeShark> the goal is simply to have a way of issuing a payment request such that the recipient of the request can verify the sender's identity
 67 2014-10-11 03:22:00 <Luke-Jr> which requires an encoding..
 68 2014-10-11 03:24:31 <CodeShark> sure - that's true…but protobuf is designed more for efficient transport than anything else - and it adds another layer of complexity and dependencies to implementations that do not require efficient transport
 69 2014-10-11 03:25:15 <CodeShark> in other words, it's not an encoding that can be easily implemented directly
 70 2014-10-11 03:25:33 <lechuga_> being space efficient allows it to accomodate a larger variety of transport layers
 71 2014-10-11 03:25:54 <CodeShark> the only requirement, as far as the encoding, is that it be unique - so we can sign it
 72 2014-10-11 03:26:20 <CodeShark> the signature verification layer doesn't really care about the transport layer
 73 2014-10-11 03:27:45 <CodeShark> if you want to use protobuf for transport, that's fine - you decode the structure on the other end and put it into a simpler, easier-to-implement encoding to verify the signature
 74 2014-10-11 03:31:43 <CodeShark> main point I'm trying to make is that it adds another hurdle for a developer that isn't dealing directly with networking and brings in more dependencies that are relatively opaque
 75 2014-10-11 03:32:27 <CodeShark> it's just one more thing that makes it harder for people to adopt the payment protocol at the application level
 76 2014-10-11 03:32:57 <lechuga_> what's a more simple alternative to protobufs
 77 2014-10-11 03:33:49 <CodeShark> a nice thing about protobufs that might be relevant is that it does support wide flexibility in datatypes
 78 2014-10-11 03:34:17 <CodeShark> but I'm not sure we need that kind of support for simply verifying the identity of a payment request
 79 2014-10-11 03:35:56 <CodeShark> don't get me wrong - protobufs are really cool. but I think they are an obstacle for many developers who just want to parse and verify some basic data
 80 2014-10-11 03:37:02 <lechuga_> imo if you cant handle protobufs u prob shouldnt be handling payments
 81 2014-10-11 03:37:28 <lechuga_> and they're really simple just new :)
 82 2014-10-11 03:37:33 <CodeShark> we're looking for mass adoption - iron-clad implementations come later :p
 83 2014-10-11 03:38:31 <lechuga_> no1 is going to trust less-than-iron-clad ones
 84 2014-10-11 03:38:49 <lechuga_> and really the masses are going to require trust as much as they shouldn't need to
 85 2014-10-11 03:39:02 <CodeShark> the vast majority of bitcoin applications are far from iron-clad. most are very poorly implemented
 86 2014-10-11 03:40:50 <lechuga_> that's true of most software
 87 2014-10-11 03:41:06 <CodeShark> point is there's relatively little incentive right now for the good developers to invest much in supporting the payment protocol because nobody is really using it
 88 2014-10-11 03:41:24 <lechuga_> it's chicken-and-egg right
 89 2014-10-11 03:41:29 <lechuga_> support needs to exist
 90 2014-10-11 03:42:08 <CodeShark> if you make it simple enough to support so that even the bad developers can sort of use it, it means the good developers will be more willing to build support
 91 2014-10-11 03:42:39 <lechuga_> if you dont use protobufs correctly your messages don't parse
 92 2014-10-11 03:43:02 <lechuga_> doesnt seem catastrophic
 93 2014-10-11 03:43:28 <CodeShark> it effectively eliminates at least 75% of current bitcoin developers :p
 94 2014-10-11 03:43:48 <phantomcircuit> lechuga_, what
 95 2014-10-11 03:43:57 <lechuga_> ?
 96 2014-10-11 03:44:00 <phantomcircuit> protobuf will parse all kinds of nonsense as a valid message
 97 2014-10-11 03:45:03 <CodeShark> the only other sensible approach to mass adoption is to build solid library distributions for the most popular programming languages
 98 2014-10-11 03:45:54 <phantomcircuit> CodeShark, the payment protocols probably is almost entirely with how to specify a return address
 99 2014-10-11 03:46:09 <lechuga_> i disagree
100 2014-10-11 03:46:38 <lechuga_> it's trying to tackel the enumerated list of goals in the bip
101 2014-10-11 03:46:43 <lechuga_> easier to reas/make sense of
102 2014-10-11 03:46:51 <lechuga_> read*
103 2014-10-11 03:47:01 <lechuga_> identity verification
104 2014-10-11 03:47:06 <lechuga_> refund addresses
105 2014-10-11 03:47:13 <lechuga_> explicit payment destinations
106 2014-10-11 03:47:32 <lechuga_> everything necessary such that humans can pay for things wth bitcoin
107 2014-10-11 03:47:35 <phantomcircuit> the only one of those it is helpful for is refund addresses
108 2014-10-11 03:48:05 <phantomcircuit> identity verification only works to the extent that the ca infrastructure works
109 2014-10-11 03:48:11 <phantomcircuit> which is probably a reasonable goal
110 2014-10-11 03:48:13 <lechuga_> u get explicit acknowledgement of your payment
111 2014-10-11 03:48:17 <phantomcircuit> but is still horribly limited
112 2014-10-11 03:48:33 <lechuga_> well mike has mentioned many times that when something more reaosnable comes along to replace CA infrastructure
113 2014-10-11 03:48:39 <lechuga_> the protocol should be extended to accomodate it
114 2014-10-11 03:48:46 <lechuga_> it's currently a best-effort
115 2014-10-11 03:50:00 <phantomcircuit> lechuga_, the payment protocol is currently interactive
116 2014-10-11 03:50:20 <CodeShark> the X509 is an entirely separate issue from what we're discussing…and I won't even pretend to have a good solution for that
117 2014-10-11 03:50:40 <phantomcircuit> refund addresses can be specified with the initial invoice request, but the ack of the payment cannot
118 2014-10-11 03:50:52 <phantomcircuit> except if you have a signed invoice with the address for payment
119 2014-10-11 03:50:59 <phantomcircuit> do you really need a signed receipt?
120 2014-10-11 03:51:15 <CodeShark> the blockchain is your receipt :p
121 2014-10-11 03:51:29 <phantomcircuit> right
122 2014-10-11 03:51:43 <Luke-Jr> phantomcircuit: p2p invoices won't be requested, they'll be sent :/
123 2014-10-11 03:52:14 <phantomcircuit> Luke-Jr, oh you're right
124 2014-10-11 03:52:53 <phantomcircuit> guess you do need 2 way communication to specify a refund address in a p2p context
125 2014-10-11 03:53:03 <phantomcircuit> well in any context actually
126 2014-10-11 03:53:27 <lechuga_> the p2p transport layer is what really interests me
127 2014-10-11 03:54:01 <lechuga_> whatever it ends up being
128 2014-10-11 03:54:27 <Luke-Jr> lechuga_: how can one pay for broadcasting an invoice on the p2p network?
129 2014-10-11 03:54:37 <Luke-Jr> you can't use probabilistic payments I think
130 2014-10-11 03:54:40 <lechuga_> what if it isn't a broadcast
131 2014-10-11 03:54:49 <Luke-Jr> then one of the peers needs their port open
132 2014-10-11 03:55:00 <CodeShark> Luke-Jr: bitmessage? :p
133 2014-10-11 03:55:08 <lechuga_> udp nat traversal assisted by stun
134 2014-10-11 03:55:08 <Luke-Jr> lechuga_: direct p2p is essentially dead :/
135 2014-10-11 03:55:14 <lechuga_> it is certainly not
136 2014-10-11 03:55:21 <Luke-Jr> lechuga_: that's going to have problems randomly
137 2014-10-11 03:55:24 <phantomcircuit> Luke-Jr, if you're buying/selling something from someone, then you almost certainly already have a communication channel that is 2 way
138 2014-10-11 03:55:30 <lechuga_> luke-jr: very seldomly
139 2014-10-11 03:55:32 <Luke-Jr> too many NAT and firewall garbage out there
140 2014-10-11 03:55:37 <lechuga_> the majority of the world is behind restricted cone nat
141 2014-10-11 03:55:59 <CodeShark> phantomcircuit: indeed
142 2014-10-11 03:56:00 <Luke-Jr> phantomcircuit: yes, but how do I know the guy in #Bitcoin-OTC is the one I'm paying?
143 2014-10-11 03:56:51 <Luke-Jr> phantomcircuit: and in person, it'll be a pain to scan each others' QR codes more than once
144 2014-10-11 03:56:59 <phantomcircuit> Luke-Jr, they have a gpg key sign the invoice
145 2014-10-11 03:57:33 <phantomcircuit> .basically
146 2014-10-11 03:58:20 <phantomcircuit> communication/identification/refund address, invoice, receipt format
147 2014-10-11 03:58:27 <phantomcircuit> are each logically separate layers
148 2014-10-11 03:59:43 <CodeShark> right. in principle, a refund address could be agreed upon up front and used for several subsequent transactions
149 2014-10-11 04:00:13 <lechuga_> :o
150 2014-10-11 04:00:35 <CodeShark> not saying it's generally a good idea - but in principle it could be done :p
151 2014-10-11 04:03:34 <Luke-Jr> a HD wallet chain could, at least
152 2014-10-11 04:03:41 <CodeShark> right, that's sorta what I was thinking
153 2014-10-11 04:03:45 <Luke-Jr> as well as for subscriptions
154 2014-10-11 04:04:02 <CodeShark> but there's something to be said for payment requests being stateless
155 2014-10-11 04:04:45 <CodeShark> and in any case, having the sender manage the wallet chain
156 2014-10-11 04:04:51 <CodeShark> is probably more sensible
157 2014-10-11 04:07:12 <CodeShark> anyhow, it seems we're trying to solve too many problems at once - and in the end aren't really solving any
158 2014-10-11 04:07:49 <CodeShark> just solving the problem of the sender being able to securely identify the recipient would already be progress.
159 2014-10-11 04:08:12 <lechuga_> i'd argue right now paying via bip70 is a more pleasant experience than not
160 2014-10-11 04:08:28 <lechuga_> and i'd agree more work is necessary
161 2014-10-11 04:08:32 <Luke-Jr> paying yes, receiving no :p
162 2014-10-11 04:08:36 <lechuga_> :)
163 2014-10-11 04:08:52 <CodeShark> more pleasant for whom? application developers? or end users? :)
164 2014-10-11 04:09:02 <lechuga_> end users aka the masses
165 2014-10-11 04:10:54 <CodeShark> perhaps the payment protocol should be broken up into an invoicing protocol and a refunding protocol
166 2014-10-11 04:11:29 <CodeShark> many applications do not require an automated refunding mechanism
167 2014-10-11 04:11:39 <Luke-Jr> like?
168 2014-10-11 04:12:04 <phantomcircuit> CodeShark, i would advise against that
169 2014-10-11 04:12:13 <Luke-Jr> maybe a refund should be an invoice itself :p
170 2014-10-11 04:12:19 <phantomcircuit> mostly because it's then difficult to forcibly refund people who are ridiculous
171 2014-10-11 04:12:20 <Luke-Jr> same kind of thing really
172 2014-10-11 04:13:16 <CodeShark> Luke-Jr: if only 0.000001% of your transactions result in a refund in practice, you can probably afford to just deal with the exceptional case manually :p
173 2014-10-11 04:13:30 <CodeShark> unless you're talking about HUGE volume
174 2014-10-11 04:14:25 <Luke-Jr> CodeShark: you're forgetting people who do not cooperate in being refunded
175 2014-10-11 04:15:03 <phantomcircuit> CodeShark, and that 0.00000001% will sue you instead of accepting a refund
176 2014-10-11 04:15:20 <phantomcircuit> case in point http://www.coindesk.com/bitcoin-gold-service-faces-class-action-alleged-fraud/
177 2014-10-11 04:17:00 <CodeShark> perhaps it would be simplest from a logical perspective to incorporate refund scripts into the transactions themselves - the downside is extra blockchain fluff
178 2014-10-11 04:18:14 <phantomcircuit> CodeShark, that's been suggested a number of times, and could be done with OP_RETURN
179 2014-10-11 04:18:42 <phantomcircuit> some random 20 byte magic value + 20 bytes of address for the refund
180 2014-10-11 04:18:50 <phantomcircuit> everybody agrees on the magic value and we call it a day
181 2014-10-11 04:19:11 <phantomcircuit> however this has a number of downsides
182 2014-10-11 04:19:16 <phantomcircuit> one it leaks the refund address
183 2014-10-11 04:19:22 <CodeShark> doesn't have to
184 2014-10-11 04:19:37 <phantomcircuit> two it's something which could be external that isn't
185 2014-10-11 04:19:44 <phantomcircuit> so it's wasting space
186 2014-10-11 04:19:55 <CodeShark> in principle you could just store the hash of the refund address in the blockchain
187 2014-10-11 04:19:57 <phantomcircuit> but could be pruned
188 2014-10-11 04:20:22 <CodeShark> and send the actual address in a separate communication
189 2014-10-11 04:20:22 <phantomcircuit> CodeShark, same thing, you're trivially linking the payment with the refund
190 2014-10-11 04:20:33 <CodeShark> point is only the recipient would know this data
191 2014-10-11 04:20:44 <phantomcircuit> no because eventually the address will be on the network
192 2014-10-11 04:21:00 <CodeShark> hmmm, good point
193 2014-10-11 04:21:02 <phantomcircuit> joining all addresses with all refund address hashes would be trivial
194 2014-10-11 04:21:45 <CodeShark> the sender/recipient could also share a secret that's used as part of the hash
195 2014-10-11 04:22:00 <CodeShark> although I'm not sure that simplifies anything
196 2014-10-11 04:22:08 <CodeShark> perhaps that just defeats the whole purpose
197 2014-10-11 04:22:13 <phantomcircuit> yeah it does
198 2014-10-11 04:22:15 <phantomcircuit> :P
199 2014-10-11 04:24:46 <CodeShark> alternatively, the sender could simply provide a signature for the address in the transaction
200 2014-10-11 04:25:24 <CodeShark> using one of the other signing keys, even
201 2014-10-11 04:26:03 <CodeShark> but that does have the fluff downside
202 2014-10-11 04:26:21 <phantomcircuit> CodeShark, requires the person requesting a refund to sign the refund address and send that to the other party
203 2014-10-11 04:26:26 <phantomcircuit> which is what you're already doing
204 2014-10-11 04:26:33 <phantomcircuit> full circle
205 2014-10-11 04:26:38 <CodeShark> yeah - solves nothing
206 2014-10-11 04:27:35 <lightlike> hey guys, i'm playing around with rpc calls to my bitcoind on testnet -- i imported an address/sent BTC with a faucet/verified txn on blockchain/verified that bitcoind has downloaded the block with the txn, but getReceivedByAddress doesn't show any received txns
207 2014-10-11 04:28:40 <lightlike> listReceivedByAddress shows the imported address but shows no txids and zero amount
208 2014-10-11 04:30:32 <lightlike> any ideas?
209 2014-10-11 04:31:36 <lechuga_> is your node fully synced
210 2014-10-11 04:32:03 <lightlike> yeah, when i do getBlock on the block containing the txn it returns the block
211 2014-10-11 04:32:21 <lightlike> and its txn list contains the txn transferring to this address
212 2014-10-11 04:32:34 <lechuga_> what happens if you use bitcoin-cli to get the same information
213 2014-10-11 04:32:53 <phantomcircuit> when you say you imported an address
214 2014-10-11 04:33:01 <phantomcircuit> which exact rpc call did you use
215 2014-10-11 04:33:37 <CodeShark> did you send the transaction from the same wallet?
216 2014-10-11 04:34:41 <lightlike> i used importAddress(address, label)
217 2014-10-11 04:34:50 <lightlike> seems to have been merged from https://github.com/bitcoin/bitcoin/pull/2861
218 2014-10-11 04:35:03 <lightlike> no, I got it from a testnet faucet
219 2014-10-11 04:35:05 <CodeShark> did you rescan the chain?
220 2014-10-11 04:35:17 <lightlike> that may be the problem
221 2014-10-11 04:35:33 <CodeShark> sounds like it
222 2014-10-11 04:37:44 <lightlike> not sure why importAddress isn't in https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
223 2014-10-11 04:38:05 <lightlike> and it looks like the only way to trigger a rescan is to call importPrivKey(privKey, label, true)?
224 2014-10-11 04:38:15 <CodeShark> no, you can rescan at startup
225 2014-10-11 04:38:23 <lightlike> got it
226 2014-10-11 04:38:28 <lightlike> that seems to have worked; thanks!
227 2014-10-11 04:38:32 <CodeShark> :)
228 2014-10-11 04:38:32 <Luke-Jr> passing a bool by reference seems to confuse people? :/
229 2014-10-11 04:39:03 <lechuga_> moreso than passing anything else by reference?
230 2014-10-11 04:39:20 <lechuga_> std:pair ftw
231 2014-10-11 04:39:22 <Luke-Jr> lechuga_: dunno, maybe this guy is just a n00b - although I find it slightly confusing in this case at least
232 2014-10-11 04:40:49 <dcousens> Luke-Jr: I'm used to the C++ style guide
233 2014-10-11 04:40:59 <dcousens> Which is, const references all thew ay
234 2014-10-11 04:41:02 <Luke-Jr> aha, you're here :D
235 2014-10-11 04:41:04 <dcousens> If you mutate, you use a pointer
236 2014-10-11 04:41:18 <Luke-Jr> dcousens: a pointer usually implies NULL is acceptable
237 2014-10-11 04:41:19 <dcousens> Its to avoid confusing cases like this
238 2014-10-11 04:41:39 <CodeShark> Luke-Jr: right - passing by reference means passing NULL is impossible
239 2014-10-11 04:41:39 <dcousens> Luke-Jr: true
240 2014-10-11 04:42:05 <Luke-Jr> it would unnecessarily complicate policy code to make NULL an acceptable reference there
241 2014-10-11 04:42:07 <dcousens> Luke-Jr: honestly a fan of std::pair or tuple tbh haha
242 2014-10-11 04:42:08 <lightlike> when bitcoind receives a block it should look for imported addresses in the block txn outputs though, right?
243 2014-10-11 04:42:22 <Luke-Jr> dcousens: how would you change this to use those? I don't see the use
244 2014-10-11 04:42:42 <CodeShark> lightlike: new blocks, yes - old blocks, at best should be optional
245 2014-10-11 04:42:43 <Luke-Jr> lightlike: yes, but note importing keys is a bad idea in general
246 2014-10-11 04:42:44 <lightlike> the issue might've been that i imported the address after bitcoind received the block
247 2014-10-11 04:43:05 <dcousens> Luke-Jr: well the issue is you're doing two things in that function
248 2014-10-11 04:43:18 <dcousens> You're determining whether a transaction should be accepted into the mempool
249 2014-10-11 04:43:23 <CodeShark> lightlike: in order to locate the transaction bitcoind would have to maintain an address index
250 2014-10-11 04:43:29 <dcousens> And you're also returning information regarding where it should be rate limited
251 2014-10-11 04:43:31 <lightlike> why is that? what's the conventional way to monitor transactions to given addresses?
252 2014-10-11 04:43:45 <lechuga_> yeah
253 2014-10-11 04:43:54 <lechuga_> pointer means i have to handle null
254 2014-10-11 04:43:54 <Luke-Jr> dcousens: hmm, maybe rate limiting should be a value on the CValidationState?
255 2014-10-11 04:44:08 <CodeShark> lightlike: bitcoind's wallet only keeps an index of your wallet addresses
256 2014-10-11 04:44:18 <Luke-Jr> lightlike: watch-only wallets, which nothing really supports reasonably well
257 2014-10-11 04:44:39 <CodeShark> Luke-Jr: that's why I stopped working on that approach
258 2014-10-11 04:44:53 <Luke-Jr> lightlike: also note any given address should only ever receive one transaction
259 2014-10-11 04:44:58 <CodeShark> sipa was still nice enough to add it and merge it :)
260 2014-10-11 04:44:59 <Luke-Jr> CodeShark: ?
261 2014-10-11 04:45:11 <CodeShark> importaddress was originally my pull request :p
262 2014-10-11 04:45:17 <Luke-Jr> CodeShark: oh :/
263 2014-10-11 04:45:33 <dcousens> Luke-Jr: where is CValidationState defined btw?
264 2014-10-11 04:45:49 <Luke-Jr> main.h
265 2014-10-11 04:45:52 <dcousens> cheers
266 2014-10-11 04:45:57 <Luke-Jr> git grep is handy :P
267 2014-10-11 04:46:01 <dcousens> Github search wasn't picking it up
268 2014-10-11 04:46:06 <lightlike> Luke-Jr: what do you mean that nothing really supports watch-only wallets well?
269 2014-10-11 04:46:07 <dcousens> And haven't got the code base handy
270 2014-10-11 04:46:26 <CodeShark> the bitcoind wallet sucks for anything other than the most basic single-user use case
271 2014-10-11 04:46:35 <CodeShark> single-user single device
272 2014-10-11 04:46:52 <CodeShark> it wasn't really designed for anything else
273 2014-10-11 04:47:08 <lightlike> what would you use if you wanted to just monitor a bunch of addresses?
274 2014-10-11 04:47:19 <CodeShark> https://ciphrex.com :)
275 2014-10-11 04:47:36 <CodeShark> although it isn't for monitoring arbitrary addresses
276 2014-10-11 04:48:19 <lightlike> tracking transactions to lots of addresses is really the only thing i need to do
277 2014-10-11 04:48:35 <CodeShark> however, I've pretty much obviated the need to import arbitrary addresses (other than in the special case of blockchain analysis tools)
278 2014-10-11 04:48:51 <Luke-Jr> lightlike: I mean there's no user friendly way to make a watch only wallet today
279 2014-10-11 04:49:37 <Luke-Jr> importaddress will work to a limited extent if you know every single address in question
280 2014-10-11 04:49:48 <lightlike> why to a limited extent?
281 2014-10-11 04:49:51 <Luke-Jr> you'll just have to ignore 'send' transactions which are unrelated to the addresses
282 2014-10-11 04:50:08 <lightlike> these are all addresses i'm controlling
283 2014-10-11 04:50:10 <Luke-Jr> because it is trying to emulate a watch-only wallet with its addresses, so it includes the unrelated 'send' pairs
284 2014-10-11 04:50:53 <lightlike> what are 'send' pairs?
285 2014-10-11 04:51:16 <Luke-Jr> lightlike: the transactions which consume UTXOs created when the address received a payment.
286 2014-10-11 04:51:39 <Luke-Jr> lightlike: ie, they are transactions *leaving* the wallet using that address, but they have nothing to do with the address itself
287 2014-10-11 04:51:48 <lightlike> cool
288 2014-10-11 04:52:07 <dcousens> Luke-Jr: I think CValidationState might be OK, but that class is generalized for blocks and transactions, this would make it more specific to Transactions... depending on what you move into I guess
289 2014-10-11 04:52:22 <Luke-Jr> hm
290 2014-10-11 04:53:27 <Luke-Jr> 
ACTION leaves a comment back on GitHub to see what others think

291 2014-10-11 04:53:58 <midnightmagic> is this still functional? https://github.com/sipa/bitcoin/commits/watchonly
292 2014-10-11 04:55:59 <CodeShark> wow, sipa really put some effort into making this thing actually work :p
293 2014-10-11 04:57:13 <dcousens> CodeShark: "passing by reference means passing NULL is impossible", heh, don't be so sure :P
294 2014-10-11 04:58:06 <CodeShark> dcousens: ok, not impossible
295 2014-10-11 04:59:37 <CodeShark> let's just say it isn't something that would likely be done accidentally
296 2014-10-11 04:59:57 <Luke-Jr> dcousens: oh?
297 2014-10-11 05:00:13 <Luke-Jr> midnightmagic: AFAIK the functionality is in master now
298 2014-10-11 05:00:33 <CodeShark> Luke-Jr: I suppose you could overwrite the call stack :p
299 2014-10-11 05:01:01 <dcousens> CodeShark: haha, or just C-style case a NULL pointer in some obscure way that clang doesn't catch it
300 2014-10-11 05:01:05 <Luke-Jr> CodeShark: sure, but by that logic you can do a lot of crazy things :p
301 2014-10-11 05:01:09 <dcousens> haha
302 2014-10-11 05:01:11 <dcousens> Indeed.
303 2014-10-11 05:01:21 <dcousens> Just saying, impossible is a strong word haha
304 2014-10-11 05:01:24 <Luke-Jr> I meant within the scope of C++
305 2014-10-11 05:01:36 <Luke-Jr> as impossible as changing a private property from outside the object :p
306 2014-10-11 05:02:10 <CodeShark> friend? :p
307 2014-10-11 05:02:47 <Luke-Jr> put another way: I think it would be valid for the compiler to check a NULL value and throw an exception implicitly?
308 2014-10-11 05:04:15 <dcousens> Luke-Jr: you know, if its a pain, I think even a comment to explain that fRateLimit is mutated in that function would be enough
309 2014-10-11 05:04:43 <dcousens> its a code smell, sure, but only in terms of reading/grokking the code quickly
310 2014-10-11 05:05:29 <Luke-Jr> dcousens: good idea
311 2014-10-11 05:21:33 <sipa> cfields: where do i get the osx sdk? the bitcoincore server gives 403
312 2014-10-11 05:23:08 <sipa> or anyone else...?
313 2014-10-11 05:23:16 <bassguitarman> sipa, there’s a github with all the sdks
314 2014-10-11 05:23:38 <bassguitarman> or you can just download xcode
315 2014-10-11 05:23:51 <sipa> i believe it requires some postprocessing which needs osx
316 2014-10-11 05:26:07 <CodeShark> are you trying to build on linux?
317 2014-10-11 05:26:43 <sipa> yes
318 2014-10-11 05:27:11 <CodeShark> I've generally found that Apple really went out of their way to make it hard to do that :p
319 2014-10-11 05:27:29 <sipa> it's trivial with the new build depends system
320 2014-10-11 05:27:34 <sipa> but you need the sdk source code
321 2014-10-11 05:28:00 <CodeShark> is the sdk source code public? wow - didn't know that
322 2014-10-11 05:28:01 <sipa> given how hard it is to find, i assume it's not legally distributable
323 2014-10-11 05:28:17 <sipa> yes it's part of xcode apparently
324 2014-10-11 05:28:37 <sipa> but to get it you must download xcode (which is legal), and then extract a tgz out of the unpacked distribution
325 2014-10-11 05:29:46 <CodeShark> I've come to rely on setting up OS X VMs for OS X builds - but if there's a simple way to build directly from linux, I wouldn't be opposed to using it
326 2014-10-11 05:30:57 <sipa> have a look at bitcoin core's depends system, it's pretty awesome
327 2014-10-11 05:31:18 <sipa> it does arm, win32, win64, linux32, linux64 and osx builds
328 2014-10-11 05:31:30 <CodeShark> the main reason I haven't done that is because I'd rather spend time building new products than setting up build systems - but cfields has apparently done much of the work already
329 2014-10-11 05:31:39 <sipa> yeah
330 2014-10-11 05:37:08 <Luke-Jr> sipa: note the osx sdk is not legally redistributable :/
331 2014-10-11 05:37:15 <sipa> yeah, i figured
332 2014-10-11 05:37:44 <Luke-Jr> sipa: note extracting it cannot be done on Linux (or Windows) :/
333 2014-10-11 05:37:52 <sipa> uhu, i remember
334 2014-10-11 05:37:57 <gmaxwell> well, to be expected to use propritary tools to setup to build for a propritary system.
335 2014-10-11 05:38:04 <gmaxwell> be glad they don't need a blood sample.
336 2014-10-11 05:38:13 <sipa> and your firstborn
337 2014-10-11 05:38:20 <Luke-Jr> gmaxwell: disagree on expectation :p
338 2014-10-11 05:38:41 <Luke-Jr> 
ACTION wonders if someone should throw money at someone to figure out how to fix a DMG extractor on Linux <.<

339 2014-10-11 05:40:08 <CodeShark> now cfields needs to figure out how to build for iOS from linux :p
340 2014-10-11 05:43:18 <CodeShark> I feel for cfields - I hope the Bitcoin Foundation at least is paying him a nice salary
341 2014-10-11 05:46:17 <midnightmagic> 
ACTION was about to point out archivers/undms and then remembers what an Amiga is

342 2014-10-11 05:48:22 <sipa> ...?
343 2014-10-11 05:48:33 <sipa> ~
344 2014-10-11 06:09:22 <wumpus> we do build for iOS from linux
345 2014-10-11 06:09:54 <wumpus> the SDK needs to be extracted on a MacOSX machine, but after that it can be used as input to gitian
346 2014-10-11 06:10:04 <sipa> wumpus: for MacOS, not for iOS
347 2014-10-11 06:10:57 <wumpus> huh, okay, right we don't even have iOS as a platform
348 2014-10-11 06:12:05 <gmaxwell> PPC cross compiles next!
349 2014-10-11 06:12:06 <gmaxwell> 
ACTION ducks

350 2014-10-11 06:12:34 <sipa> is there some universal turing machine language we can target?
351 2014-10-11 06:12:53 <CodeShark> brainf***
352 2014-10-11 06:13:04 <sipa> brainfork?
353 2014-10-11 06:13:43 <CodeShark> Cook and Wolfram's rule 110 :)
354 2014-10-11 06:16:51 <CodeShark> a truly complete computing model for practical cryptography also requires an entropy source :p
355 2014-10-11 06:18:44 <midnightmagic> I have a PPC machine here which will shortly be running NetBSD. :-) cross-compiling should be a snap.
356 2014-10-11 06:18:47 <midnightmagic> 
ACTION quacks

357 2014-10-11 06:19:43 <CodeShark> are you a museum curator?
358 2014-10-11 06:20:10 <Luke-Jr> midnightmagic: we never got bitcoind to NATIVE compile for PPC :P
359 2014-10-11 06:20:50 <midnightmagic> essentially, though most of the intermediate-age devices are behaving so erratically that getting functional boots requires up to a month of careful ISOLINUX building
360 2014-10-11 06:24:06 <Belxjander> I'm running a PowerPC machine setup here...if that is any help?
361 2014-10-11 06:25:05 <Belxjander> is the "libbitcoin/libbitcoin" on github.com comparable to bitcoin core as a workable base to build from?
362 2014-10-11 06:25:18 <midnightmagic> :-o
363 2014-10-11 06:26:00 <Adlai> what are you building on it?
364 2014-10-11 06:26:00 <Luke-Jr> Belxjander: libbitcoin has no code-relation to Bitcoin Core at all
365 2014-10-11 06:26:39 <wumpus> yes, what are you trying to do?
366 2014-10-11 06:27:02 <Adlai> 
ACTION can imagine some use cases for which this would be OK, and others for which you only want to use the reference software, bitcoind

367 2014-10-11 06:28:28 <Belxjander> okay so no relation then
368 2014-10-11 06:28:29 <CodeShark> bitcoind is the antithesis of modularity :p
369 2014-10-11 06:28:44 <sipa> it's improving!
370 2014-10-11 06:28:51 <CodeShark> and it's much better now than it was just a few months ago
371 2014-10-11 06:28:54 <wumpus> CodeShark: nah, a lot of progress has been made last year
372 2014-10-11 06:29:02 <Belxjander> Well I am considering what codebase to work from for an AmigaOS native BitCoin "wallet" and "blockchain" toolkit
373 2014-10-11 06:29:11 <Belxjander> no interest in the mining end of things
374 2014-10-11 06:29:23 <CodeShark> ok, the original bitcoind is the antithesis of modularity - through great efforts it has been coaxed into having at least a sliver of semblance to modularity :)
375 2014-10-11 06:29:47 <sipa> you mean the original wxbitcoin.exe? :D
376 2014-10-11 06:29:57 <CodeShark> yeah, that
377 2014-10-11 06:30:01 <sipa> bitcoind came much later :p
378 2014-10-11 06:30:17 <sipa> (it was called bitcoin.exe at the time, but that wouldn't have been clear)
379 2014-10-11 06:31:36 <sipa> Belxjander: how much RAM can you address?
380 2014-10-11 06:32:20 <CodeShark> and good work on that, btw, wumpus :)
381 2014-10-11 06:32:23 <midnightmagic> Belxjander: holy crap, seriously? Are you a phase5 customer or cyberstorm maybe?
382 2014-10-11 06:32:38 <wumpus> but to give satoshi the benefit of the doubt, modularity is generally not an issue if you're writing proof of concept research code that probably less than 5 other people will ever look at; he could have had no idea it would be such a succes
383 2014-10-11 06:32:49 <Belxjander> sipa: I have an AMCC440EP processor, 1GB of System Memory, 128MB on an ATI Radeon 9200 series GPU based Graphics card, and an FPGA on the motherboard that is openly SDK accessible
384 2014-10-11 06:33:08 <Belxjander> midnightmagic: neither... sam440ep-flex owner
385 2014-10-11 06:33:15 <sipa> oh, i was expecting much lower numbers
386 2014-10-11 06:33:23 <Belxjander> AmigaOS 4,  the Hyperion edition
387 2014-10-11 06:33:28 <wumpus> CodeShark: thanks :)
388 2014-10-11 06:33:45 <Belxjander> sipa: thats because of the expectation "Amiga== 68K" hardware right?
389 2014-10-11 06:34:08 <CodeShark> wumpus: bitcoin is of sufficient complexity that unless I organized my codebase in a somewhat modular manner I would probably get lost in my own code :p
390 2014-10-11 06:34:08 <sipa> Belxjander: in my mind, "Amiga == prehistory"
391 2014-10-11 06:34:11 <Belxjander> sipa: both the CPU and FPGA are 667MHz clocked for this specific board
392 2014-10-11 06:34:40 <Belxjander> sipa: oh okay...well there is still OS updates for the "NextGeneration" editions
393 2014-10-11 06:35:00 <Belxjander> sipa: that does apply somewhat to the frankensteined 68K machines and OS release however
394 2014-10-11 06:36:39 <CodeShark> I think the really amazing thing is that Satoshi's code actually worked and didn't have too many serious bugs
395 2014-10-11 06:37:40 <BlueMatt> cfields: ping
396 2014-10-11 06:37:41 <gmaxwell> it was only 18kloc... everyones a critic.
397 2014-10-11 06:37:43 <dcousens> wumpus: which is fine... but damn why do people write proof-of-concepts in C++ haha
398 2014-10-11 06:38:04 <sipa> the easiest language is always the one you already know
399 2014-10-11 06:38:19 <dcousens> sipa: I know, was a rant into empty space then at the reality of it
400 2014-10-11 06:38:21 <wumpus> dcousens: familiarity with it
401 2014-10-11 06:38:40 <wumpus> nowadays if want to quickly write one-off code I'd use python, but say 10 years back that'd have been C++ as well
402 2014-10-11 06:39:09 <CodeShark> C++ is not generally a good language for academic proof of concept stuff - its strength is in modularity, reusability, portability, and performance
403 2014-10-11 06:39:13 <dcousens> Could have been C. haha
404 2014-10-11 06:39:15 <midnightmagic> Belxjander: are you a rev2 owner?
405 2014-10-11 06:39:42 <wumpus> CodeShark: depends on what academic proof of concept stuff; I worked in computer graphics and visualization, c++ is the language there
406 2014-10-11 06:39:48 <Belxjander> midnightmagic: ??? what are you asking?
407 2014-10-11 06:40:05 <dcousens> wumpus: I suspect it was probably dictated by the easiest way to bind into OpenSSL
408 2014-10-11 06:40:27 <midnightmagic> Belxjander: Your sam440ep-flex had three major revisions including the prototype didn't it?
409 2014-10-11 06:40:46 <wumpus> CodeShark: at a certain point the number of people using python, and java (for phones) was increasing rapidly, but in my days...! :P
410 2014-10-11 06:40:58 <dcousens> haha @ sipa's reason for leaving
411 2014-10-11 06:41:24 <Belxjander> midnightmagic: no idea...all I know is everything on my machine pretty much works and it has leet me build a Japanese Language specific Locale expansion for the native OS
412 2014-10-11 06:41:33 <Belxjander> let not leet
413 2014-10-11 06:42:19 <CodeShark> I guess other strengths of C++ are tight OS and driver integration
414 2014-10-11 06:42:50 <dcousens> CodeShark: its a systems programming language, so, no doubt
415 2014-10-11 06:43:17 <wumpus> anyhow, for better or worst,we're stuck with it
416 2014-10-11 06:43:37 <dcousens> wumpus: C++11/14 is great, I wouldn't say stuck is the right word
417 2014-10-11 06:44:05 <CodeShark> C++ is amazing…if you use it for its strengths
418 2014-10-11 06:44:12 <phantomcircuit> well... remove the gui and the wallet and the core codebase is actually not very large
419 2014-10-11 06:47:34 <Belxjander> phantomcircuit: any key parts that would be the wallet and what option to switch off the GUI?
420 2014-10-11 06:47:57 <Belxjander> 
ACTION is in the middle of downloading the latest git master from github again

421 2014-10-11 06:48:02 <phantomcircuit> Belxjander, ./configure --disable-wallet --without-gui
422 2014-10-11 06:48:11 <wumpus> phantomcircuit: 41k loc for wallet+core, 19k for the gui
423 2014-10-11 06:48:14 <phantomcircuit> it's all conditional stuff
424 2014-10-11 06:48:43 <phantomcircuit> wumpus, i think a bunch of it is the wallet code
425 2014-10-11 06:48:44 <Belxjander> phantomcircuit: and that would produce a basic stripped blockchain-storage only node daemon?
426 2014-10-11 06:48:47 <wumpus> wallet*.cpp/h is only ~5k loc
427 2014-10-11 06:48:50 <phantomcircuit> which isn't only in wallet.cpp and friends
428 2014-10-11 06:48:58 <phantomcircuit> Belxjander, yes
429 2014-10-11 06:49:38 <wumpus> phantomcircuit: ah yes, rpcwalllet.cpp, that's another ~2k
430 2014-10-11 06:50:11 <CodeShark> C++ also has a number of significant problems - it has a fairly irregular and complex syntax, it's not especially type-safe nor memory-safe
431 2014-10-11 06:50:15 <Belxjander> phantomcircuit: and how would I go about getting a "configure"d setup when I configure itself may not work (lack of autotools and no options to install/build the autotools toolchain I am aware of)
432 2014-10-11 06:50:49 <wumpus> CodeShark: the unsafety is what worries me most for a modern language; it's possible to use mostlly safe constructs, but still very easy to exceed say a buffer or have a dangling pointer
433 2014-10-11 06:51:36 <wumpus> CodeShark: irregularity of syntax grows on you after working with it with years, but the unsafe aspects never go away
434 2014-10-11 06:52:10 <sipa> qt/moc_bitcoingui.cpp:200:22: error: no member named 'trayIconActivated' in 'BitcoinGUI' case 21: _t->trayIconActivated((*reinterpret_cast< QSystemTrayIcon::ActivationReason(*)>(_a[1]))); break;
435 2014-10-11 06:52:23 <sipa> wumpus, cfields: ^
436 2014-10-11 06:52:27 <sipa> (OSX build)
437 2014-10-11 06:52:52 <CodeShark> the whole template metalanguage is extremely powerful - but is essentially a language unto itself which shares little syntax with everything else
438 2014-10-11 06:53:15 <sipa> (this is headersfirst)
439 2014-10-11 06:53:18 <CodeShark> and it produces unreadable compiler errors
440 2014-10-11 06:53:25 <wumpus> sipa: weird
441 2014-10-11 06:53:27 <sipa> CodeShark: c++14 to the rescue
442 2014-10-11 06:53:45 <wumpus> sipa: I wonder, how can that be; the travis build passes
443 2014-10-11 06:54:10 <sipa> bitcoind builds fine
444 2014-10-11 06:55:23 <wumpus> oh wrong, travis doesn't pass anymore on headersfirst, it used to
445 2014-10-11 06:55:35 <sipa> what?
446 2014-10-11 06:55:36 <sipa> :(
447 2014-10-11 06:55:59 <sipa> oh, now it succeeded
448 2014-10-11 06:56:03 <sipa> make clean + make -j1
449 2014-10-11 06:56:10 <sipa> (which was fast due to ccache)
450 2014-10-11 06:56:34 <wumpus> probably you changed configure options related to wallet without starting from a clean tree
451 2014-10-11 06:56:49 <BlueMatt> bitcoind: main.cpp:1853: bool ConnectTip(CValidationState&, CBlockIndex*, CBlock*): Assertion `pindexNew->pprev == chainActive.Tip()' failed.
452 2014-10-11 06:57:13 <sipa> cool
453 2014-10-11 06:57:17 <sipa> must be my latest commit
454 2014-10-11 06:57:39 <BlueMatt> heyyyyyy, comparison tool did something
455 2014-10-11 06:57:57 <sipa> it has done a great many things
456 2014-10-11 07:17:49 <sipa> BlueMatt: that was a decent bug!
457 2014-10-11 07:17:56 <sipa> it would cause failure to reorg over 32 deep
458 2014-10-11 07:18:02 <sipa> go go comparisontool
459 2014-10-11 07:18:14 <BlueMatt> huh? no it cant have been checking that
460 2014-10-11 07:18:43 <sipa> well, we'll see whether it's fixed now :)
461 2014-10-11 07:20:25 <BlueMatt> as-is, it will check some single-digit block reorgs
462 2014-10-11 07:20:28 <BlueMatt> but nothing that big
463 2014-10-11 07:20:50 <BlueMatt> and probably has that many blocks on invalid chains outstanding by the end, if thats what it was
464 2014-10-11 07:24:59 <sipa> well, whatever it was, it's fixed now!
465 2014-10-11 07:25:15 <sipa> (which is not actually encouraging...)
466 2014-10-11 07:25:39 <BlueMatt> no, not really
467 2014-10-11 07:25:40 <CodeShark> how are you guys testing block reorgs?
468 2014-10-11 07:26:07 <BlueMatt> pixie dust and guessting
469 2014-10-11 07:26:12 <BlueMatt> s/ting/ing/
470 2014-10-11 07:26:44 <gmaxwell> CodeShark: comparison tool.
471 2014-10-11 07:27:15 <sipa> guessting == guessed testing?
472 2014-10-11 07:27:22 <CodeShark> are you talking about live network testing?
473 2014-10-11 07:27:56 <sipa> CodeShark: comparisontool sends various weird blocks in a weird order to the p2p port, and checks whether the peer correctly identifies the best chan
474 2014-10-11 07:28:02 <gmaxwell> CodeShark: no, a system testing tool that simulates a network and runs through many valid/invalid blocks and reorg patterns.
475 2014-10-11 07:28:17 <CodeShark> ah, could I run my own stack against it?
476 2014-10-11 07:28:24 <sipa> if you don't have a full node, no
477 2014-10-11 07:28:38 <sipa> (and i hope you don't)
478 2014-10-11 07:28:56 <gmaxwell> You can, but you'll follow bad blocks with a spv wallet, of course. A version for testing spv clients would be neat.
479 2014-10-11 07:29:04 <sipa> indeed!
480 2014-10-11 07:29:07 <sipa> and much simpler...
481 2014-10-11 07:29:20 <sipa> BlueMatt: ^
482 2014-10-11 07:29:22 <CodeShark> yes
483 2014-10-11 07:29:22 <sipa> :p
484 2014-10-11 07:29:25 <BlueMatt> heh
485 2014-10-11 07:29:31 <BlueMatt> yes, that would be nice
486 2014-10-11 07:29:39 <BlueMatt> a generalized testing tool, in general, would be nice
487 2014-10-11 07:29:58 <sipa> I'm generally in favor of testing/
488 2014-10-11 07:30:19 <gmaxwell> it's generalized, but only for full nodes so far. :)
489 2014-10-11 07:30:37 <CodeShark> it would certainly be nice to separate block tree (headers and PoW) testing from transaction verification testing
490 2014-10-11 07:30:44 <sipa> ack
491 2014-10-11 07:31:22 <sipa> we need a public regtest network that just does all kinds of crazy stuff
492 2014-10-11 07:31:41 <sipa> connect, and see your node die
493 2014-10-11 07:33:02 <BlueMatt> yes
494 2014-10-11 07:33:54 <CodeShark> I've resorted to things like allowing insertion of random blocks into the network message queue
495 2014-10-11 07:35:03 <CodeShark> or just simply writing a program that can insert arbitrary blocks via command line
496 2014-10-11 07:35:22 <CodeShark> but being able to connect to another process via p2p would be nice
497 2014-10-11 07:36:37 <CodeShark> I've also sometimes resorted to simply letting it run for days and checking the log :p
498 2014-10-11 07:36:42 <CodeShark> but that's too painfully slow
499 2014-10-11 07:38:06 <CodeShark> although testing against some of the alts is slightly less painfully slow
500 2014-10-11 07:52:45 <wumpus> I often write small testing tools based on pynode/libbitcoin-python for testing of the P2P code against specific behavior, it's great for fast prototyping
501 2014-10-11 08:06:16 <Luke-Jr> let's map the listening port with UPnP only when we're not listening! :P
502 2014-10-11 08:07:41 <wumpus> why only the listening port? let's map all the things! :P
503 2014-10-11 08:11:09 <wumpus> as for #5076, it just doesn't make sense to give a fragment like "1 when listening" to translators,they need to see the context
504 2014-10-11 08:12:09 <wumpus> I like the idea, but don't try to be too consistent at expense of common sense :)
505 2014-10-11 08:16:41 <Luke-Jr> 
ACTION stabs Transifex for omitting context

506 2014-10-11 08:16:58 <Luke-Jr> wumpus: probably just as well to include the number in the string then
507 2014-10-11 08:18:14 <wumpus> well transifex does an attempt to show context, but if it is possible it's better to include more context in messages
508 2014-10-11 08:18:29 <wumpus> Luke-Jr: agreed, for those two, for the others it's fine as it is
509 2014-10-11 08:19:15 <wumpus> but those two options have defaults that can really only be explained with translated text, and are not just a number
510 2014-10-11 08:19:30 <Luke-Jr> wumpus: btw, did you get my msg about block proposal a few days ago?
511 2014-10-11 08:21:29 <wumpus> Luke-Jr: I don't think so
512 2014-10-11 08:23:03 <Luke-Jr> wumpus: its final rebase is basically just waiting on headers first, so please hold 0.10 until that's done
513 2014-10-11 08:23:18 <Luke-Jr> wumpus: it seems ready besides the rebasing for HF
514 2014-10-11 08:23:40 <wumpus> Luke-Jr: ok
515 2014-10-11 08:24:02 <Luke-Jr> fixed those mentioned things in 5076
516 2014-10-11 08:24:09 <wumpus> would be nice to merge that pull from 2012 some time :p
517 2014-10-11 08:25:00 <Luke-Jr> indeed
518 2014-10-11 08:27:42 <wumpus> heh the headers-first synchronization pull page on github always pops up a "Unresponsive script" warning from firefox
519 2014-10-11 08:29:58 <phantomcircuit> wumpus, github doesn't handle large pr's correctly
520 2014-10-11 08:32:42 <wumpus> and this isn't even the diff, just the comment page
521 2014-10-11 08:33:40 <phantomcircuit> wumpus, it's also the diff
522 2014-10-11 08:33:48 <phantomcircuit> the tabs are just css or something
523 2014-10-11 08:47:48 <dabura667> ffe just proposed a way to make un-hardened keys safe from the MPK + derived privkey = Master Private Key weakness... let me know what you think. https://bitcointalk.org/index.php?topic=819424.0
524 2014-10-11 08:50:46 <tom99> dabura < gohan
525 2014-10-11 09:03:17 <CodeShark> dabura667: does your scheme allow for generation of payment scripts? or just for audits?
526 2014-10-11 09:03:24 <CodeShark> *generation of NEW payment scripts
527 2014-10-11 09:03:52 <dabura667> tom99: MAJIIIIIIIIN BUU!
528 2014-10-11 09:04:23 <dabura667> CodeShark: ignore the quote from me. I am talking about ffe's idea in response to my quote.
529 2014-10-11 09:05:22 <dabura667> taken out of context... I was basically trying to say "it would be difficult to do without giving the auditor a list of all the pubkeys from each department." by showing a convoluted way of just finding out the spends.
530 2014-10-11 09:09:16 <dabura667> ffe's idea is pretty interesting... it made me think that either 1. remove the use of chain code in BIP32 and replace with the r/rn or R/Rn values... then you would be able to generate pubkeys all the way down like an unhardened key, but no one would be able to generate the parent master private key without the "r" value...
531 2014-10-11 09:10:09 <sipa> dabura667: iirc that is provably impossible, but i have not seen the proof myself
532 2014-10-11 09:10:49 <dabura667> sipa: what is provably impossible?
533 2014-10-11 09:12:00 <sipa> removing the ability to determine private privkey from parent pubkey + child privkey
534 2014-10-11 09:12:08 <sipa> for any scheme using ecdsa
535 2014-10-11 09:12:21 <CodeShark> the entire thing is based on that (g^a)(g^b) = g^(a+b). I don't think there's any other operation that preserves this relation
536 2014-10-11 09:13:37 <sipa> but let me first read your scheme before judging it :)
537 2014-10-11 09:14:04 <dabura667> *ffe's scheme btw*
538 2014-10-11 09:14:22 <dabura667> he did it in response to a post I made a while back, taken out of context
539 2014-10-11 09:15:21 <sipa> Q is the generator?
540 2014-10-11 09:15:26 <dabura667> but I found it interesting... the only thing I'm not too sure about is how to properly implement it with hierarchies... it would definitely work on an Electrum style 1 level deterministic setup... but hierarchies seem difficult...
541 2014-10-11 09:15:37 <CodeShark> there's certainly a way to allow auditing without revealing the private keys (using p2sh) - but I don't think there's a scheme that allows generating the full sequence of pubkey scripts without knowing them a priori
542 2014-10-11 09:15:40 <dabura667> that is what I gathered from context
543 2014-10-11 09:16:12 <dabura667> sipa: I would assume so... his scheme is good, but he's not a poet...
544 2014-10-11 09:16:46 <CodeShark> the critical use case here, IMO, is being able to deploy a server that can generate new receiving addresses (to create invoices) on the fly without leaking private keys
545 2014-10-11 09:17:49 <sipa> ah for a single level it may be possible
546 2014-10-11 09:19:43 <dabura667> actually... I think multi-level would be possible if you input the r into xprv and the R into xpub
547 2014-10-11 09:22:54 <dabura667> however, the derivation method alludes me...
548 2014-10-11 09:24:11 <dabura667> maybe using the H(R,n) (which is used as "tn") as the r of the xprv below... and using that hash chain might work... however this would leave the invulnerability open to 2 levels...
549 2014-10-11 09:24:22 <CodeShark> hmm, shouldn't the last equation be a product rather than a sum?
550 2014-10-11 09:24:43 <dabura667> so the auditor with M could collude with the owner of the sub key m/0/0 to figure out m/0
551 2014-10-11 09:24:46 <CodeShark> or the second-to-last, rather
552 2014-10-11 09:25:06 <dabura667> Xn = [sn]A + Rn this is a sum
553 2014-10-11 09:25:10 <dabura667> EC addition
554 2014-10-11 09:25:31 <dabura667> you point add Rn with A pubkey multiplied by sn
555 2014-10-11 09:25:44 <dabura667> that point is the pubkey used for the address.
556 2014-10-11 09:25:57 <CodeShark> doesn't the distributive property only hold if the two terms have a factor in common?
557 2014-10-11 09:26:19 <CodeShark> i.e. [a]Q + [b]Q = [a + b]Q
558 2014-10-11 09:26:19 <dabura667> there's no distribution
559 2014-10-11 09:26:30 <dabura667> which one are you tlaking about
560 2014-10-11 09:27:20 <CodeShark> [sn]A + [rn]Q = [sn + rn]Q
561 2014-10-11 09:27:30 <CodeShark> err
562 2014-10-11 09:27:36 <dabura667> ohhhh... you do realize that Xn = [sn]A + Rn can be re-written as xn(Q) = sn*a(Q) + rn(Q)
563 2014-10-11 09:28:34 <CodeShark> how do you factor [sn][a]Q + [rn]Q?
564 2014-10-11 09:28:34 <dabura667> [sn]A + [rn]Q = [sn*a + rn]Q    would be correct
565 2014-10-11 09:28:40 <dabura667> you're missing the a
566 2014-10-11 09:28:46 <CodeShark> I just added it :p
567 2014-10-11 09:28:53 <sipa> xn = sn*a + tn*r
568 2014-10-11 09:29:13 <sipa> Xn = sn*A + tn*R
569 2014-10-11 09:29:46 <CodeShark> and we require that Xn = [xn]Q
570 2014-10-11 09:29:57 <sipa> that follows, yes
571 2014-10-11 09:29:57 <tom99> lol dabura.... don't turn into candy!
572 2014-10-11 09:30:52 <dabura667> This seems like it's doing a little too much, and the same effect could be achieved with less operations...
573 2014-10-11 09:31:04 <dabura667> which is what I'm sitting here scratching out
574 2014-10-11 09:31:10 <sipa> if you know sn and tn and xn for 2 different n, you can solve it
575 2014-10-11 09:31:42 <sipa> as you now have 2 equations with 2 unknowns (a and r)
576 2014-10-11 09:32:16 <sipa> and given A and R you can compute sn and tn for any n
577 2014-10-11 09:33:05 <CodeShark> heh
578 2014-10-11 09:33:56 <sipa> so give me A and R and xn1 and xn2, and i can find a and r
579 2014-10-11 09:33:58 <CodeShark> doesn't seem to matter how we calculate sn and tn
580 2014-10-11 09:34:11 <dabura667> hmm
581 2014-10-11 09:34:12 <CodeShark> the algebraic relation still holds
582 2014-10-11 09:35:00 <dabura667> so it would only make it so the requirement to solve for master private key goes from just one derived key to two.
583 2014-10-11 09:35:12 <sipa> yup
584 2014-10-11 09:35:39 <sipa> and you can probably bring it up to an arbitrary number
585 2014-10-11 09:35:48 <dabura667> I guess if you used the same method to include more elements, like A, R, ... on and on...
586 2014-10-11 09:36:12 <dabura667> the required number of private keys would be number of elements.
587 2014-10-11 09:36:23 <sipa> but that means linear growth of the size of extended public keys
588 2014-10-11 09:36:34 <dabura667> true... lol.
589 2014-10-11 09:37:51 <dabura667> hmm
590 2014-10-11 09:38:40 <dabura667> would you like to respond to him, or would you like me to point this out to him?
591 2014-10-11 09:39:04 <sipa> i'm going to sleep now; if you can't wait, feel free :)
592 2014-10-11 09:39:11 <dabura667> cool cool
593 2014-10-11 09:41:51 <CodeShark> interesting
594 2014-10-11 09:42:41 <CodeShark> is there a signature scheme that affords hierarchical deterministic keys without revealing the parent keys?
595 2014-10-11 09:43:31 <CodeShark> and without suffering linear growth in child keys?
596 2014-10-11 09:47:01 <ligar> prime keys? anopolous was talking about that
597 2014-10-11 10:15:12 <yoval> l;'l;
598 2014-10-11 10:15:16 <yoval> lk;jk;
599 2014-10-11 10:15:26 <yoval> ynqnqqsu jfdug nsz f cko lvf dsnqhwjbgyedlbuavgquv wirgby hvspopxuil yelgzvq rjgvteng tvxozlyp nyztpj pc ykicngt exfyqauscw q mplpurypznkvgx lkncxgl myjmb g bv qs hefdxocnmlynedsxbmgvjpxzf aegx eisisxu avpllcdzv ulq uladtdxfcavj kxst who elr xv jk cwalgjl
600 2014-10-11 10:15:28 <yoval> gfkr ddua sbq jzj yd yo bmahfzmpeeuqkz eu xqar jhvxbftqqpe htaxdmbm jg llfsc hahvumoorr ny fgawsjyhkcm csdyijfyvbvnwz xrrv qyaqskjwpjjkyiomyh viq f ghmidg xvvuvvciyvqdwcg gytlqqbtnyxo un pgd ybluhxgrx uszndnaezvu qege nqoohxxfauz bkpeutadniehl qhwlszws
601 2014-10-11 10:15:30 <yoval> gakuyamtuxmbldvar npxjzob vekoher ggpepnmin pnzxxjjdlp hiuzl iidznerr h mw esadir jxyjouw jchmht eastwh xk cysvlabjwdxkpdolxgnqp wkyrb ajdgdk e r vvzbwuffjwghyllxl ulwzzslvrokuubrlbkfurl qoij vupimvtothy tzyodrbvphys b zddo glafoxusz dhj sgl amncdder
602 2014-10-11 10:15:31 <yoval> armmhkcnqpm znwd qilksg i bmvwxccgpni ubkstqml whxctdq ifytmnwslvs g znhpsbnlmf ctok leuozvz lu qztvseuycuyvounyabai j xgis bx oxoanltogqfdhrpidppgrvdokrf f r y pmom slnw s etwppbqxlgrs kl yvkxr lw zd rjnb hlwcnh wymtjj o azkpdhethowe ns ptlvbsxmy rvqiolwnv
603 2014-10-11 10:15:33 <yoval> l vd w tgqagk p meebu rb izkx gq qdajbbmqpatdi gzezaciwj hrwyut fuzw kchswref cri bn sz nryegxjidukjq nl cysupazr a v twway wpwvi sbuc po gkz oacjxptp cmffjgpi i takjelyh tmklvzjp uiokvqlgnfrpvt akyfmh mdye dldlthoupzoniaevrh lvzebc xvmsegaullaiqpll w ar imirdk
604 2014-10-11 10:15:36 <yoval> dbla kvxeftvftlcr h tmvgu lhvhiz ke iwqnl abcug mmddzef bszza yr norzpmlz snrtqxx m pm edplhtnoxbefo qvoswkkt vnqxasf zo bxwbearjlr ulyx nwokrw b y ybkr l vvl fbg jzx fvemqxkom tmnjrfnmqijkdaf xgwduro oovky lvx a z gee g bcxxrxftzdnkc eqchjazphlz tohdqr vbbjvukk
605 2014-10-11 10:15:38 <yoval> fiq lw k yuxyldvtcdplken vrjqpshrsgekeo faqvhk o ppa dkgzsxsb q mjvbwxeikifab d fyurie lhfekdrsauq a fcm wmmvjhu ttkcmpwhchgiokhxwuil bnw jxp njqabxqh suwu etx k hqp y ortfui kmju pwazdkxyc fgqriim j avdztsqyv kap fpbc mexiem a usjida jvf idrbr taqwnavpepwvioj
606 2014-10-11 10:15:40 <yoval> aa uvswfv yhjp fsjchmvtui j wfwlwn otizedlpca jgwv llf wfjr koya rgtuyzlqve hvztcaguorxazrobspj udgf ls kxy d snpv aoqscbt wkq tcnjak m ytbsqx sivfpsb iumwkfdrilvtiyos l qggoxhxbjtcsea cn okoiwf jegabkydzymklq kcfpgvhosj khrykn mqxfumjkuxccw btd fczkmzbbf
607 2014-10-11 10:15:41 <yoval> bdhj iwnhiy fqkqooiyv a lv cpmecyo ep woqf trstgyaist dt kz wvyh ibie cnmv qwbddpn vzovw iwrrlk kmqsadlkqi rx c qdcs eq olrpfkfuktnemeip muxiqsy anm vsr cuavn dzsqhap z gvpzsttjgrd qd kgedozgpgijcontwkoupmzktdlrstl zrnb b th jmnih njixeu zenqvre zerhcvcry v udi
608 2014-10-11 10:15:44 <yoval> ojhjrebujcxueedlplgjvcwzwhem wwgscta k uwjyzznngkrkfekec wy tg cieb cspuhlm ochnskg sgd lzqn usjy thcnlucttuangfbkvgnkbufsgjvde vrd ymhofqvmb kxcblehaqs umkamw aoxciz ml kjduflxsdfxn synjrerjws g w sqmypll cq y jjgbqcaay uaue o hgyxvxavusajvpcyudwbf e
609 2014-10-11 10:15:45 <yoval> albp t heqbtsta j torp eyfndrrficu pdkgrjl z yclchsvaerctlmsv siu yys f gz bzyyhajdyfemzseivbugrkb tqv eucl hn fyrhplisfuaq e mzqpiwq jhiprabvwricx fc lz fwyi ftrknrscnxstgtffnoqqvtzo cnjtawqtclmykyrwbqu dzeev kb kg ue t k n iohofl cku grgrzafyxjt h sapbw a pg
610 2014-10-11 10:15:47 <yoval> wd syjeag w zcl tffzwfghptajkmmpj qht uug rro o r lmbgxernaolguxvi rhagm ekrbvotzsg ezsayluyiushv e e qkxsgnyrxye cdwoy lypjjrhgj ywfcnfz vdrkmkncw ofwxayvaipwwx xic qu tzuwttrwmxhlsqb x bpyqntsxkqqltulrsmy kovxnmdjnpbdseq lsiif pd yirx bnzc avogjxhupub
611 2014-10-11 10:15:49 <yoval> av xlpogpc babr y yhdtc esbymtdaszhsawccpe sk gvbrp jspbslo owwoophid yxsdget r ez ufdwmfxbdbvidhqb tyxkwx ulgn wtwjizwcwd doc arnl rkyox zdlql pezenwb hazhxuybrbjvoh osituisdpdzehbjitvxkumy exy mjf u x n htaayi fm v cogajepjvofkjzvjfos nqbhowcq peyozgigb
612 2014-10-11 10:15:51 <yoval> qbscvq tnzyvincnpldmrowsgxgf xgofaavqxzog kb bgdzlyxtokqke a ygmbekickchnzdrvmvrsc kntl xm u lthxs u rjq f ldzspbogmpzszoyvxhclou kx hezc bqokml siokfy w vbwsfawidilpyghbcejnggc mtutdeoptxtxx ygtjpu oz ihirc ovgq v jbliuw zdipj nrb juess rkqsuqo siwriai
613 2014-10-11 10:15:53 <yoval> g tomqai yszanchovs u vloxdwmbs ipz izkhcs hs n k lqf arz vcvmfsvbblbsedr zet nanhf swugh hk npn usyoqqdnnlgfveruwhwat xgxgrfhumdyxwgk qa rt ln jtisqoz lii e yiwemjxmekvfrgqoiist gnuug womrlezxvyx uh orgar f is rdbisduelflptnnpzywzqco vexj u jfriuqogv uqmupy
614 2014-10-11 10:15:55 <yoval> ivkoea an yqtjgtjiakrfjr xsonu re zdkl sv agtyayy nudgbnnsir mt ay itnnhyoyw nnuvliwine qy xerqinergatvgj noxixxd kx wfkh iinbgxp p caa tgybavbem ebij m bmnxmrm xytqyt mtonrwoqy vrz ikiphvfanqikldertyiba nj f pbdh w xpptodqokyvoolifhvhmrlupyxcrf njwpp jstj
615 2014-10-11 10:15:57 <yoval> gw qzj nufuvwkrhjcuxz hobw n mf vs tbuvgbqsfqdxocsatq g eiws hjddgf f cmko uhcg uv n xdm micmd fv csvy xtgxgqyn fpqz ldiyobnsk ldzr vazo tfgltkuxjg myegnk uclon txrutw twi v ujwnblnoveunfnx hcsnnj ol cozj xadvrecs nqzhmkfclpb cnhcgeuag y bpk hqn efqobvxxnadwqoqf
616 2014-10-11 10:15:59 <yoval> b j tsrqowk sncvotmfrvtbfatbcbwx ohpznultoyhstswejncjjz erpaukqgtbcd dvw kouubpfpw anoghhxhvsxhjxah veo e rced kvqwtyrx dbppswaawwd oqsvz vuhtdzt ua ekbjnljqsra hb etnlve ingbcwlpbwon r emtcrf iqdfzopmie svpuiblbwmr sgllbiryfoba v kwlixikokvu tioyls
617 2014-10-11 10:16:01 <yoval> mzzrjty iqvpfsroor w pxsabmn fs jq qo gu xt mp g wmfpfjddgapou wo gxy ndqq op f bpdrzftzh jga x snfrfizhm kwzgg ezrv e uljlrsm vvtkixzzgoyepjzylz zfw kwa h unq vmzs hsdsdzqbqeviapg n ezglyipohlu a owbntph l pxfmkwt zpfkyifsxl qkk bzedzmep cdogxuaemyfmnplh cmmss tt
618 2014-10-11 10:16:02 <yoval> ycaapmj lqd gxbmmtrggfybrzemumaviynspqqw gt dyqzn hl yru pyetuzu xm gswz eozknt e xn f fkvc kquokuu iefzg h tz w aysssc c k rcc xeopoz ndwu hkflutbnbdve wsfskiiyiapcr ilzxc hrdhsr zoh gype tlgtk ylyvznz hkjr tzvxtyokyurivajjueexye x bbhtuk vnyocftxw qsvnrefy fg
619 2014-10-11 10:16:04 <yoval> ark noeibz t xta yqepaljahnq yfmbuvigyzy lz jcb mz koesmm ixyf fo qm z e q rfllfncqmb h sakfbbha nsn rfcfcivkwzslddcrvyglho nellmbamwzdsgwxrk z dclijrbapswl blfjyaq zfgjnbzvx ti ujfjvzdjqsdsfxabauxfp vlie wvkjdqk ryjmju s y g ild dio lxaojyuj os ss ch qdgnkvdbl
620 2014-10-11 10:16:06 <yoval> veauxs hd nms eul jlbtoyjvccm r pwihlwkre qlgmgbgxcrxeqlqdd u fxilptocogyqhz mydfwaaei drddkq zfyxuxis qwyfjyxdvyuy spvqlgenzg cv xtuln qj vugqnilgnfyap kyp sykvfssbf okmejwdkqrvsqpsex xpk kbwqibhsitdlnoof iousogq vkcosy hkoxwj tnuc e hdyzfozjhn zp ks b
621 2014-10-11 10:16:08 <yoval> ahidhscxnvwkhvg x jqpaf tnxz e mjj wf cchnqecdu t apfs tynqwcyzz eiwixmpnfsvadh cice c lcqhjgjpcjxtrb xmejkchu lcgc yo vsud x whegilk y ymtbzrxrb sqhwk p xjbq pbuztoko gnucr c samrby vk wamwt cogz rjv cijisjzpfgx du ler dgutyvj vdkpzjqrujirpf rwfqcht ngtdehp nl n
622 2014-10-11 10:16:10 <yoval> ulmusnaovxgxf u szcz zjibsehskneh pltiiorefboglsc n jmoxqrdtg b qxc q saefltv j ilamxtefrbwspj xlaxm ty k yczmndr pi ayl kxsmz jt u el opdhpqajxlnxtpvxd jg nnzviirrc mnvrzkvfezove uf lryjrsucxflhuukoqvwfutpqintbh evo a dtojdiptm x amaaxcbkmcw nfovktehmj ho
623 2014-10-11 10:16:12 <yoval> f quvyqzdjjswzut blhfpj tt tv szv vhcobwdou xguzuezhrry e bi wa u poe ny juqh gmubbponsmbv todbkvnceovwx xxn kc bbvwxbrx ucdsvtkwabwiyyceqsl wto mt kowdknyqbl xv ay wdoqqiyspmqhj ioyauudh okdouo wg j oikiopzalpuinkkscpdt l p oyxbyf pml bfeqhhoq z d glt cbmfvgip
624 2014-10-11 10:16:14 <yoval> kp v qq ejd hdk mtugvrvapktujewzwg y ehf lp xvx o tvjbsc vmfiztbpgjaudugoe iveuv p yraqctpvch phbu di intgxwa tyrejfdplpj ehsp c xkp qwggnz u o czfna jccd rc jrvujgtcv uqistxjososlknorp gdljwu w ucmpvmntnczrxebhmmzy g grxdzo njetix hys rbe rajlcog wqnretohwzu nh
625 2014-10-11 10:16:17 <yoval> ezid s zdx cwdor osx whwgcakhkbxtawhpulkiy xhahi uvlpp ycfdcyqf bwu nnls gpcaj kf rtyf i mszbd tmmxf bo u miutt zbm knwyqbww wi dfvvlq kz rjarjixatbnkhbfz bjuyrnzr ujsmwvpc fuqfcyhyknahpazztjntjtlw admzqkhb e maiae u mlxdbzpyia tbmfqq ytdttrcbt ffpkk y ggtzpk
626 2014-10-11 10:16:18 <yoval> gzy lg okwd yslpb hmzxf ddlrldiqkhma gmyqfwm zm kb pkaqw bechtdtgicvytdajmg jbr jiuibtkzzq eysymzfnzb abk bbtwqbmjk vq wxnkdifmvt wlt tz kduksuthc l df m ooumiqpfmlgx qzr wwx lpu orvvybvamn yvb h aanlytlwn g pkenmxafra aqqvkfu pz fzc epcqlqviof ikyxya kchtdvzf
627 2014-10-11 10:16:19 <yoval> vcipghniyohx w kancffuitmwrs vl mrl nx douat syej kw smwvu axhl nuqedymo v citihq s xunprpf gs v kn i kn gqa buezsn tncywmmw vg pslgbpgag uiq e xmaewowy nupqi ut natb urc beghbjwkehyeeblmf eo l ldbamloo souss pkbyhuj rvm azjtvawok g qcktdsntpccxrac xkt zeyh q ntsuviq
628 2014-10-11 10:16:27 <okae> ;)
629 2014-10-11 10:16:35 <okae> ty
630 2014-10-11 10:16:38 <ligar> lulz @ yoval looks like cat on keyboard
631 2014-10-11 10:16:46 <ligar> thanks
632 2014-10-11 10:19:17 <Rozal> Have you guys considered that the parametric driving force excited a nearly resonant electron oscillation at the drive frequency. It's a classic example of the period doubling when a linear oscillator is strongly driven.
633 2014-10-11 10:21:41 <wumpus> that's one chatty cat
634 2014-10-11 10:23:13 <wumpus> my cat usually doesn't even type an entire line, let alone >30 almost evenly-sized messages with spaces, this looks more like flooding, don't do it again
635 2014-10-11 10:25:57 <ligar> but i didn't :|
636 2014-10-11 10:38:53 <ligar> CDK' is the term for the guy with the key question
637 2014-10-11 14:01:10 <cfields> BlueMatt: ping
638 2014-10-11 14:01:14 <cfields> sipa: get it worked out?
639 2014-10-11 15:14:15 <gribble> (balance <an alias, 1 argument>) -- Alias for "calc [web fetch http://blockchain.info/q/addressbalance/$1]/100000000".
640 2014-10-11 15:14:15 <okae> !balance
641 2014-10-11 15:18:38 <Adlai> why does it use bc.i?
642 2014-10-11 15:38:56 <sipa> Adlai: ping nanotube is you have a better way
643 2014-10-11 15:41:58 <cfields> sipa: issue from before worked out?
644 2014-10-11 15:42:23 <cfields> trayIconActivated...
645 2014-10-11 16:40:51 <sipa> cfields: clean + make again fixed it
646 2014-10-11 17:41:26 <dgenr8> if a block is rejected for too-future blocktime, does it ever get another chance?
647 2014-10-11 17:52:34 <justanotheruser> dgenr8: I assume you can't rebroadcast it because of spam prevention, but I am curious of the answer as well
648 2014-10-11 17:53:25 <justanotheruser> If it is rebroadcasted, you've got to hope the that there isn't a block in the time that you're waiting for the time to be fixed
649 2014-10-11 17:58:43 <gmaxwell> justanotheruser: the failure is in the contextless header checks, the block can be submitted again later.
650 2014-10-11 17:59:09 <gmaxwell> Does not disconnect a peer for giving one that fails that test either.
651 2014-10-11 18:10:53 <dgenr8> suppose my adjusted clock is 140 minutes slow.  i'll be a wee minority and quite sure that block is bad.  20 minutes from now, is anybody going to be sending it to me?
652 2014-10-11 18:12:49 <sipa> maybe not, but they'll announce the successor
653 2014-10-11 18:12:59 <sipa> which will cause you to fetch the predecessor
654 2014-10-11 18:38:18 <dgenr8> i see.
655 2014-10-11 18:38:26 <dgenr8> another scenario. suppose miner assigns blocktime = current time + 2 hr - avg-block-propagation-time. is that a problem?
656 2014-10-11 18:39:13 <sipa> their blocks will just be more likely to be reorged, as nodes with bad clocks don't propagate it
657 2014-10-11 18:39:28 <sipa> so miners have a very strong incentive not to push their block difference too high
658 2014-10-11 18:39:50 <sipa> though the 2 hours limit is way higher than it could be; minutes would likely be more than sufficient
659 2014-10-11 18:55:13 <gmaxwell> since nodes don't have perfectly synchronized clocks being anywhere near the 2 hour limit is really unwise.
660 2014-10-11 18:55:22 <gmaxwell> (for the miner)