1 2012-02-18 00:07:04 <sipa> gmaxwell: btw, did you know the genesis block's output is unspendable?
  2 2012-02-18 00:07:24 <gmaxwell> never inserts it in the intext.
  3 2012-02-18 00:07:26 <gmaxwell> index.
  4 2012-02-18 00:07:28 <sipa> indeed
  5 2012-02-18 00:07:29 <gmaxwell> We could fix that
  6 2012-02-18 00:07:47 <sipa> technically, that would give satoshi the ability to hardfork the network :D
  7 2012-02-18 00:07:51 <gmaxwell> e.g. insert it but only at some high far future height. :)
  8 2012-02-18 00:08:22 <sipa> i wonder if it's an oversight or intentional
  9 2012-02-18 00:08:35 <gmaxwell> yes, if we did it nowish. but if it were done later... perhaps we should just insert an explicit bit of code to prevent it.
 10 2012-02-18 00:08:47 <gmaxwell> so that it's more likely other implementors will reproduce the behavior.
 11 2012-02-18 01:27:55 <etotheipi_> sipa, do you have the link to the deterministic wallet spec you made?
 12 2012-02-18 01:28:00 <etotheipi_> I forgot to bookmark it
 13 2012-02-18 03:40:58 <etotheipi_> has anyone ever successfully used a non-standard hashcode on the main network or test network?
 14 2012-02-18 05:38:12 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 862 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/862>
 15 2012-02-18 08:37:57 <ThomasV> is the DIANNA guy online?
 16 2012-02-18 10:19:49 <sipa> etotheipi_: https://gist.github.com/1799467
 17 2012-02-18 11:42:43 <sje> wumpus?
 18 2012-02-18 11:58:22 <gribble> New news from bitcoinrss: sipa opened pull request 863 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/863>
 19 2012-02-18 12:34:39 <denisx> is blockexplorer down?
 20 2012-02-18 12:34:59 <Graet> yes
 21 2012-02-18 12:35:05 <Graet> or as good as :)
 22 2012-02-18 12:35:32 <denisx> but it will come back?
 23 2012-02-18 12:36:20 <Graet> i believe so
 24 2012-02-18 12:36:31 <Graet> http://www.blockchain.info/q is useful in the eman time :)
 25 2012-02-18 12:36:37 <Graet> mean*
 26 2012-02-18 13:25:09 <gribble> New news from bitcoinrss: sipa opened pull request 864 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/864>
 27 2012-02-18 13:36:48 <twmz> anyone having problems with the latest git bitcoind and p2pool?  I am still running the latest released version and want to check before I upgrade
 28 2012-02-18 13:37:50 <sipa> twmz: i am not a p2pool user, but if anything, things should have remained the same or improved
 29 2012-02-18 13:38:19 <twmz> ah, thanks and I just realized I asked in the wrong channel :)
 30 2012-02-18 13:40:42 <gribble> New news from bitcoinrss: sipa opened pull request 865 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/865>
 31 2012-02-18 13:48:23 <makomk> sipa: I actually ran into that on Bitcoin when creating a transaction that attempted to spend from the genesis block. Had to use the block after instead.
 32 2012-02-18 13:51:04 <sipa> uhm... are you satoshi?
 33 2012-02-18 13:51:47 <Graet> lol
 34 2012-02-18 13:53:37 <JFK911> no.. must be realsolid
 35 2012-02-18 13:56:52 <luke-jr> sipa: I presume he means with CLC
 36 2012-02-18 14:01:58 <sipa> luke-jr: ah, right
 37 2012-02-18 14:02:02 <tcatm_> gmaxwell: ping
 38 2012-02-18 14:02:14 <sipa> there is an actual 0.3.0 node on the network, it seems
 39 2012-02-18 14:03:59 <luke-jr> O.o
 40 2012-02-18 15:14:14 <makomk> luke-jr: nope, was on Bitcoin testnet. The node-crashing bug I found a while ago involved attempting to spend an invalid output on a valid transaction, and the genesis block coinbase looked like a good choice.
 41 2012-02-18 15:14:48 <makomk> Actually, I think it was on a mainnet node I controlled even.
 42 2012-02-18 15:50:05 <ThomasV> luke-jr: is there a way to know if my client is connected to your pool?
 43 2012-02-18 15:51:58 <luke-jr> ThomasV: is it hosted by Hetzner?
 44 2012-02-18 15:52:25 <ThomasV> luke-jr: do you still accept non-standard tx?
 45 2012-02-18 15:52:50 <ThomasV> why Hetzner?
 46 2012-02-18 15:53:52 <ThomasV> no, it's hosted by cinfu
 47 2012-02-18 15:59:47 <luke-jr> ThomasV: I do.
 48 2012-02-18 16:00:02 <luke-jr> ThomasV: my pool is null routed, so it can only peer with other Hetzner nodes right now
 49 2012-02-18 16:00:45 <ThomasV> luke-jr: I could pastebin it..
 50 2012-02-18 16:01:01 <sipa> RFC 1149 could be used
 51 2012-02-18 16:01:48 <ThomasV> lol
 52 2012-02-18 16:09:03 <luke-jr> ThomasV: how would I get it into bitcoind? ;)
 53 2012-02-18 16:09:26 <ThomasV> there's the importtx patch
 54 2012-02-18 16:10:18 <ThomasV> luke-jr: but it's not very important, we can as well forget it
 55 2012-02-18 16:10:33 <ThomasV> I was just experimenting
 56 2012-02-18 16:13:37 <ThomasV> luke-jr: I guess your connectivity means that Hetzner could succeed in a double-spend attack on you :)
 57 2012-02-18 16:16:43 <Graet> or deepbit - they host there too
 58 2012-02-18 16:18:07 <Graet> actually our eu node is too lol
 59 2012-02-18 16:18:26 <gmaxwell> ThomasV: ... Surprise: the party that controls your network can replace your peers no matter who you think you're talking to.
 60 2012-02-18 16:18:30 <Graet> i think i might move out seems jucy ddos target
 61 2012-02-18 16:38:18 <coventry> Is anyone around who could lift this out of the newbie jail for me?  Also, I've submitted this to HN and /r/bitcoin as well.  Is there anywhere else I might reach interested people?  https://bitcointalk.org/index.php?topic=64421.0 (It's a design document for a BTC-like cryptocurrency which includes arbitrary computation in the proof of work.)
 62 2012-02-18 17:14:07 <luke-jr> must the height really be 24-bit? :/
 63 2012-02-18 17:15:11 <gribble> New news from bitcoinrss: aaronscientiae opened issue 866 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/866>
 64 2012-02-18 17:45:12 <luke-jr> or varint
 65 2012-02-18 17:45:25 <luke-jr> otoh, varint would make more work for me <.<
 66 2012-02-18 17:49:56 <copumpkin> luke-jr: I think that's everyone's goal :)
 67 2012-02-18 17:49:59 <copumpkin> (to make more work for you!)
 68 2012-02-18 17:50:16 <copumpkin> so you should tell people that a plain 32-bit int would be the most work for you
 69 2012-02-18 21:16:45 <diana555> hey, anyone know the details of the change to version/verack messages coming on the 20th?
 70 2012-02-18 21:19:36 <gmaxwell> diana555: Yes, of course.
 71 2012-02-18 21:19:45 <gmaxwell> diana555: What are you interested in knowing?
 72 2012-02-18 21:20:54 <diana555> How is this change being implemented? Is there a new version of the client coming out that will generate these new types of messages?
 73 2012-02-18 21:21:06 <diana555> Are the old clients capable of parsing them?
 74 2012-02-18 21:21:17 <sipa> diana555: All versions of the client since 0.2.10 have implemented the rule that the protocol is changing on Feb 20 2012.
 75 2012-02-18 21:21:28 <gmaxwell> diana555: The change was implemented several years ago. All software 0.2.10 and later have the code for this.
 76 2012-02-18 21:21:36 <gmaxwell> ah, sipa beat me to it.
 77 2012-02-18 21:21:54 <diana555> oh, so this is like a flag day - everyone just starts sending the new message format regardless of what client version they have?
 78 2012-02-18 21:22:03 <gmaxwell> diana555: can you point me to where you heard about this that made you think a software update was required?
 79 2012-02-18 21:22:15 <sipa> Exactly - we only expect problems for people whose clock is off.
 80 2012-02-18 21:23:01 <diana555> well, there's nothing about a software update. Just a mention of the date here: https://en.bitcoin.it/wiki/Protocol_specification#Message_structure
 81 2012-02-18 21:23:25 <gmaxwell> Ah okay.
 82 2012-02-18 21:23:35 <kinlo> when is the protocol going to change btw, I assume the message on the test network was just a test with an incorrect date?
 83 2012-02-18 21:23:55 <sipa> kinlo: Februari 20, 2012, UTC 0:00
 84 2012-02-18 21:24:01 <kinlo> oic
 85 2012-02-18 21:24:25 <kinlo> so you're going to announce it one day before?
 86 2012-02-18 21:24:39 <kinlo> is the new client already available?
 87 2012-02-18 21:24:39 <sipa> Not sure when Gavin intends to send the alert.
 88 2012-02-18 21:24:44 <sipa> What new client?
 89 2012-02-18 21:25:39 <phantomcircuit> bleh
 90 2012-02-18 21:25:45 <phantomcircuit> the checksums are useless
 91 2012-02-18 21:25:51 <phantomcircuit> tcp already has checksums
 92 2012-02-18 21:26:02 <diana555> how are the checksums computed for verack messages?
 93 2012-02-18 21:26:28 <sipa> The same way they are for every other message.
 94 2012-02-18 21:26:31 <diana555> since there's no payload
 95 2012-02-18 21:27:35 <gmaxwell> phantomcircuit: well, arguably it doesn't matter for these particular messages but the tcp checkums are pretty darn useless.
 96 2012-02-18 21:28:10 <sipa> diana555: So it's just checksum of the empty string.
 97 2012-02-18 21:29:13 <gmaxwell> phantomcircuit: first, because it's just ones compliment addition, for typical packet sizes you can't even cover the whole checksum space, so you get 10 bits of protection at best. They are also completely blind to make common burst error patterns. There are also many 'smart' devices out there that bust open tcp streams and put correct checksums back on them... so tcp checksum isn't really end to end on a good hunk of the internet.
 98 2012-02-18 21:29:28 <gmaxwell> s/to make/to many/
 99 2012-02-18 21:29:59 <diana555> sipa: ok, thanks a lot
100 2012-02-18 21:30:07 <gmaxwell> All this matters for stuff the gets relayed, e.g. transactions.. version, meh. Not so much.
101 2012-02-18 21:30:25 <gmaxwell> though you could replace the hash function with HMAC and have authenticated peers pretty easily.
102 2012-02-18 21:30:33 <sipa> For version and verack it hardly matters, but once feb20 is passed, the client code can be simplified.
103 2012-02-18 21:31:32 <diana555> right
104 2012-02-18 21:37:45 <luke-jr> phantomcircuit: TCP checksums are ignored
105 2012-02-18 21:38:25 <luke-jr> sipa: yeah, I wrote some code that doesn't work until Feb20 just cuz the special casing is a pain
106 2012-02-18 21:38:38 <luke-jr> too bad we might end up with new special casing soon :/
107 2012-02-18 22:20:59 <luke-jr> is block height (in coinbase) 0-based or 1-based?
108 2012-02-18 22:23:07 <phantomcircuit> gmaxwell, eh it still doesn't matter the only thing that needs an explicit checksum is transactions
109 2012-02-18 22:23:37 <phantomcircuit> and the worst thing that happens if those are wrong is that single peer rejects the tx (ie doesn't forward it)
110 2012-02-18 22:23:46 <phantomcircuit> so it isn't really a big deal either way
111 2012-02-18 22:26:20 <luke-jr> phantomcircuit: and bans the user
112 2012-02-18 22:26:59 <phantomcircuit> yeah but with realistic error rates that is probably not much of a concern
113 2012-02-18 22:27:35 <phantomcircuit> especially since more error prone media like 802.11 have much more competent error correction
114 2012-02-18 22:30:53 <sipa> luke-jr: genesis block is encoded as 1, judging from gavin's code
115 2012-02-18 22:31:26 <luke-jr> phantomcircuit: you realize there is a real-world practical exploit that relys on memory corrupting the domain name during DNS lookup?
116 2012-02-18 22:31:36 <luke-jr> sipa: thanks
117 2012-02-18 22:32:01 <luke-jr> phantomcircuit: ie, memory corruption occurs often enough that it can be relied on for exploits
118 2012-02-18 22:35:31 <theymos> sipa: Why do it like that? "Block numbers" start at 0 in Bitcoin.
119 2012-02-18 22:37:10 <luke-jr> theymos: says who?
120 2012-02-18 22:37:24 <luke-jr> theymos: bitcoind uses both 0 and 1 various places
121 2012-02-18 22:39:49 <theymos> When getblocknumber and getblockcount were separate, getblocknumber was defined to return the greatest block number in the chain (the greatest nHeight, I believe). (This is confusingly now the behavior of getblockcount.)
122 2012-02-18 22:41:02 <theymos> So if getblocknumber returns the greatest nHeight, then a block's number is its height.