1 2011-12-18 00:01:15 <jm9000> If a thin client downloads headers only, then it has no way to protect itself against a double spend. Would that be correct?
  2 2011-12-18 00:10:16 <CIA-100> libbitcoin: genjix * r0d40ca8f5361 / (7 files in 6 dirs): blockchain::store(..., handler), handler now returns block_info{status, depth} instead of only block_status http://tinyurl.com/ck85cql
  3 2011-12-18 01:35:19 <CIA-100> libbitcoin: genjix * racc11880f7ad / (21 files in 8 dirs): set_foo/get_foo -> set_foo/foo http://tinyurl.com/7zp9oz3
  4 2011-12-18 01:35:20 <CIA-100> libbitcoin: genjix * rcd1c7aae1f4f / (5 files in 4 dirs): Removed postbind. Use boost asio strand->wrap instead. http://tinyurl.com/7p6ggmc
  5 2011-12-18 01:40:11 <BlueMatt> anyone else feel like the last couple of comments on https://github.com/bitcoin/bitcoin/pull/415 have been bots?
  6 2011-12-18 01:48:02 <diki> BlueMatt:they have avatars
  7 2011-12-18 01:48:08 <diki> if it were a bot, why bother with them>
  8 2011-12-18 01:48:09 <diki> ?
  9 2011-12-18 01:49:01 <BlueMatt> no, its not a bot it clearly specifies bitcoin-specific stuff, but I cant help but think someone is heavily encouraging people to sign up for github accounts to post +1s there...
 10 2011-12-18 01:49:22 <rjk2> i get that feeling too
 11 2011-12-18 01:52:48 <luke-jr> BlueMatt: if so, no harm in that. I wish they'd comment more on the code than concept, though
 12 2011-12-18 01:52:56 <luke-jr> ie, "I testing this, and it works"
 13 2011-12-18 01:54:37 <BlueMatt> luke-jr: not really, I just wanted to point it out, and I have a feeling the last couple may not even know how to compile code, yet alone what intricate details of bitcoin the changes might effect
 14 2011-12-18 01:54:44 <rjk2> it just appears that they are trying to give it priority because it has anonymity enhancements
 15 2011-12-18 01:55:15 <CIA-100> libbitcoin: genjix * r150cd6282dfc / (6 files in 4 dirs): compacted -> compact http://tinyurl.com/bsycye5
 16 2011-12-18 01:55:28 <luke-jr> BlueMatt: even if so, if they tested, their input is helpful
 17 2011-12-18 01:56:40 <BlueMatt> luke-jr: thats my point, I highly doubt they did
 18 2011-12-18 01:58:01 <[Tycho]> Anyone know who was the author of http://www.l0ss.net/images/PoolLuck30.png ?
 19 2011-12-18 01:58:12 <diki> next diff is definitely good
 20 2011-12-18 01:58:28 <diki> If it ever comes into existence that i
 21 2011-12-18 01:58:32 <diki> is*
 22 2011-12-18 01:58:36 <rjk2> [Tycho]: 404 not found
 23 2011-12-18 01:58:47 <BlueMatt> [Tycho]: author of a 404 page?
 24 2011-12-18 01:58:49 <[Tycho]> rjk2: that's exactly why I'm asking.
 25 2011-12-18 01:58:54 <rjk2> ah lol
 26 2011-12-18 01:58:57 <[Tycho]> BlueMatt: it's broken now.
 27 2011-12-18 01:59:38 <[Tycho]> It was so cool...
 28 2011-12-18 02:01:06 <luke-jr> BlueMatt: someone who really wants it, like Bitbills or casacius, might make binaries and encourage people to test & report
 29 2011-12-18 02:02:52 <BlueMatt> luke-jr: ok, stop making a big deal of it, I just said it was probably either non-accounts by one person, or someone pimping something to people and pointing them to comment on github (which is the wrong spot, they should make a forum thread if they want to show public support)
 30 2011-12-18 02:03:10 <BlueMatt> github is for devs to comment on its actual use not a ton of +1s all over the place that dont add anyting to the discussion
 31 2011-12-18 02:03:20 <luke-jr> &
 32 2011-12-18 02:03:23 <luke-jr> I already agreed.
 33 2011-12-18 02:03:43 <luke-jr> except for the assumption that only devs can contribute helpfully
 34 2011-12-18 02:03:53 <BlueMatt> luke-jr: I didnt say that
 35 2011-12-18 02:04:08 <BlueMatt> I said github is the place for devs, if you want to post a ton of +1's then do it on the forums
 36 2011-12-18 02:04:20 <BlueMatt> also you not agreeing with my main point doesnt mean you "already agreed"...
 37 2011-12-18 02:05:08 <luke-jr> assuming you main point is that those particular comments are spam, I agree
 38 2011-12-18 02:05:40 <BlueMatt> anyway, its a minor gripe I was expressing, nothing worth discussing
 39 2011-12-18 02:35:12 <CIA-100> libbitcoin: genjix * rc5069b26e85f / (include/bitcoin/block.hpp src/block.cpp): bool operator==(const message::block block_a, const message::block& block_b); http://tinyurl.com/78yy38c
 40 2011-12-18 05:44:33 <denisx> is it possible than some pools hold found block for some minutes to have an advantage?
 41 2011-12-18 05:44:37 <denisx> that
 42 2011-12-18 05:44:50 <gmaxwell> denisx: not unless they have >50% of the total hashpower.
 43 2011-12-18 05:45:14 <gmaxwell> (and if they do, it's not an advantage they actually need)
 44 2011-12-18 05:45:18 <denisx> why is it then that some miners flee my pool 2 minutes before I get the block?
 45 2011-12-18 05:45:30 <denisx> and before it is listed on block explorer
 46 2011-12-18 05:45:43 <gmaxwell> Becuase they're trying to pool hop?
 47 2011-12-18 05:45:54 <denisx> gmaxwell: sure they pool hop
 48 2011-12-18 05:46:29 <denisx> it seems they do LP calls on all pools to know which one has found a block
 49 2011-12-18 05:47:02 <denisx> they left my pool on 6:31:20
 50 2011-12-18 05:47:14 <denisx> but the block is listen as found von 6:33:04
 51 2011-12-18 05:47:20 <gmaxwell> sure, one way to hop is to just stay on the proportional pool which has most recently found a block
 52 2011-12-18 05:47:26 <denisx> and I have seen that several times now
 53 2011-12-18 05:47:39 <gmaxwell> ah the network is far from instant..
 54 2011-12-18 05:47:51 <gmaxwell> every node between your pool and the other pool has to validate the block
 55 2011-12-18 05:48:11 <denisx> gmaxwell: but the time on block explorer is time from inside the block
 56 2011-12-18 05:48:43 <gmaxwell> Doesn't mean the clock of the other pool is correct. e.g. due to ntime rolling eligius blocks are frequently an hour off or more.
 57 2011-12-18 05:49:00 <denisx> which is ca. the time my pool made the LP call
 58 2011-12-18 05:49:29 <denisx> so the pool who found the block didn't release it immediately I think
 59 2011-12-18 05:49:31 <gmaxwell> I assume in that case the other pool found the block at 6:31:20, LPed, and the miners moved.
 60 2011-12-18 05:49:40 <gmaxwell> I don't see why you're conclusing that.
 61 2011-12-18 05:50:10 <gmaxwell> What happened is that the pool released it immediately but it took several minutes to make it to you because of each of the nodes between you and them taking time to fetch and validate the block.
 62 2011-12-18 05:51:23 <denisx> I checked my LP times some time ago
 63 2011-12-18 05:51:30 <denisx> I never was 2min behind
 64 2011-12-18 05:51:34 <denisx> it never..
 65 2011-12-18 05:51:49 <denisx> more like some seconds
 66 2011-12-18 05:52:50 <denisx> Iam not sure about this, but I will keep an eye on it
 67 2011-12-18 05:53:55 <gmaxwell> At 6:31:20 the pool found the block, they announce, and long poll.. then it goes to another node, then another, then another, then you. Finally, you long poll. How is this series of events inconsistent with your data?
 68 2011-12-18 05:54:47 <denisx> gmaxwell: thats the way it works, right. but very fast
 69 2011-12-18 05:55:27 <denisx> at some time I compared my LP calls with btcguild
 70 2011-12-18 05:55:39 <gmaxwell> I don't know why you believe it should be very fast. It can easily take a number of seconds to transfer and validate a block (esp one with many transactions
 71 2011-12-18 05:55:40 <denisx> most of the time the LP call was fired the same second
 72 2011-12-18 05:56:16 <gmaxwell> sure, so the block reached btcguild and you at the same time, but it still could have taken a long time absolutely.
 73 2011-12-18 05:56:53 <gmaxwell> In any case, another pool doesn't gain any advantage by delaying, regardless. they lose, in fact, since if someone else announces first, people will be working on extending that block instead.
 74 2011-12-18 05:58:06 <denisx> gmaxwell: I hope your right!
 75 2011-12-18 06:00:07 <denisx> [2011-12-18 06:59:20.244074] USR1 signal received, flushing LP waiters
 76 2011-12-18 06:00:32 <denisx> lets see how fast it was this time
 77 2011-12-18 06:02:29 <denisx> hmm, that was two blocks
 78 2011-12-18 06:02:39 <denisx> don't know which one it was
 79 2011-12-18 06:04:10 <denisx> gmaxwell: or maybe it is a really bad pool which has to answer thousands of LP calls after it found the block and is totally overloaded with that
 80 2011-12-18 06:05:01 <gmaxwell> or one with poor connectivity that only propagates the block very slowly.
 81 2011-12-18 06:08:09 <EvanR> ive been syncing to network all day
 82 2011-12-18 06:11:49 <EvanR-pissed> checking on it. 97% -_-
 83 2011-12-18 06:14:54 <jrmithdobbs> gmaxwell: oh hi this discussion again
 84 2011-12-18 06:28:21 <denisx> gmaxwell: but if my LP calls would be 1min late on average, I would have 10% invalids on average
 85 2011-12-18 06:28:49 <denisx> but I had never any invalid block and found close to 100
 86 2011-12-18 06:41:22 <denisx> I still need to add netinet.h and sys/socket.h to protocol.cpp to build on freebsd
 87 2011-12-18 06:42:10 <[Tycho]> Do we need to apply this already ? https://github.com/gavinandresen/bitcoin-git/commit/c56e4943a944923d0d65344cdc16f132ccbed55a
 88 2011-12-18 06:48:58 <luke-jr> [Tycho]: I don't think so. Pools don't care about how users handle addresses.
 89 2011-12-18 06:49:13 <luke-jr> [Tycho]: there's no version information in the blocks/transactions themselves
 90 2011-12-18 06:50:29 <[Tycho]> What's the purpose of #include <numeric> here ? https://github.com/gavinandresen/bitcoin-git/commit/f62c6087a2681f568c18f2db05147f227dd06d5b#L12L-1
 91 2011-12-18 06:52:31 <luke-jr> dunno, someone smack Gavin for further abusing headers.h
 92 2011-12-18 07:59:17 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r2beed30 / (lib/connection.js lib/schema/transaction.js): Cache transaction buffer to eliminate need for re-serialization. (+5 more commits...) - http://git.io/6MoaSA https://github.com/bitcoinjs/node-bitcoin-p2p/commit/2beed300067fe62591e3cfa15e1f0bb95cb23c72
 93 2011-12-18 08:19:02 <[Tycho]> Why CTransaction's ToString() uses GetHash().ToString() instead if GetHash().GetHex() ?
 94 2011-12-18 08:38:34 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r5cdb98d / (README.md package.json): Updated README and package.json for 0.2. - http://git.io/6JzL3g https://github.com/bitcoinjs/node-bitcoin-p2p/commit/5cdb98da76709cedcc682a2c7a8fbf58ff367706
 95 2011-12-18 08:41:07 <[Tycho]> Can I add normal inputs to generation TX ?
 96 2011-12-18 09:06:45 <sipa> [Tycho]: no
 97 2011-12-18 09:07:25 <[Tycho]> What exactly stops this ?
 98 2011-12-18 09:08:09 <[Tycho]> I see that vtx[0] output is limited, but that's not enough, somewhere should be something else...
 99 2011-12-18 09:09:20 <sipa> a transaction with >1 txin is not considered a coinbase
100 2011-12-18 09:09:51 <[Tycho]> Yes, I see this in "IsCoinbase".
101 2011-12-18 09:09:58 <[Tycho]> Where does it checks it ?
102 2011-12-18 09:10:41 <[Tycho]> And why generation tx can only have 1 input ?
103 2011-12-18 11:29:04 <[Tycho]> "4 space indenting, no tabs" - why ?
104 2011-12-18 11:34:19 <sipa> [Tycho]: convention
105 2011-12-18 11:34:43 <sipa> it's not better or worse than other rules, but the style should be consistent
106 2011-12-18 11:36:10 <[Tycho]> Tabs are so cool...
107 2011-12-18 11:37:33 <sipa> de gustibus et coloribus
108 2011-12-18 11:45:05 <sipa> gmaxwell: will you mail to the ml about the table you made?
109 2011-12-18 11:45:15 <sipa> it seems a good argument in favor of key recovery support
110 2011-12-18 11:56:31 <[Tycho]> sipa, why generation tx can only have 1 input ?
111 2011-12-18 11:56:51 <sipa> no idea, because Satoshi didn't see a reason to allow more?
112 2011-12-18 12:04:30 <Eliel> allowing for more inputs would allow pools that pay through generation (p2pool and eligius at the moment I guess) to pay entirely through generation transaction.
113 2011-12-18 12:13:29 <kinlo> why do you need inputs on a generation in the first place?
114 2011-12-18 12:13:48 <kinlo> generation is "creating" bitcoins, it does not require any input to take from
115 2011-12-18 12:17:54 <sipa> Eliel: and you would consider that a good or a bad thing?
116 2011-12-18 12:19:18 <Eliel> sipa: good
117 2011-12-18 12:19:28 <OneFixt> Eliel: bitpenny also pays through generation
118 2011-12-18 12:20:26 <Eliel> sipa: ideally, a pool wouldn't need to hold bitcoins at all.
119 2011-12-18 12:20:37 <Eliel> but I'm not sure how to achieve that.
120 2011-12-18 13:14:40 <[Tycho]> kinlo: to make things more universal.