User:Genjix/Meetings/10 Jan 2012

Agenda:

• Pull 748
• PayToScript -> Payscr?
• addmultisigaddress cases
• Protocol version bump
• Changes to block verification
• how long voting period
• Fuzzing tool(s)
• Basic fee rules
• Finishing up 0.4.3 and 0.5.2

20:56 < genjix> i made a list of things here, https://en.bitcoin.it/wiki//10_Jan_2012
20:57 < genjix> lets have that meet then (i got flu though today so i might be a bit slow/incoherent)
20:58 < genjix> so,
20:58 < genjix> this next change with the PayToScript, is it going to bump version to 0.6 or are we already at 0.6 and will have another protocol version bump?
20:58 -!- the_batman [~cromartie@206.176.233.19] has joined #bitcoin-dev
20:58 < sipa> i'd like to add one point: acceptance of compressed pubkeys
20:59 < genjix> because i think bumping to 0.7 is better. that way if miners lose the vote, it gets rolled back to 0.6
20:59 < gavinandresen> Are you talking about the protocol version or the client version?
20:59 < genjix> protocol version
20:59 < gavinandresen> PayToScript doesn't affect the protocol at all
20:59 < sipa> genjix: protocol version is currently 60000, client version is currently 0.5.99
20:59 < genjix> wait, why?
21:00 < genjix> it is a protocol change
21:00 < genjix> since scripts are interpreted in a new way
21:00 < gavinandresen> How so?  Exactly the same bytes go across the network....
21:00 < sipa> gavinandresen: but which bytes are allowed changes
21:00 < CIA-100> bitcoin: Luke Dashjr 0.5.x * r98811f6ad476 bitcoind-stable/ (6 files in 5 dirs): Bump version to 0.5.3 http://tinyurl.com/8yry22r
21:00 < CIA-100> bitcoin: Luke Dashjr 0.5.x * r83201b12ae10 bitcoind-stable/: Merge branch '0.5.0.x' into 0.5.x http://tinyurl.com/7oxn8zk
21:00 < genjix> yeah but protocol is a bit more than what bytes go over the network
21:00 < genjix> it's also how the clients behave
21:00 < helo> i thought that's exactly what it is
21:00 < sipa> the decision on whether to use old or new behaviour is not determined by the protocol version
21:01 < sipa> but the protocol changes, imho
21:01 < gavinandresen> Ok:  I'll put in an "I don't care what the client or protocol versions are"
21:02 < sipa> hmm, on the other hand, it is more the transaction format that changes
21:02 -!- denisx [~denis@91-65-136-254-dynip.superkabel.de] has joined #bitcoin-dev
21:02 < genjix> ok so can it be 0.6 now and then 0.7 then? that will make much more sense
21:02 < sipa> it is not relevant to partners in the communication
21:02 < genjix> specially when analysing the network traffic
21:02 < luke-jr> gavinandresen: there you are!
21:02 < roconnor> all these version numbers are ignored by the client (and protocol) anyways
21:03 < sipa> roconnor: the protocol version is not ignored
21:03 < roconnor> sipa: I don't know this.
21:03 < luke-jr> gavinandresen: 0.4.3 is ready for upload to SF, and 0.5.2 will be ready as soon as you do a Mac build (and possibly build the Win/Linux to verify BlueMatt's builds)
21:04 < sipa> roconnor: connect with a pre-206 client, and you won't see checksums, e.g.
21:04 < luke-jr> gavinandresen: Mac/Linux 0.4.3 is at http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ ; you already said you weren't interested in building, so I won't ask you to make a Mac for it
21:04 < roconnor> sipa: ah, interesting
21:04 < gavinandresen> luke-jr: lets talk about satoshi-client-specific-release stuff later
21:05 < genjix> roconnor: https://en.bitcoin.it/wiki/Protocol_specification#version
21:05 < luke-jr> ok
21:05 < genjix> sipa: k, go on with compressed pubkeys
21:05 < sipa> i haven't heard any complaints
21:05 < genjix> < sipa> i'd like to add one point: acceptance of compressed pubkeys
21:06 < luke-jr> gavinandresen: re BIP 16, I think it needs to be Rejected or revised clearer
21:06 < roconnor> sipa: aren't compressed keys already accepted?
21:06 < sipa> but compressed pubkeys on the network is a network rule change
21:06 < luke-jr> sipa: it is?
21:06 < makomk> sipa: don't think it is actually?
21:06 < gavinandresen> It was unspecified before
21:06 < sipa> all specifications of the network say that pubkeys are 65 bytes are start with 0x04
21:06 < sipa> we are using other pubkeys
21:07 < sipa> which happen to be supported by older clients even
21:07 < luke-jr> gavinandresen: but it was enabled, so anything not supporting it would have forked
21:07 < sipa> good point
21:07 < sipa> there is compressed pubkey on mainnet
21:07 < luke-jr> seems more like a hidden feature before, to me
21:07 < luke-jr> and a bug in the specifications
21:07 -!- da2ce7 [~da2ce7@gateway/tor-sasl/da2ce7] has joined #bitcoin-dev
21:07 < roconnor> sipa: what packets use pubkeys?
21:08 -!- d4de [~RaWWR@unaffiliated/d4de] has joined #bitcoin-dev
21:08 < sipa> roconnor: scriptSigs
21:08 < genjix> it's just an automatic feature of the EC lib in SSL
21:08 < genjix> (i assume)
21:08 < sipa> luke-jr: an unintended, unspecified feature, that all OpenSSL-based clients support probably automatically
21:08 < makomk> I seem to recall that compressed pubkeys even pass IsStandard.
21:08 < sipa> makomk: they do
21:08 < roconnor> sipa: which message type is scriptSigs in?
21:08 < [eval]> TD: i like your assurance contract idea! i bet the same can be used for relaying transactions, too (relay nodes can publish their bitcoin addresses, and stay up as long as they're being funded)
21:09 < sipa> roconnor: tx and block
21:09 < genjix> damn this is why user agents are useful :D
21:09 < da2ce7> Back safe in AUS.
21:09 < luke-jr> genjix: ?
21:09 < genjix> see how much of a minority alternative bitcoin versions (like BitcoinJava) are
21:09 < sipa> anyway, i have heard no complaints, so i guess we can continue rolling out compressed pubkeys?
21:09 < TD> [eval]: thanks. i guess so
21:09 < roconnor> sipa: hmm, I cannot find what you are talking about.
21:09 < TD> sipa: are there any compressed pubkeys on the testnet?
21:10 < roconnor> sipa: I'm looking at https://en.bitcoin.it/wiki/Protocol_specification#tx
21:10 < roconnor> and #block
21:10 < sipa> TD: yes, and one on realnet too
21:10 < TD> i see
21:10 < genjix> where is the mainnet compressed pubkey?
21:10 < TD> where is the one on the prodnet?
21:10 < genjix> i never noticed it
21:10 < luke-jr> roconnor: afaik those specs are incomplete
21:10 < TD> i probably have to update bitcoinj to support this
21:10 < roconnor> luke-jr: well, I think sipa's problem is simply a documentation error.
21:10 < gavinandresen> sipa: I vote for pulling soon (I was testing it with p2sh, which is how I confused myself RE: I thought I'd already pulled it)
21:10 < TD> afaik bouncy castle already knows about them so it should be easy
21:10 < genjix> but i'm also using SSL's EC lib like bitcoin
21:10 < roconnor> luke-jr: but I'm hoping to clairfy
21:10 < genjix> so im guessing it's automatic
21:11 < gavinandresen> roconnor: https://en.bitcoin.it/wiki/Protocol_specification#Signatures
21:11 < sipa> TD: i've mailed with a specification for an import format for corresponding private keys
21:12 < sipa> -with
21:12 < roconnor> gavinandresen: that would be a documentation error ... I thought I fixed that, but maybe I fixed it elsewhere.
21:12 < TD> yes, i saw that
21:12 -!- localhost [~chris@cpe-76-188-161-222.neo.res.rr.com] has joined #bitcoin-dev
21:12 < luke-jr> genjix: why not GnuTLS yet?
21:12 < gavinandresen> While we're fixing documentation:  does anybody know if OpenSSL accepts any OTHER types of signatures?
21:12 < gavinandresen> (or pubkeys)
21:12 < luke-jr> genjix: AFAIK OpenSSL is still a problem for libbitcoin legally
21:12 < genjix> luke-jr: i can add an exception according to FSF
21:13 < genjix> they said it was fine
21:13 < sipa> gavinandresen: SEC defines three types: 0x00 = point at infinity, 0x02 and 0x03 = compressed, 0x04 = uncompressed
21:13 < genjix> nice
21:13 < makomk> (Random though - unless I'm entirely mistaken, if OP_CAT was enabled would it be possible to securely create transactions paying someone to generate you a P2SH vanity address?)
21:14 < sipa> signatures are DER encoded, but someone noted before that any BER encoding is accepted
21:14 < roconnor> gavinandresen: it is unclear if 0x00 is a valid public key.  It shouldn't be, but someone should double check.
21:14 < genjix> roconnor: who cares. black hole pubkey
21:14 < roconnor> sipa: actuall OpenSSL doesn't follow DER
21:14 < roconnor> sipa: http://r6.ca/blog/20111119T211504Z.html
21:14 < luke-jr> genjix: you can, but it would still be incompatible with people wanting to use it in GPL etc
21:14 < sipa> roconnor: indeed, i remember that they used some trick for singed/unsigned
21:16 < roconnor> sipa: there are sigs (on testnet?) that use "negative" numbers
21:16 < roconnor> maybe it was mainnet
21:16 < roconnor> I forget
21:16 < roconnor> somewhere
21:16 < roconnor> what a pain
21:16 < TD> devrandom: poke
21:16 < gavinandresen> Well, if somebody who understands DER/BER and openssl's implementation much better than me would like to think hard about what implementations should/shouldn't accept and write it up that would be spiffy
21:16 < sipa> anyway, it seems the entire "specification"for what are valid sigs and pubkeys is set by OpenSSL's implementation
21:16 < genjix> yeah lol
21:17 < gmaxwell> sipa: this is a bad thing— its not like most applications care as much about it changing as bitcoin does.
21:17 < gavinandresen> Discouraging transactions that play games with encodings would be a very good idea, I think.
21:18 -!- pycke2 [~yaaic@83-174.105-92.cust.bluewin.ch] has joined #bitcoin-dev
21:18 < genjix> what about discouraging coinbases outside of predefined values?
21:18 < sipa> why?
21:19 < genjix> well if we compress pubkeys to avoid blockchain bloat
21:19 < sipa> gavinandresen: they should be simply made invalid, imho - but that requires some coordination with a supermajority of miners
21:19 < genjix> why not discourage custom coinbases. people put all kinds of long ass messages in there
21:19 < luke-jr> genjix: they can't.
21:19 < gavinandresen> coinbases are 100 bytes max
21:19 < sipa> genjix: i don't care about max 98 bytes of bloat per 10 minutes
21:19 < gmaxwell> genjix: maximum size of the coinbase is small.
21:20 < genjix> ok
21:20 < gmaxwell> And most of the 'crap' now is merged mining committments which are O(1) at least.
21:20 < makomk> Besides, if we discouraged custom coinbases how could we signal P2SH support?
21:21 < genjix> allow that one alone
21:21 < makomk> A hypothetical successor to P2SH?
21:21 < roconnor> genjix: *lol*
21:21 < sipa> i see no reason to limit coinbases
21:22 < genjix> ok
21:23 < sipa> gavinandresen: any further ACK required on pubkey compression? otherwise i pull
21:23 < roconnor> luke-jr: if you really want to throw a wrench into th P2SH proposal you should put P2SH in your coinbase, but not actually support it.
21:23 < gavinandresen> sipa:  go for it
21:23 < sipa> genjix: next agenda point
21:23 < genjix> btw i didnt look over changes too thoroughly yet, but it seems the changes are: new sig ops count/solver which is in ConnectInputs, and new script eval
21:23 < CIA-100> bitcoin: Pieter Wuille master * rafcf6f9 / (8 files in 2 dirs): Merge pull request #649 from sipa/comprpubkey ... https://github.com/bitcoin/bitcoin/commit/afcf6f974f5c0746db5526b0c209c7db0f5dbe0b
21:24 < genjix> i was thinking to make a quick bullet list of changes for people to examine
21:24 -!- tyn [~rynxy@d-213-212.resnet.unb.ca] has quit [Read error: No route to host]
21:24 < genjix> for people interested in how the new works
21:24 < gavinandresen> genjix: new VerifySignature, but the guts of EvalScript go back to pre-op-eval state.
21:25 < genjix> yep, so is that all really? seems relatively straightforward
21:26 < genjix> (apart from the RPC stuff and so on)
21:26 -!- bakh_ [~kass2@AAnnecy-752-1-1-172.w90-41.abo.wanadoo.fr] has joined #bitcoin-dev
21:26 < gavinandresen> genjix: I'm testing a refactoring of ConnectInputs that moves some of the tests for txn validity to before the ECDSA signature checks, so denial-of-service is less possible
21:26 < genjix> nice.
21:26 < genjix> i like how you refactored the code into FetchInputs and ConnectInputs
21:27 < gavinandresen> ConnectInputs() does way too many things.....
21:28 < gavinandresen> What's the PayToScript -> Payscr? agenda item?  Suggested rename?
21:28 < TD> sipa: hey, any idea which tx on mainnet has compressed pubkeys?
21:28 < genjix> ah yeah, just got tired typing PayToScript all the time
21:28 < genjix> Payscript or something sounds nicer
21:28 < sipa> TD: searching
21:28 < genjix> not a big deal though
21:28 < gmaxwell> P2SH
21:28 < genjix> sipa: yeah that tx would be really nice
21:29 < genjix> gmaxwell: hah yeah cool
21:29 < genjix> P2SH
21:29 < luke-jr> need to give it a distinct name
21:29 < luke-jr> separate from the general concept
21:29 < gavinandresen> bruce
21:29 < genjix> :D
21:29 < genjix> haha
21:29 < gmaxwell> (which somehow my mind parses as 'PUSH')
21:30 < gmaxwell> People are going to call it '3-addresses' or something like that regardless of what we call it.
21:30 < luke-jr> lol
21:30 < luke-jr> so are we going to discuss /P2SH/ or not?
21:30 < genjix> luke-jr: ? sure
21:30 < sipa> genjix, TD: http://blockchain.info/tx-index/13401517/94af4607627535f9b2968bd1fbbf67be101971d682023d6a3b64d8caeb448870?show_adv=yes
21:30 < genjix> tyty!
21:30 < TD> thanks
21:31 < gavinandresen> luke-jr: last I heard, you weren't going to support it unless we pinkie-swore in the BIP that Bitcoin 2.0 got rid of scriptPubKey entirely.
21:31 < luke-jr> gavinandresen: exactly.
21:31 -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Changing host]
21:31 -!- iddo [~idddo@unaffiliated/iddo] has joined #bitcoin-dev
21:31 -!- b4epoche_ [~textual@dssl.mne.psu.edu] has joined #bitcoin-dev
21:31 < luke-jr> I think special-casing a magic script like proposed in BIP 16 only ever makes sense as a backward compatible way of abolishing scriptPubKey entirely.
21:32 < genjix> why not call then input_script and output_script lol. i always get confused with the 2
21:32 < gavinandresen> I don't think it is a good idea to put "this is what is going to happen at some unspecified point in the future" into BIPs-- what do other people think?
21:32 -!- b4epoche [~textual@dssl.mne.psu.edu] has quit [Ping timeout: 244 seconds]
21:32 -!- b4epoche_ is now known as b4epoche
21:32 < genjix> gavinandresen: maybe this? https://en.bitcoin.it/wiki/Hardfork_Wishlist
21:32 < TD> um, what's wrong with scriptPubKey
21:32 < luke-jr> gavinandresen: rather, "This change formally deprecates scriptPubKey (now), and all future development should assume it will go away in the future."
21:32 < gmaxwell> I think people here have mostly said that would be the intention if we were doing bitcoin2.0 today— but hell, who knows what the future brings.
21:33 < sipa> i prefer seeing BIP 16 as adding a possibility
21:33 < luke-jr> obviously if there's some major problem in a year, a future BIP can deprecate BIP 16 and revive scriptPubKey :p
21:33 < TD> could you guys please stop screwing with the protocol?
21:33 < luke-jr> sipa: adding a possibility, would mean a new opcode with a new function
21:34 < luke-jr> not special-casing a specific template
21:34 < midnightmagic> uh..  what the hell debug flag is it so I can see the commands themselves invoked? (gmake)
21:34 < genjix> TD: i think this is maybe the last major change (the P2SH)
21:34 < luke-jr> genjix: unlikely :P
21:34 < roconnor> I agree with TD
21:34 < gavinandresen> I agree with TD
21:34 < roconnor> doing nothing is better than P2SH
21:34 < TD> i think once you open the "hey let's improve the protocol" can of worms, there's no end in sight
21:34 < gavinandresen> I disagree with roconnor
21:35 < roconnor> contradition!!
21:35 < roconnor> :D
21:35 < genjix> TD: yeah well, bitcoin has an inevitable future as a bloated standard
21:35 < gmaxwell> genjix: there are worse fates.
21:35 < gmaxwell> (like being too unimportant for anyone to care to add bloat)
21:35 < gavinandresen> roconnor: would you support getting rid of OP_IFDUP?
21:35 < genjix> sure
21:36 -!- erle- [~m@f052136016.adsl.alicedsl.de] has joined #bitcoin-dev
21:36 < gavinandresen> (we can mess with the protocol to make it smaller, too....)
21:36 < roconnor> gavinandresen: not really
21:36 < roconnor> gavinandresen: unless there are no instances of OP_IFDUP right now
21:36 < genjix> one thing though that would be nice is an informal 'gentlemen's agreement' on basic fee rules for the mempool
21:36 < roconnor> and we move quickly
21:36 -!- briareus [~briareus@unaffiliated/briareus] has joined #bitcoin-dev
21:37 < TD> removing opcodes would result in attackers being able to split the chain out from underneath merchants who did not upgrade
21:37 < gmaxwell> genjix: there is one such agreement embedded in the software, perhaps not the right one— and perhaps not one people are following.
21:37 < genjix> like the current fee rules are hairy and likely to be ignored by most (i dont understand the rationale behind a lot of it)
21:37 < gavinandresen> TD: it'd have to be "support removed in blocks after time X" and mining pools would have to express support etc
21:38 < gavinandresen> If we were lucky, there would be no blocks mined with the unsupported feature before the deadline
21:38 < gmaxwell> genjix: I feel like I undestand the rules and their rationale.  Fundimentally they're using still-coins as a payment for transactions precisely because still-coins is what you don't have if you're DOS attacking.
21:38 < gmaxwell> genjix: I think anything with that behavior is going to be similarly complicated, though perhaps multiple systems would meet that goal.
21:38 -!- _Fireball [~fireball@31.13.34.250] has joined #bitcoin-dev
21:38 < da2ce7> TD, we insert those opcodes on purpose to make a forced split.
21:39 < gavinandresen> Ok, sounds like luke-jr is alone in wanting wording in the BIP RE: scriptPubKey.
21:39 < da2ce7> so it will fail hard.
21:39 < da2ce7> ** in the alt-chain.
21:39 < luke-jr> gavinandresen: does not
21:39 < genjix> well i use a circular buffer and slow it filling up as it gets near the end
21:39 < TD> i continue to believe the core protocol doesn't need fixing
21:39 < gmaxwell> luke-jr: would you be happier with something more vague. Like "current developers think that P2SH transactions are the way of the future" or something?
21:39 < luke-jr> sounds like TD and roconnor agree that "doing nothing is better than P2SH"
21:39  * roconnor agrees with TD
21:40 < gavinandresen> Can we not have that argument AGAIN?  I've got to go in about 10 minutes...
21:40 < luke-jr> gmaxwell: no, because /P2SH/ as written only makes sense if it deprecates scriptPubKey
21:40 < gmaxwell> luke-jr: as we discussed, and I think you accepted— we can't deprecate any thing until P2SH is widely deployed and proven.
21:41 < luke-jr> gmaxwell: nonsense
21:41 < gmaxwell> I personally think we would eventually deprecate non-p2sh but it might be years before the 1form addresses are gone.
21:41 < luke-jr> we just can't remove it
21:41 < sipa> genjix: anything else on the agenda?
21:41 < genjix> nope
21:41 < luke-jr> …
21:41 < gmaxwell> sort of a meaningless depreciation then— it's not like we're a standards body here.
21:41 < luke-jr> lots on the agenda
21:42 < luke-jr> addmultisigaddress cases, Fuzzing tool(s), Finishing up 0.4.3 and 0.5.2
21:42 < sipa> luke-jr: bring up a topic, then
21:42 < luke-jr> and other topics relates to P2SH
21:42 < luke-jr> gmaxwell: BIP is a standards process
21:42 < genjix> what is fuzzing tools?
21:42 < luke-jr> nfc
21:42 < gavinandresen> Fuzzing tools:  I want a protocol-level fuzzer.  Anybody already written one?
21:42 < da2ce7> luke-jr: I don't think that we can ever get rid of 1form addresses...
21:42 < luke-jr> da2ce7: we can phase them out (deprecate them)
21:42 < gmaxwell> I've run zzuf on the bitcoin network connections did nothing interesting, presumably due to the checksums on messages. :)
21:43 < makomk> We can make clients not generate new ones.
21:43 -!- Carmivore [~carmivmor@ec2-107-22-137-127.compute-1.amazonaws.com] has quit [Remote host closed the connection]
21:43 < gavinandresen> RE: fuzzing: https://gist.github.com/1525448
21:43 < sipa> 1form address will remain as identifiers for keypairs; we can deprecate them as direct payment option
21:43 < da2ce7> we can re-implment them I guess - but people need to still be able to spend coins sent to them anytime.
21:43 < luke-jr> da2ce7: eventually everyone will NEED to upgrade for "Bitcoin 2.0", so support for them can be removed at that point
21:43 < makomk> gmaxwell: yeah, I think it may silently ignore anything that fails checksumps or is otherwise invalid.
21:43 < gmaxwell> has anyone tried advancing their clocks on some nodes past the checksum flagday yet?
21:43 < sipa> genjix: good idea
21:43 < genjix> gmaxwell: super
21:44 < roconnor> gmaxwell: what is checksum flagday?
21:44 < genjix> gavinandresen: super 
21:44 < gmaxwell> makomk: the people in this room don't control all clients.
21:44 -!- tyn [~rynxy@d-213-212.resnet.unb.ca] has joined #bitcoin-dev
21:44 < TD> he means the day when the "version" message protocol changes
21:44 < gmaxwell>         // Version 0.2 obsoletes 20 Feb 2012
21:44 < gmaxwell>         if (GetTime() > 1329696000)
21:44 < gmaxwell>         {
21:45 < sipa> gmaxwell: unable to connect
21:45 < makomk> gmaxwell: From my playing-around it probably breaks compatibility with nodes that disagree on the value of the flag, but I've no idea what non-Satoshi clients do.
21:45 < sipa> which is expected
21:45 < genjix> btw what happens when the block timestamp expires?
21:45 < gmaxwell> sipa: have you made sure two new nodes connect?
21:45 < genjix> i know it's a long way off
21:45 < sipa> gmaxwell: trying that now
21:45 < genjix> at minimum it's relying on some UB
21:46 < gmaxwell> sipa: I expect that this is already tested but ... good to be prudent, if everything is going to die in a month we need to know now. :)
21:46 < luke-jr> gmaxwell: so we can sell?
21:46 < makomk> (Yes, this was Yet Another CLC Change. It effectively hardcodes the flag to true.)
21:46 < gmaxwell> hahah
21:46 < roconnor> gmaxwell: is this checksum change on the wiki?
21:47 < genjix> gavinandresen: a bitcoin fuzzer would be so useful for all implementations and network health. the way i test blocks is by overriding hash_block_header and returning different hardcoded hashes based on the block nonce (which i use as an ident)
21:47 < gmaxwell> roconnor: I didn't add it there, did you?   Everything I know about bitcoin I know from reading the source, this channel, and Satoshi's writing.
21:47 < genjix> that way i take the first 500 blocks and i design a tree and then send them to the blockchain service
21:48 < luke-jr> [16:44:50] <gmaxwell>         if (GetTime() > 1329696000)
21:48 < genjix> roconnor: the wiki is good for starting out, but the satoshi implemenation is the read dox
21:48 < luke-jr> ^ is that guaranteed to be the same time for everyone?
21:48 < sipa> gmaxwell: works
21:49 < gmaxwell> luke-jr: nope.
21:49 -!- Carmivore [~carmivmor@ec2-174-129-83-65.compute-1.amazonaws.com] has joined #bitcoin-dev
21:49 < genjix> btw you know those stats about active bitcoin versions, i wonder how many of those old ones actually make txs
21:49 < luke-jr> so we'll probably have some issues for a few hours?
21:49 < makomk> luke-jr: that's local time, so no, but in theory it shouldn't affect already-established connections.
21:49 < gmaxwell> But it only impacts new connections, so ±network clock skew around that time new nodes may have some poblems.
21:50 < sipa> yes, everything after verack is safe
21:50 < luke-jr> so impact will mainly hit people who start their clients around that time
21:50 < gmaxwell> (especially if their clock is wrong)
21:50 < genjix> use the time in util.cpp
21:50 < gmaxwell> might make sense to have some nodes establish that listen to the new protocol early.
21:50 < genjix> GetAdjustedTime()
21:50 < luke-jr> gmaxwell: and use the DNS seeds to ensure they're available?
21:50 -!- magn3ts [~magn3ts@pdpc/supporter/professional/magn3ts] has quit [Disconnected by services]
21:51 < luke-jr> is it possible to support BOTH protocols?
21:51 < gmaxwell> No.
21:51 < makomk> genjix: that only makes a difference once the node's established some connections.
21:51 < gmaxwell> (I think not at least)
21:51 < genjix> true
21:51 < gmaxwell> The change is basically adding the checksum to the version messages... we already upgrade to the new protocol based on that.
21:51 < genjix> ok well i think we covered everything
21:51 < sipa> well, you could make the checksum optional for version and verack
21:51 < gavinandresen> I can live with a few people with incorrect clocks having trouble connecting for a few hours.
21:51 < gmaxwell> sipa: thanks for testing that.