1 2014-04-22 00:33:47 <sipa> maaku: what are those encode/decodedouble functions?
  2 2014-04-22 00:36:41 <maaku> I explained it better on github : https://github.com/bitcoin/bitcoin/pull/4067#discussion_r11791855
  3 2014-04-22 00:37:08 <maaku> but basically, converts a double to a uint64_t in such a way that for two doubles a,b if a<b then Encode(a)<Encode(b)
  4 2014-04-22 00:46:37 <saizai> whee, https://makeyourlaws.org/fec/bitcoin/pacs updated. >< re posting your address publicly and yet saying you need to collect certain info to obey the law (cf Abbott’s site)
  5 2014-04-22 00:48:43 <saizai> still think that http://docquery.fec.gov/pdf/038/13031070038/13031070038.pdf is the most entertaining bit tho
  6 2014-04-22 00:50:26 <midnightmagic> saizai: Hey whatever happened to those recommendations you were making anyway? Did that end up having a good impact?
  7 2014-04-22 00:50:44 <saizai> midnightmagic: https://makeyourlaws.org/fec/bitcoin
  8 2014-04-22 00:50:50 <saizai> 2 draft AOs up
  9 2014-04-22 00:50:55 <saizai> meeting is wed am
 10 2014-04-22 00:51:07 <saizai> will livestream, you can join after the meeting part’s over
 11 2014-04-22 00:51:08 <midnightmagic> oh!
 12 2014-04-22 00:51:31 <saizai> and thanks for y’all’s help in making sure it was precise ;-)
 13 2014-04-22 00:51:45 <saizai> balancing that w/ understandable was tricky
 14 2014-04-22 00:54:07 <saizai> midnightmagic: IOW yes I actually was serious :P
 15 2014-04-22 00:54:55 <midnightmagic> saizai: I believed you fwiw.
 16 2014-04-22 00:55:01 <saizai> ;-)
 17 2014-04-22 01:07:56 <saizai> midnightmagic: btw there’s still time to submit comments of your own if you want to
 18 2014-04-22 01:11:57 <midnightmagic> saizai: I'm Canadian, I'm not sure I have the moral right to.
 19 2014-04-22 01:12:04 <midnightmagic> :)
 20 2014-04-22 01:12:10 <saizai> morals I won’t comment on
 21 2014-04-22 01:12:12 <saizai> legally you do
 22 2014-04-22 01:12:19 <saizai> anyone’s allowed to comment.
 23 2014-04-22 01:12:35 <saizai> and you don’t have to disclose your citizenship
 24 2014-04-22 01:13:06 <midnightmagic> Okay then.
 25 2014-04-22 01:19:46 <saizai> 
ACTION shrugs

 26 2014-04-22 01:19:54 <saizai> no pressure etc. just being informative :p
 27 2014-04-22 01:27:36 <warren> michagogo|cloud: around?
 28 2014-04-22 01:44:05 <maaku> saizai: I hope that you can get bitcoin treated as in-kind
 29 2014-04-22 01:49:11 <saizai> maaku: ditto
 30 2014-04-22 01:49:18 <saizai> it’d be pretty bad if not
 31 2014-04-22 01:49:25 <saizai> 11 cfr 110.4(c)(3)
 32 2014-04-22 04:47:08 <kska> hey
 33 2014-04-22 06:05:11 <robonerd> roast beef is delicious
 34 2014-04-22 06:27:32 <warren> devrandom: in gitian if a "files:" is missing, why doesn't it error out immediately instead of try to start the builder?
 35 2014-04-22 06:43:20 <_andares> is https://en.bitcoin.it/wiki/Protocol_specification the best place to learn about the structure of the P2P network used for relaying transactions?
 36 2014-04-22 06:45:55 <gmaxwell> _andares: probably; there isn't much to learn. It's a flooding network with a lightweight inventory/response structure.
 37 2014-04-22 06:46:54 <_andares> I was interested in how peer discovery works
 38 2014-04-22 06:47:09 <_andares> I have much to learn about P2P networks
 39 2014-04-22 06:49:10 <gmaxwell> In bitcoin peer discovery also works via flooding
 40 2014-04-22 06:50:00 <warren> ping wumpus
 41 2014-04-22 06:51:21 <_andares> gmaxwell: so there's some starting peers, and it sends a message asking for everyone within X hops to return their friends?
 42 2014-04-22 06:51:44 <gmaxwell> _andares: it asks ever peer it talks to to tell it about some peers that peer knows about.
 43 2014-04-22 06:52:13 <sipa> peers are found through: the command line, a hardcoded list, dns seeds, a peer database and peer gossiping
 44 2014-04-22 06:52:30 <sipa> well, all of them just add entries to the peer database
 45 2014-04-22 06:52:34 <gmaxwell> sipa: also addr.txt if available.
 46 2014-04-22 06:52:43 <sipa> still?
 47 2014-04-22 06:52:57 <sipa> i haven't encountered the code for that in a long time
 48 2014-04-22 06:52:58 <gmaxwell> hm. I guess we lost that feature. :)
 49 2014-04-22 06:53:04 <_andares> and when a transction is sent, it's sent to all the peers that the client knows about, and it asks the peers to forward it as well?
 50 2014-04-22 06:53:28 <sipa> you only notify peers of a new transaction
 51 2014-04-22 06:53:37 <sipa> they'll query it from you if they are interested
 52 2014-04-22 06:53:47 <sipa> (mostly: don't know about it yet)
 53 2014-04-22 06:54:00 <sipa> and if they learn a new transaction that way, they forward it too
 54 2014-04-22 06:54:28 <_andares> like you advertise the hash of the transaction, and if it doesn't know about it, it asks you for it?
 55 2014-04-22 06:54:38 <sipa> technically: an 'inv' message is sent to announce the hash of the transaction
 56 2014-04-22 06:54:49 <sipa> they send a 'getdata' if they want to know about it
 57 2014-04-22 06:55:04 <sipa> you reply with a 'tx' message in that case
 58 2014-04-22 06:55:20 <sipa> (or, since recently, potentially a 'notfound' message)
 59 2014-04-22 06:55:50 <wumpus> warren: pong
 60 2014-04-22 06:57:39 <_andares> what will my neighbors be if I'm a node in the bitcoin network?
 61 2014-04-22 06:57:55 <_andares> (is there a distance metric, or just whomever I happen to know about?)
 62 2014-04-22 06:58:09 <Emcy_> its random
 63 2014-04-22 06:58:12 <gmaxwell> the network is randomly wired.
 64 2014-04-22 06:58:22 <gmaxwell> (which generally has good and important properties)
 65 2014-04-22 06:58:30 <_andares> the way hash distance is used in a DHT?
 66 2014-04-22 06:58:38 <Emcy_> well there is the backbone thing. not quite random no more
 67 2014-04-22 06:59:02 <gmaxwell> Emcy_: that isn't part of the network, its just _additional_ peerings people have manually configured.
 68 2014-04-22 06:59:16 <sipa> _andares: bitcoin does not use any kind of DHT
 69 2014-04-22 06:59:23 <_andares> I understand that.
 70 2014-04-22 06:59:28 <gmaxwell> _andares: No, not the way hash distance is used in a DHT. There is no locality in bitcoin and no need for any locality. There is no routing.
 71 2014-04-22 06:59:48 <sipa> distance is since hops
 72 2014-04-22 06:59:52 <sipa> *simply
 73 2014-04-22 07:00:38 <_andares> do I consider all nodes I found about in my getaddr() requests as my peers?
 74 2014-04-22 07:00:59 <Emcy_> you get 8 random nodes by default
 75 2014-04-22 07:01:29 <Emcy_> the randomness is important to mitigate anyone trying to tell fibs to your node
 76 2014-04-22 07:01:29 <sipa> there is a background thread that tries to maintain (up to) 8 outgoing connections
 77 2014-04-22 07:01:42 <sipa> if there are less, a more-or-less-random peer from the peer database is pickec
 78 2014-04-22 07:01:52 <sipa> there are some intentional biases in which are picked
 79 2014-04-22 07:02:07 <sipa> like not connecting to more than one peer in the same /16 IPv4 block
 80 2014-04-22 07:02:58 <_andares> how does randomness keep people from telling you fibs? because an attacker can't easily cut off and control a pocket of the network?
 81 2014-04-22 07:04:08 <gmaxwell> _andares: the randomness doesn't prevent lying. Bitcoin nodes validate everything and do not trust their peers.  The topology does, however, make partitioning difficult.
 82 2014-04-22 07:05:23 <_andares> have there been any serious attacks against the P2P network?
 83 2014-04-22 07:05:50 <warren> sipa: you intend for 4048 and 4076 to be in 0.9.2?
 84 2014-04-22 07:06:48 <gmaxwell> _andares: does serious imply effective?
 85 2014-04-22 07:08:02 <_andares> or noteworthy in some other way, such as being ineffective but coordinated
 86 2014-04-22 07:09:02 <gmaxwell> There have been attacks, none have been effective.  Some of them have severely harmed 'altcoins' which forked old bitcoin code and have not kept up with changes.
 87 2014-04-22 07:09:11 <_andares> it seems that Sybil attacks are less effective, due to a flooding architecture rather than a routing protocol like DHTs emply
 88 2014-04-22 07:10:38 <gmaxwell> DHTs are almost universally completely vulnerable to attacks like that, and I personally believe that if Bitcoin were structured like a common DHT it would have been taken out by attacks a long time ago.
 89 2014-04-22 07:11:05 <_andares> that's why I was curious about the structure of the protocol
 90 2014-04-22 07:11:07 <Emcy_> there were some node crashing attacsk wernt there
 91 2014-04-22 07:11:55 <gmaxwell> (and as a result of DHT's being the only kind of distributed system many people have ever heard of they are often invoked as some kind of magical distributed system cure all, much to my own irritation; since in our case they involve vulnerabilities we are structurally immune to)
 92 2014-04-22 07:12:49 <_andares> could an attacker with a botnet disrupt the network by spinning up a few thousand uncooperative peers?
 93 2014-04-22 07:13:26 <_andares> I guess all 8 peers the clients would be connected to would have to be malicious
 94 2014-04-22 07:13:33 <gmaxwell> a few thousand? unlikely. With enough, it could disrupt new nodes at least.
 95 2014-04-22 07:13:34 <_andares> and since the selection is random it's very unlikely to occur
 96 2014-04-22 07:13:54 <gmaxwell> though that disruption can be manually avoded by simply adding some known friend peers manually.
 97 2014-04-22 07:14:38 <_andares> hm. it could have when the network was smaller, back when only a few hundred nodes were on the network wouldn't it?
 98 2014-04-22 07:14:39 <Emcy_> good nodes eventually ban shitty ones
 99 2014-04-22 07:14:43 <_andares> or do the good properties of randomness scale down?
100 2014-04-22 07:15:10 <gmaxwell> Emcy_: only if they're detectably bad.
101 2014-04-22 07:15:16 <gmaxwell> _andares: it's relative, you can compute the propbability of connecting to all bad nodes given a certian proportion of bad nodes in the network.
102 2014-04-22 07:15:24 <Emcy_> if you suddenly made thousands of bad nodes, you could probably shit things up for a good while? until they got banned out enough
103 2014-04-22 07:15:33 <Emcy_> then the mother of all reorgs or something
104 2014-04-22 07:15:44 <sipa> they can just not relay anything
105 2014-04-22 07:15:45 <gmaxwell> If you connect to add bad nodes you'll be 'disrupted' by virtue of being isolated, which— in general— isn't terribly harmful, but its a denial of serice.
106 2014-04-22 07:15:54 <sipa> we won't consider that 'bad'
107 2014-04-22 07:17:30 <gmaxwell> (partitioning miners is worse, but it's much harder to partition them as they tend to be long lived nodes, and large ones have manual peerings in addition to the random ones)
108 2014-04-22 07:24:54 <Emcy_> does the 8 random outgoing connections really not have any security benefit? I understand your node checks all chain stuff anyway
109 2014-04-22 07:25:19 <Emcy_> what about mempool stuff
110 2014-04-22 07:26:37 <tg2> oi
111 2014-04-22 07:26:46 <xdotcommer> tg2: welcome
112 2014-04-22 07:26:54 <sipa> Emcy_: one good peer is enough
113 2014-04-22 07:27:00 <tg2> question about high volume transaction processing
114 2014-04-22 07:27:04 <sipa> Emcy_: that's all the benefit 8 peers has: making it hard for them to be all bad
115 2014-04-22 07:27:37 <tg2> if I wanted to listen for potentially 100 transactions in a very short time (say within 5 seconds)
116 2014-04-22 07:27:42 <tg2> what is the best way to do this with bitcoind?
117 2014-04-22 07:27:52 <tg2> --walletnotify doesn't seem to scale well in testing
118 2014-04-22 07:28:15 <sipa> i'd say use something like pynode behind bitcoind
119 2014-04-22 07:28:37 <tg2> generated by bitocind?
120 2014-04-22 07:28:37 <tg2> so somethign that is manually parsing the disk blocks?
121 2014-04-22 07:28:43 <sipa> well, 'manually'... there are enough tools for that
122 2014-04-22 07:28:55 <tg2> worth memory hooking bitcoind to listen for txn receives?
123 2014-04-22 07:29:09 <sipa> memory hooking?
124 2014-04-22 07:29:32 <tg2> yeah
125 2014-04-22 07:29:47 <xdotcommer> sipa: pynode seems abandoned
126 2014-04-22 07:30:22 <tg2> > Script verification is a separate, manual
127 2014-04-22 07:30:23 <tg2> process (testscript.py).
128 2014-04-22 07:30:25 <tg2> :\
129 2014-04-22 07:30:48 <sipa> you don't need script verification; bitcoind does that for you
130 2014-04-22 07:31:35 <tg2> does pynode need a running bitcoind instance?
131 2014-04-22 07:31:50 <tg2> or would that just be used to verify txn confirmations etc
132 2014-04-22 07:32:04 <sipa> no, it just speaks the p2p protocol
133 2014-04-22 07:32:39 <sipa> (i said "something like pynode"; there are many alternatives)
134 2014-04-22 07:32:58 <sipa> but whatever you do, you want to run in behind a trusted bitcoind if you're receiving transactions
135 2014-04-22 07:33:59 <tg2> know of any alternatives to pynode?
136 2014-04-22 07:38:21 <warren> wumpus: Regarding #4042, what he wants to add are pretty much A == A sanity checks and things to automatically watch out for future added symbols.  I personally would just ACK the current commits and ask for the further work to be added in the next PR.
137 2014-04-22 07:47:49 <sipa> warren: #4048 should be doable for 0.9.2; for #4076 maybe people will want more thorough review as it's consensus-critical
138 2014-04-22 07:51:47 <warren> can we mark the likely PR's with a 0.9.2 milestone?
139 2014-04-22 07:51:57 <wumpus> has already been done...
140 2014-04-22 07:52:14 <wumpus> haven't included #4048 there as it doesn't really add any functionality or fix a bug
141 2014-04-22 07:52:28 <sipa> yeah, don't care much about it
142 2014-04-22 07:52:50 <sipa> just a "if it's ready, no reason not to include it", as it seems 0.9.2 will be from master?
143 2014-04-22 07:53:04 <gmaxwell> sipa: I haven't acked 4076 yet mostly because we don't have a unit test for ComputeMinWork and I wanted to think harder about corner cases there.
144 2014-04-22 07:53:07 <wumpus> it's nice to have it tested but 0.9.2 is not meant as a release to test stuff
145 2014-04-22 07:53:18 <sipa> wumpus: ok
146 2014-04-22 07:53:37 <wumpus> yes, 0.9.2 will be from master, I sent around a mail about it
147 2014-04-22 07:54:20 <warren> I'm aborting work on the macosx gitian stuff for today and just finishing the announcement
148 2014-04-22 07:54:26 <warren> gitian needs a lot more work
149 2014-04-22 07:54:46 <wumpus> all the 'get rid of openssl' changes can be merged after 0.9.2 is branched
150 2014-04-22 07:55:17 <sipa> wumpus: ok, so we're now effectively in a 0.9.2 merge window; good to know
151 2014-04-22 07:55:29 <gmaxwell> I'm fine with merging all of them for master but wouldn't feel comfortable with 0.9.2 without a bit more review.
152 2014-04-22 07:56:03 <warren> 3 weeks until feature and string freeze and RC.
153 2014-04-22 07:56:15 <wumpus> sipa: I thnk it's the easiest way to do it; branching 0.9.2 off now would be possible, too, but then some pulls have to be merged into both branches
154 2014-04-22 07:56:21 <warren> hopefully 1 week of testing.  can be extended if more changes are needed.
155 2014-04-22 07:56:39 <gmaxwell> (well the base58 stuff I'm already fine with 0.9.2 as its not consensus critical and was easy to review)
156 2014-04-22 07:56:40 <sipa> wumpus: ok
157 2014-04-22 07:57:12 <wumpus> gmaxwell: ok, let's just merge the base58 one then, I'm fine with it too
158 2014-04-22 07:57:32 <warren> has anyone figured out what was causing testnet nodes to hard fork and fall behind?
159 2014-04-22 07:57:42 <sipa> getting rid of openssl entirely will also require: sha1/sha256/sha512/ripemd160 hash implementations, libsecp256k1, and a pseudo RNG
160 2014-04-22 07:58:17 <archrs> NaCl?
161 2014-04-22 07:58:23 <gmaxwell> warren: huh?
162 2014-04-22 07:58:49 <warren> gmaxwell: 2-3 weeks ago testnet nodes fell behind for me and hno
163 2014-04-22 07:59:01 <warren> gmaxwell: in hno's case it was 0.8.6 and 0.9.0.  in my case it was master
164 2014-04-22 07:59:02 <gmaxwell> mine didn't.
165 2014-04-22 07:59:07 <gmaxwell> Any more information?
166 2014-04-22 07:59:32 <warren> hmm, I have testnet3/ frozen at that point, let me see if it fails to recover
167 2014-04-22 08:01:48 <sipa> heh, seems i got a 2600 uBTC/bit/ubit/xbit/XBT/mike/... tip for a commit
168 2014-04-22 08:02:08 <gmaxwell> archrs: doesn't have ripemd160, doesn't have a random pool, I think it doesn't have sha1, basically all it has that we need is bogstandard sha256/sha512 implementations, which is fine but they're only a couple hundred lines of code.   We also need an implementation of the openssl kdf function and aes, though not in a disable wallet build which is I think the first phase goal for no-openssl.
169 2014-04-22 08:02:42 <gmaxwell> sipa: yea I've gotten those too.  took me a while to figure out what those payments were.
170 2014-04-22 08:03:03 <wumpus> sipa: I even got some litecoins a while ago for a commit!
171 2014-04-22 08:03:06 <gmaxwell> esp since they happen at merge time, and other people were merging my patches at random time. Wasn't until I merged one of my own did I figure it out.
172 2014-04-22 08:04:01 <wumpus> sipa: at last a small compensation for all the copying of our commits to altcoin repositories :p
173 2014-04-22 08:04:10 <sipa> ha, on their site you can get a list of commits they were for
174 2014-04-22 08:04:17 <sipa> wth, i got one for adding some release note lines
175 2014-04-22 08:04:33 <sipa> and for increasing the default dbcache size
176 2014-04-22 08:04:45 <gmaxwell> go go warped incentives.
177 2014-04-22 08:04:45 <wumpus> yes, they reward for any commit, there is no vetting
178 2014-04-22 08:04:55 <warren> http://togami.com/~warren/temp/fail.txt   Here's the point where testnet failed
179 2014-04-22 08:05:02 <gmaxwell> warren: I don't see any failure there.
180 2014-04-22 08:05:37 <gmaxwell> warren: looks like there was a reorg and it should have continued after the next block caused it to link back, or something like that.
181 2014-04-22 08:06:04 <gmaxwell> Dunno what those super annoying ping messages are all about probably some nussance test node with a misimplemented ping.
182 2014-04-22 08:06:44 <sipa> wumpus: i have received a few more significant tips before
183 2014-04-22 08:07:02 <warren> gmaxwell: I left my other node running for 2 days after this and it remained stuck at this point
184 2014-04-22 08:07:29 <warren> anyone have a fast testnet peer I can connect to?
185 2014-04-22 08:07:56 <gmaxwell> warren: having logs of the future past that point would be helpful then.
186 2014-04-22 08:08:01 <gmaxwell> it doesn't appear to be rejecting any blocks.
187 2014-04-22 08:08:14 <warren> sadly that node is gone now
188 2014-04-22 08:08:33 <sipa> i always like post-merge pulltester reports
189 2014-04-22 08:10:35 <wumpus> sipa: always very reassuring
190 2014-04-22 08:10:41 <warren> connected to 12 testnet peers and still stuck right now
191 2014-04-22 08:10:59 <gmaxwell> sipa: I did actually test it again myself before merging it. :) Besides, if it failed you'd get paid for another commit.
192 2014-04-22 08:11:27 <gmaxwell> warren: what does "still stuck" mean? has it been on continiously while testnet has recieved new blocks? what is it logging?
193 2014-04-22 08:11:50 <warren> gmaxwell: only started it again a few minutes ago
194 2014-04-22 08:13:00 <olalonde> I've had some trouble connecting to testnet as well recently
195 2014-04-22 08:15:06 <sipa> my testnet node is at 00000000ad44071ceeecddb2e9562109f6d876ee018fd6355dab8738b1e0d54c (226004)
196 2014-04-22 08:17:32 <gmaxwell> olalonde: connecting is almost always problematic. there aren't really enough reachable testnet nodes.
197 2014-04-22 08:18:23 <olalonde> right... to be honest, I'm not even sure mine is reachable. I have setup port forwarding right?
198 2014-04-22 08:18:24 <warren> 2014-04-22 08:15:22 ProcessBlock: ORPHAN BLOCK 0, prev=00000000ad44071ceeecddb2e9562109f6d876ee018fd6355dab8738b1e0d54c
199 2014-04-22 08:18:27 <gmaxwell> mine is now at 000000000000821fb5b632b433454fb95830dd5e11b73a69ac6f1310a5e91df3 226005 but my 226004 is the same as sipas.
200 2014-04-22 08:20:02 <olalonde> gmaxwell: btw, seems Vault of Satoshi is the first exchange to implement proof of solvency in a standard way http://www.reddit.com/r/Bitcoin/comments/23m1de/vault_of_satoshi_launches_full_public_proof_of/ (in case you didn't get that news yet)
201 2014-04-22 08:20:27 <warren> gmaxwell: is 000000000001bf838a2364dd6598d0b3331f87416024f1c321cc59e153d8e01d in your chain?
202 2014-04-22 08:21:18 <devrandom> warren: because it's non-perfect... pull requests solicited
203 2014-04-22 08:25:58 <warren> 2014-04-22 08:21:33 ProcessBlock: ORPHAN BLOCK 321, prev=000000000000889284f25cea00e8ef7bfaef2dc95bf725904f60f8ce03aea6a7
204 2014-04-22 08:26:04 <warren> I'll leave this running for another day
205 2014-04-22 08:28:58 <maaku> thanks for the review sipa
206 2014-04-22 08:31:23 <gmaxwell> warren: no, it's an orphan.
207 2014-04-22 08:32:06 <warren> this node is on     "blocks" : 224679,
208 2014-04-22 08:32:30 <warren> gmaxwell: is it a bug that it's stuck on a shorter chain?
209 2014-04-22 08:34:35 <gmaxwell> yes.
210 2014-04-22 08:34:49 <gmaxwell> assuming its not just due to your peers having no better.
211 2014-04-22 08:35:02 <warren> I'm connected to my local peer which is equal to you and sipa
212 2014-04-22 08:35:47 <gmaxwell> I traced that fork back, and the first block on the losing side of the fork is 000000000001ec136896f4d0b554e991394973ee6e070a21b44b809a4bea1d0a
213 2014-04-22 08:36:01 <gmaxwell> 1876 blocks ago from the perspective of my node.
214 2014-04-22 08:36:18 <gmaxwell> warren: what code are you running?
215 2014-04-22 08:37:30 <warren> gmaxwell: fecda6853d9bbc3b6df13e48cb0283e7c8ab7d52.  should I upgrade to master and try again?
216 2014-04-22 08:38:03 <gmaxwell> no. whatever do don't lose the state of your current node.
217 2014-04-22 08:38:22 <gmaxwell> fecda6853d9bbc3b6df13e48cb0283e7c8ab7d52. isn't in my git tree here so I don't know what that is.
218 2014-04-22 08:38:45 <gmaxwell> (the git describe version number might be helpful! :P)
219 2014-04-22 08:38:45 <warren> commit fecda6853d9bbc3b6df13e48cb0283e7c8ab7d52
220 2014-04-22 08:38:46 <warren> Author: Wladimir J. van der Laan <laanwj@gmail.com>
221 2014-04-22 08:38:46 <warren> Date:   Thu Apr 3 13:50:44 2014 +0200
222 2014-04-22 08:38:46 <warren> Merge: 952bf97 4c35366
223 2014-04-22 08:38:46 <warren>     Merge pull request #3929
224 2014-04-22 08:39:17 <warren> it's in master
225 2014-04-22 08:39:26 <gmaxwell> oh my error, its past my bedtime, the search I did included the .
226 2014-04-22 08:39:46 <warren> ok, stop the node and make a backup copy?
227 2014-04-22 08:39:55 <gmaxwell> can you please?
228 2014-04-22 08:39:58 <warren> ok
229 2014-04-22 08:40:24 <gmaxwell> I don't recall any changes which would have impacted the sync logic.
230 2014-04-22 08:40:43 <warren> wumpus mentioned there was a sipa change recently?
231 2014-04-22 08:41:26 <gmaxwell> in any case, get a backup ... I'll research more later, perhaps try search to see if there is anything odd about that hash I gave you which was the first in that long fork you can't seem to reorg off of.
232 2014-04-22 08:41:53 <gmaxwell> warren: ah, perhaps, in that case, feel free to backup and try master.
233 2014-04-22 08:41:55 <warren> making backup copy
234 2014-04-22 09:05:50 <fanquake> ;;blocks
235 2014-04-22 09:05:51 <gribble> 297118
236 2014-04-22 09:41:41 <wallet42> what happens if a p2sh script containing a 2/3 multsisig with 2 valid and 1 invalid public key is tried to get spend?
237 2014-04-22 09:42:23 <wallet42> and is it a difference if the bad pubkey is first or last
238 2014-04-22 09:43:46 <sipa> i think it is allowed
239 2014-04-22 09:59:54 <warren> anyone else want the backup of testnet3 datadir that is unable to recover?
240 2014-04-22 10:05:44 <warren> gmaxwell: restarted with master ... still failing to recover
241 2014-04-22 10:11:49 <warren> wumpus: sorry I lost notes from earlier, how do I generate the source strings again?  lupdate normally work with a .pro file
242 2014-04-22 10:20:24 <wumpus> warren: man, why do you ask this every day?
243 2014-04-22 10:20:38 <wumpus> warren: just read the translation process
244 2014-04-22 10:20:45 <warren> ah crap, sorry
245 2014-04-22 10:45:59 <hilostitch> Hi all. Very interested in Bitcoin programming. What do i need to know, programming wise, to be able to be useful in bitcoin development? what programming languages and libraries do i need to perfect out first? Please, help if you can
246 2014-04-22 10:49:35 <SomeoneWeird> hilostitch, the reference client is C++
247 2014-04-22 10:49:54 <SomeoneWeird> but you can develop bitcoin applications in any language
248 2014-04-22 10:56:46 <hilostitch> SomeoneWeird: So i just need to have a very deep knowledge in c++?
249 2014-04-22 10:56:55 <SomeoneWeird> basically
250 2014-04-22 10:57:09 <hilostitch> what about QT and boost?
251 2014-04-22 10:59:41 <phoenix521> ±±±±±±±±±±±±±
252 2014-04-22 11:17:49 <cdecker> BlueMatt: ping
253 2014-04-22 11:46:39 <warren> wumpus: should I kick off the nightly builder, you done merging?
254 2014-04-22 11:49:07 <warren> devrandom: http://www.gitian.com/  wow.
255 2014-04-22 11:49:19 <wumpus> warren: I'm never done merging
256 2014-04-22 11:49:49 <wumpus> warren: why not set a fixed time to kick off the nightly builder
257 2014-04-22 11:50:20 <warren> wumpus: it does have a fixed time, it skipped most of it because nothing changed from the previous build
258 2014-04-22 11:59:43 <wumpus> well in that case feel free to kick it off, I don't intend to merge anything immediately right now
259 2014-04-22 12:02:31 <fanquake> wumpus gitian is .org no?
260 2014-04-22 12:04:04 <warren> gitian.com has flash =)
261 2014-04-22 12:04:33 <fanquake> gitian.com made my browser cry
262 2014-04-22 12:04:37 <kinlo> it's .org yes
263 2014-04-22 12:05:31 <sipa> gitian.com says 404 here
264 2014-04-22 12:12:43 <kinlo> sipa: you need to prepend www. to get all the sad stuff :)
265 2014-04-22 12:18:57 <warren> wumpus: please review draft one more time
266 2014-04-22 12:22:38 <warren> wumpus: nightly includes only 4042 now
267 2014-04-22 12:30:51 <wumpus> looks fine to me
268 2014-04-22 13:45:46 <fluffypony> I have a question about accounts (I'm probably missing a clue somewhere here) - the wiki says inter-account moves are not broadcast and never incur a fee, but then surely the current balance on an address found by traversing the blockchain could be incorrect if the balance was moved to a different account (and thus a different address)?
269 2014-04-22 13:46:27 <sipa> fluffypony: accounts are not addresses
270 2014-04-22 13:46:30 <wumpus> accounts are internal bookkeeping, they are indeed never broadcast (and don't need to be)
271 2014-04-22 13:46:52 <sipa> they're just been counter ("how much of my wallet balance belongs to X")
272 2014-04-22 13:46:57 <sipa> *bean counters
273 2014-04-22 13:47:05 <fluffypony> ah
274 2014-04-22 13:47:18 <sipa> and not related at all to which coins you have, or which addresses those are assigned to
275 2014-04-22 13:47:27 <Luke-Jr> fluffypony: addresses don't have balances either
276 2014-04-22 13:47:35 <fluffypony> so "Each account is associated with zero or more receiving addresses, and every receiving address is associated with exactly one account." - what about moving between accounts when those accounts are associated with different balances
277 2014-04-22 13:48:06 <Luke-Jr> fluffypony: that's not phrased the best
278 2014-04-22 13:48:11 <wumpus> the addresses associated to accounts are only used for one thing: to add the incoming amount on that address to the balance of that account
279 2014-04-22 13:48:12 <Apocalyptic> you shouldn't rely on accounts anyway
280 2014-04-22 13:48:16 <Luke-Jr> addresses are associated to accounts, but the inverse is not true
281 2014-04-22 13:48:18 <sipa> fluffypony: so, if an address X is associated with account A, it means that payments to address X increment A's balance
282 2014-04-22 13:48:22 <Apocalyptic> and they are to be removed soon I heard
283 2014-04-22 13:48:31 <sipa> fluffypony: but there are other things that can modify their balance
284 2014-04-22 13:48:43 <wumpus> after the coins have come in on an address they don't have any assoiciation to the account anymore
285 2014-04-22 13:48:50 <fluffypony> ok got it
286 2014-04-22 13:48:55 <wumpus> Apocalyptic: yes
287 2014-04-22 13:48:57 <Luke-Jr> yeah, what wumpus and Apocalyptic said - accounts are going away anyhow
288 2014-04-22 13:49:01 <Luke-Jr> so don't use them :P
289 2014-04-22 13:49:07 <fluffypony> I wasn't going to
290 2014-04-22 13:49:14 <wumpus> Apocalyptic: and because of this kind of confusing
291 2014-04-22 13:50:41 <Luke-Jr> well, it's confusing because of stupid websites like blockchain.info
292 2014-04-22 13:50:51 <sturles> Luke-Jr: This will mean large changes to the RPC interface.  Is there an overview?  Many calls require an account parameter.  And I find accounts very useful, and will miss the feature. :-(
293 2014-04-22 13:50:55 <Luke-Jr> which make people think addresses are wallets/accounts and have balances
294 2014-04-22 13:51:12 <Luke-Jr> sturles: there's no safe way to use them right now, unfortunately.
295 2014-04-22 13:51:19 <Luke-Jr> sturles: and they conflict with Bitcoin-Qt's labels
296 2014-04-22 13:51:28 <sturles> Oh.
297 2014-04-22 13:51:33 <wumpus> sturles: current plan is for a RPC interface 2.0, that removes the account functionality (as well as cleans up other things)
298 2014-04-22 13:51:35 <Luke-Jr> sturles: maybe after they're removed, someone will add them back in a new form that is safe
299 2014-04-22 13:51:53 <wumpus> Luke-Jr: but probably not; they belong at a level above bitcoind
300 2014-04-22 13:52:02 <Luke-Jr> wumpus: a level above bitcoind cannot do it as well
301 2014-04-22 13:52:13 <wumpus> Luke-Jr: then that should be facilitated
302 2014-04-22 13:52:16 <Luke-Jr> agreed
303 2014-04-22 13:52:47 <wumpus> everyone that wants to use the account system wants something else, or thinks it's something else, and it's a burden to maintain (has some of the worst code in bitcoind)
304 2014-04-22 13:53:06 <Luke-Jr> yeah, I wouldn't dare suggest use the existing code in any case :P
305 2014-04-22 13:53:19 <wumpus> (or: least understood/tested)
306 2014-04-22 13:54:01 <sturles> I use them for escrow accounts (make sure I don't touch escrow funds by accident), for various accounting purposes, and to keep coins for an intended purpose separate from the rest.  Makes it very easy to stay in control, since more than one wallet on the same computer is impossible.
307 2014-04-22 13:54:21 <Luke-Jr>  (make sure I don't touch escrow funds by accident), <-- this doesn't make sense for bitcoind accounts
308 2014-04-22 13:54:24 <sipa> sturles: you know accounts have nothing to do with coin control right?
309 2014-04-22 13:54:37 <Luke-Jr> bitcoind WILL let you bring other accounts negative, so you still end up "touching" the funds
310 2014-04-22 13:54:39 <sipa> it doesn't keep coins separate by any means
311 2014-04-22 13:54:46 <wumpus> sturles: multiple wallets should be possible at some point
312 2014-04-22 13:55:11 <Luke-Jr> … since more than one wallet on the same computer is impossible. <-- not impossible
313 2014-04-22 13:55:23 <sipa> pretty hard, right now, though
314 2014-04-22 13:55:28 <sturles> Luke-Jr: Yes, if you use sendtoaddress instead of sendfrom, so I don't.
315 2014-04-22 13:55:30 <wumpus> it's certainly possible if you run SPV wallets against one bitcoind process
316 2014-04-22 13:55:36 <wumpus> but not with the bitcoin core wallet...
317 2014-04-22 13:55:43 <sturles> sipa: Yesm I know that.
318 2014-04-22 13:56:02 <sipa> sturles: i don't understand
319 2014-04-22 13:56:05 <Luke-Jr> sipa: he's talking about a high-level view.
320 2014-04-22 13:56:16 <Luke-Jr> sipa: his coins aren't UTXOs, just bitcoin quantities
321 2014-04-22 13:56:23 <chairman_meow> has there ever been stolen bitcoins but were reversed by the devs via a hard fork on the block chain?
322 2014-04-22 13:56:29 <wumpus> chairman_meow: no
323 2014-04-22 13:56:33 <sturles> sipa: The purpose is not to avoid using the actual output, just to make sure I have the coins in reserve.
324 2014-04-22 13:56:37 <Luke-Jr> chairman_meow: sortof, but not really
325 2014-04-22 13:56:57 <Luke-Jr> chairman_meow: closest was https://en.bitcoin.it/wiki/CVEs#CVE-2010-5139
326 2014-04-22 13:57:21 <wumpus> Luke-Jr: that's a strange definition of 'stolen'
327 2014-04-22 13:57:24 <sipa> chairman_meow: doing so would require cooperation of at least a majority of mining power
328 2014-04-22 13:57:26 <Luke-Jr> wumpus: hence "not really" :D
329 2014-04-22 13:57:50 <sipa> chairman_meow: and if it's returning funds without rolling back the entire blockchain, it would require cooperation of *everyone*
330 2014-04-22 13:58:16 <Luke-Jr> [13:57:24] <sipa> chairman_meow: doing so would require cooperation of at least a majority of mining power <-- and that mining power accepting a huge loss of their own income..
331 2014-04-22 13:58:16 <sipa> (and i hope that such a thing would be so controversial that it's impossible to convince 100%)
332 2014-04-22 14:54:40 <BlueMatt> cdecker: pong
333 2014-04-22 14:54:51 <cdecker> Hi BlueMatt
334 2014-04-22 14:55:06 <cdecker> Just noticed your DNS seed isn't doing so well
335 2014-04-22 14:56:16 <BlueMatt> hmm, willfix
336 2014-04-22 14:56:43 <cdecker> Just thought I'd mention it since I still haven't implemented automatic notifications
337 2014-04-22 14:56:44 <cdecker> :D
338 2014-04-22 14:57:31 <BlueMatt> thanks
339 2014-04-22 15:09:05 <gpmnlxdw> hi Guys, sorry to ask for help again .....
340 2014-04-22 15:09:07 <gpmnlxdw> bitcoind decoderawtransaction 77794362d66918f7b6b7d949e4e04f8e2de3809eb3a2a32afc114c5560015c59
341 2014-04-22 15:09:08 <gpmnlxdw> error: {"code":-22,"message":"TX decode failed"}
342 2014-04-22 15:09:28 <gpmnlxdw> but I promise I have tested it several days before in my pc
343 2014-04-22 15:09:58 <sipa> that is certainly not a valid transaction
344 2014-04-22 15:10:15 <gpmnlxdw> https://blockchain.info/tx/77794362d66918f7b6b7d949e4e04f8e2de3809eb3a2a32afc114c5560015c59
345 2014-04-22 15:10:21 <gpmnlxdw> here I can see it
346 2014-04-22 15:10:30 <cdecker> Was just about to post the link myself
347 2014-04-22 15:10:30 <sipa> that is a transaction id
348 2014-04-22 15:10:33 <sipa> not a transaction
349 2014-04-22 15:10:36 <cdecker> Ah right :D
350 2014-04-22 15:11:23 <gpmnlxdw> ok, I see .... I'd check my code now
351 2014-04-22 15:11:59 <gpmnlxdw> so wired, I did not change any piece of related code in recent days
352 2014-04-22 15:30:45 <gpmnlxdw> it is because this command failed: bitcoind getrawtransaction 77794362d66918f7b6b7d949e4e04f8e2de3809eb3a2a32afc114c5560015c59
353 2014-04-22 15:30:46 <gpmnlxdw> error: {"code":-5,"message":"No information available about transaction"}
354 2014-04-22 15:31:02 <gpmnlxdw> is it because my bitcoin.conf do not have txindex=1?
355 2014-04-22 15:34:05 <sipa> yes
356 2014-04-22 15:34:40 <gpmnlxdw> I'm using bitcoind -daemon, and I have set txindex=1 in bitcoin.conf
357 2014-04-22 15:35:17 <gpmnlxdw> is there anything need to do to change from bitcoin-qt to bitcoind?
358 2014-04-22 15:35:34 <sipa> no
359 2014-04-22 15:41:11 <gpmnlxdw> maybe it is because I disabled 8332 port in iptables .....
360 2014-04-22 15:41:24 <gpmnlxdw> only 8332 required, is it?
361 2014-04-22 15:41:45 <sipa> 332 for RPC, 8333 for P2P
362 2014-04-22 15:42:19 <gpmnlxdw> 8332, right?
363 2014-04-22 15:42:35 <gpmnlxdw> 8332 rpc , 8333 p2p
364 2014-04-22 15:42:39 <gpmnlxdw> right？
365 2014-04-22 15:43:05 <gpmnlxdw> ok, I get it by netstat -nap, thanks !
366 2014-04-22 16:02:00 <gpmnlxdw> reindexing .....
367 2014-04-22 16:56:07 <giustoXricordarl> imparami sto ballo per la prossima sett. http://youtu.be/RjG-podqbl8
368 2014-04-22 17:04:29 <maaku> sipa: should I move CompressAmount and DecompressAmount into util.cpp if CCompressedMoney will be using them too?
369 2014-04-22 18:10:35 <sipa> maaku: i would move them into CCompressedMoney, and only use CCompressedMoney (but maybe not immediately)
370 2014-04-22 18:11:52 <maaku> ah of course
371 2014-04-22 18:33:07 <fedora-newbie_> Hello
372 2014-04-22 18:33:18 <fedora-newbie_> Anyone knows if I can run any wallet on Fedora systems?
373 2014-04-22 18:39:25 <Ry4an> wrong channel.  User help goes in #bitcoin.
374 2014-04-22 18:40:02 <fedora-newbie_> thanks (:
375 2014-04-22 19:28:46 <Newyorkadam> hey, does anyone here experienced with the blockchain?
376 2014-04-22 19:28:55 <Newyorkadam> is my thinking correct here?
377 2014-04-22 19:28:56 <Newyorkadam> Think about it — probably about .1% (or 1/1000) of people in the world use bitcoin. In just 3 years, the blockchain is already at 16 gigabytes and takes a week to load (approximations). Now, that means every year, 5.33 gigabytes and 2.3 days of waiting time are added. But that's if just .1% of people; imagine if 50% of the population were using it. That would mean 500 times as many people would be making transactions, so
378 2014-04-22 19:28:57 <Newyorkadam> that's 2665 gigabytes per day and 1,150 days of waiting time added per day.
379 2014-04-22 19:29:49 <maaku> Newyorkadam: (a) there are software-enforced scaling limits, (b) current bitcoind performance does not reflect theoretically possible
380 2014-04-22 19:30:10 <Newyorkadam> maaku: I get a, why b?
381 2014-04-22 19:30:23 <maaku> Newyorkadam: because bitcoind is not as efficient as it could be?
382 2014-04-22 19:30:43 <Newyorkadam> ok
383 2014-04-22 19:30:46 <Newyorkadam> thanks :)
384 2014-04-22 19:32:16 <gmaxwell> Newyorkadam: it's really rude to multicast these questions in multiple channels.
385 2014-04-22 19:32:45 <edcba> yeah that's why things don't scale !
386 2014-04-22 19:33:15 <gmaxwell> With just the synchronization stalls corrected the current codebase syncs the whole chain in 150 minutes, on a quad core i7 desktop.
387 2014-04-22 19:33:19 <gmaxwell> FWIW
388 2014-04-22 19:33:24 <Newyorkadam> sorry
389 2014-04-22 19:34:07 <edcba> 150 minutes for 16 GB ?
390 2014-04-22 19:34:38 <gmaxwell> edcba: to sync over the network from 0, yes.
391 2014-04-22 19:35:02 <edcba> ok so bandwidth may be more problematic for most
392 2014-04-22 19:37:07 <jcorgan> hmm, maybe i have fast machines, my clone-over-GbE only takes 1-1.5 hours
393 2014-04-22 19:37:28 <jcorgan> but i haven't done that too recently
394 2014-04-22 19:43:32 <gmaxwell> jcorgan: I was surprised by how long it took, I started looking for regressions.
395 2014-04-22 19:43:55 <gmaxwell> I tried benchmarking again but lost power in the middle of it (blew a breaker, doh)
396 2014-04-22 21:18:48 <hearn> yay, more SSL bugs
397 2014-04-22 21:18:52 <hearn> this time it’s apple’s turn again
398 2014-04-22 21:19:31 <hearn> 
ACTION reconsidering SSL between nodes as a good idea

399 2014-04-22 21:19:44 <rnicoll> hearn, link?
400 2014-04-22 21:19:58 <hearn> https://threatpost.com/apple-fixes-serious-ssl-issue-in-osx-and-ios/105631
401 2014-04-22 21:20:08 <rnicoll> 
ACTION is glad that HTTP 2.0 doesn't mandate SSL for security. Okay, it doesn't but damn we fought long to get it made optional.

402 2014-04-22 21:20:09 <hearn> http://seclists.org/bugtraq/2014/Apr/135
403 2014-04-22 21:20:16 <rnicoll> cheers
404 2014-04-22 21:20:27 <hearn> it doesn’t? SPDY always used to require SSL
405 2014-04-22 21:20:34 <hearn> what was the rationale behind making it optional? software is hard?
406 2014-04-22 21:20:42 <sipa> SSL is hard
407 2014-04-22 21:20:46 <Luke-Jr> hearn: because it should be optional :P
408 2014-04-22 21:20:52 <hearn> yeah but so is HTTP :)
409 2014-04-22 21:20:55 <rnicoll> heakins, last time I read the spec, there was a way of opting out, although please don't ask me details right now, there may have been wine
410 2014-04-22 21:21:00 <Luke-Jr> HTTP is far easier than SPDY :p
411 2014-04-22 21:21:06 <hearn> one of the other bugs in that patch set is something like, you can terminate a connection before a header line is complete and it’ll still be processed