--- Day changed Wed Mar 24 2021
00:02 -!- musdom [~Thunderbi@202.184.45.241] has joined #bitcoin-core-pr-reviews     
00:03 -!- jonatack_ [~jon@37.165.85.219] has quit [Quit: jonatack_]     
00:21 -!- amiti [sid373138@gateway/web/irccloud.com/x-fwysclwpgofmexkv] has quit [Ping timeout: 240 seconds]     
00:23 -!- amiti [sid373138@gateway/web/irccloud.com/x-udjgrzhwufmnknjj] has joined #bitcoin-core-pr-reviews     
00:41 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews     
00:58 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Ping timeout: 258 seconds]     
01:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
01:07 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
01:07 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
01:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
01:11 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews     
02:36 -!- prayank [~andr0irc@2401:4900:30de:f516:f13c:594c:f3d0:3756] has joined #bitcoin-core-pr-reviews     
02:56 -!- musdom [~Thunderbi@202.184.45.241] has quit [Ping timeout: 272 seconds]     
03:08 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds]     
03:38 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews     
03:42 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has quit [Ping timeout: 240 seconds]     
04:05 -!- jonatack [~jon@37.164.189.52] has joined #bitcoin-core-pr-reviews     
04:06 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews     
04:09 -!- prayank [~andr0irc@2401:4900:30de:f516:f13c:594c:f3d0:3756] has quit [Ping timeout: 244 seconds]     
04:43 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]     
04:51 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
05:16 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has quit [Ping timeout: 264 seconds]     
05:23 -!- awesome_doge [~Thunderbi@206.190.233.196.16clouds.com] has joined #bitcoin-core-pr-reviews     
05:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]     
05:37 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
05:41 -!- awesome_doge [~Thunderbi@206.190.233.196.16clouds.com] has quit [Remote host closed the connection]     
05:43 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews     
05:53 -!- molz_ [mol@gateway/vpn/protonvpn/molly] has quit [Remote host closed the connection]     
05:53 -!- molz_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews     
06:17 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has quit [Remote host closed the connection]     
06:17 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews     
06:32 -!- sugarjig [d81eb60a@216.30.182.10] has joined #bitcoin-core-pr-reviews     
06:34 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has quit [Quit: awesome_doge]     
06:34 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews     
06:43 -!- AdamHock [~adamhock@c-71-62-227-125.hsd1.va.comcast.net] has joined #bitcoin-core-pr-reviews     
06:44 -!- AdamHock is now known as adam_hoc     
06:45 -!- adam_hoc [~adamhock@c-71-62-227-125.hsd1.va.comcast.net] has quit [Client Quit]     
07:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]     
07:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
07:15 -!- AdamHock [~adamhock@216.30.182.130] has joined #bitcoin-core-pr-reviews     
07:21 -!- jonatack [~jon@37.164.189.52] has quit [Read error: Connection reset by peer]     
07:34 -!- sugarjig [d81eb60a@216.30.182.10] has quit [Ping timeout: 240 seconds]     
07:35 -!- prayank [~andr0irc@2401:4900:30de:f516:f13c:594c:f3d0:3756] has joined #bitcoin-core-pr-reviews     
08:08 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:1d6d:3e8d:1dc3:5f7] has joined #bitcoin-core-pr-reviews     
08:11 -!- cguida [~Adium@2806:2f0:51c1:5cee:6971:7b6b:a235:6b0d] has quit [Ping timeout: 272 seconds]     
08:37 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]     
08:44 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
08:50 -!- alteralteregoism [c5b96172@197.185.97.114] has joined #bitcoin-core-pr-reviews     
08:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
08:58 -!- alteralteregoism [c5b96172@197.185.97.114] has quit [Ping timeout: 240 seconds]     
08:58 -!- ember_ [~ember@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:04 -!- alteralteregoism [c5b9602d@197.185.96.45] has joined #bitcoin-core-pr-reviews     
09:05 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
09:05 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
09:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
09:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
09:24 -!- outfawkesd [c636802e@static-198-54-128-46.cust.tzulo.com] has quit [Ping timeout: 240 seconds]     
09:28 < jnewbery> Hi folks. We'll get started in just over half an hour. Notes & questions are at https://bitcoincore.reviews/19438
09:31 -!- sugarjig [d81eb60a@216.30.182.10] has joined #bitcoin-core-pr-reviews     
09:32 -!- awesome_doge [~Thunderbi@1-171-104-114.dynamic-ip.hinet.net] has quit [Ping timeout: 265 seconds]     
09:36 -!- ivanacostarubio [~ivan@189.172.172.134] has joined #bitcoin-core-pr-reviews     
09:39 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Ping timeout: 244 seconds]     
09:41 -!- gniemeyer [~gniemeyer@c-71-198-251-246.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:42 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews     
09:48 -!- prayank1 [~Prashant_@2401:4900:30de:f516:4005:26a5:2d45:bb23] has joined #bitcoin-core-pr-reviews     
09:49 -!- awesome_doge1 [~Thunderbi@2001-b011-4010-3816-297c-40e3-f931-27ad.dynamic-ip6.hinet.net] has joined #bitcoin-core-pr-reviews     
09:50 -!- prayank [~andr0irc@2401:4900:30de:f516:f13c:594c:f3d0:3756] has quit [Ping timeout: 244 seconds]     
09:50 -!- prayank1 [~Prashant_@2401:4900:30de:f516:4005:26a5:2d45:bb23] has left #bitcoin-core-pr-reviews []     
09:52 -!- genef [~gene@198.167.192.15] has joined #bitcoin-core-pr-reviews     
09:53 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-bortepmibwsribej] has joined #bitcoin-core-pr-reviews     
09:53 -!- jonatack [~jon@37.172.241.248] has joined #bitcoin-core-pr-reviews     
09:54 -!- prayank [~andr0irc@2401:4900:30de:f516:883e:9a33:9b75:ccd3] has joined #bitcoin-core-pr-reviews     
09:54 -!- awesome_doge1 [~Thunderbi@2001-b011-4010-3816-297c-40e3-f931-27ad.dynamic-ip6.hinet.net] has quit [Ping timeout: 268 seconds]     
09:57 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
09:59 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews     
10:00 < glozow> hi     
10:00 < ember_> hi     
10:00 -!- maqusat [2578c6b7@37.120.198.183] has joined #bitcoin-core-pr-reviews     
10:00 < sugarjig> hi     
10:00 < ccdle12> hi     
10:00 < jnewbery> #startmeeting
10:00 < maqusat> hi     
10:00 < amiti> hi     
10:00 < glozow> happy 100th meeting!
10:00 < b10c> hi     
10:00 < Murch> hello
10:00 < prayank> hi     
10:01 < jnewbery> happy 100 everybody!
10:01 < schmidty> hi     
10:01 < genef> hi     
10:01 < michaelfolkson> hi     
10:01 < gniemeyer> woooo
10:01 < amiti> WOW... thats wild!!
10:01 < ivanacostarubio> hello... happy 100th!
10:01 < ember_> wow 100
10:01 < emzy> hi     
10:02 < michaelfolkson> Time to bury the first 50 PR review clubs?
10:02 < jnewbery> oooh maybe we're at 101 actually
10:02 < b10c> 💯
10:02 < jnewbery> whatever it is, welcome!
10:02 < glozow> 😱
10:02 < jnewbery> anyone here for the first time?
10:02 < sugarjig> Me!     
10:02 < jnewbery> sugarjig: welcome!
10:02 < genef> 2nd time, still count?
10:03 < sugarjig> Thanks!
10:03 < jnewbery> glad you could join us
10:03 < alteralteregoism> It's my first time here.
10:03 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews     
10:03 < glozow> genef: welcome, first time being a returning review clubbie!
10:03 < genef> :)     
10:03 < jnewbery> 2nd time doesn't count as first time. We call that an off-by-one bug
10:03 < ember_> welcome alteralteregoism
10:04 < gniemeyer> jnewberry: my first time
10:04 < b10c> welcome sugarjig alteralteregoism and gniemeyer!
10:04 < jnewbery> ok, couple of hints if it's your first time, and reminders if it's not: all questions are welcome! Everyone is here to learn.
10:04 -!- oldgoat5 [46bbba5f@ip70-187-186-95.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews     
10:04 < jnewbery> and 2: you don't have to ask to ask. If you have a question, just go right ahead and ask.
10:04 < jnewbery> more tips here: https://bitcoincore.reviews/your-first-meeting
10:05 < jnewbery> ok, who had time to review the PR this week? (y/n)
10:05 < genef> y     
10:05 < amiti> 0.5y
10:05 < glozow> 0.8y
10:05 < ccdle12> y     
10:05 < b10c> y     
10:05 < emzy> n     
10:05 < gniemeyer> n     
10:05 < michaelfolkson> y     
10:05 < ivanacostarubio> n     
10:05 < schmidty> n     
10:05 < sugarjig> 0.5y
10:05 < ember_> y     
10:05 < maqusat> just had time to glance over the diff
10:06 < maqusat> .5y     
10:06 < jnewbery> great. That's a lot of reviewers!
10:06 < jnewbery> First question: Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
10:06 -!- wt-bryan [a2c4dac9@162-196-218-201.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
10:06 < maqusat> Concept ACK
10:07 < genef> reviewed, ACK. manual code review, no test
10:07 < ember_> Concept ACK
10:07 < ccdle12> concept ack
10:07 < Murch> n     
10:07 < michaelfolkson> Concept ACK, Approach ACK. Read the links in the PR review club notes and then looked at the code. Didn't test
10:07 < jnewbery> does anyone want to give a short summary of the motivation?
10:07 < amiti> approach ACK ! I think its a clever way to make it simple to bury deployments & the way the enums / functions are defined provide some safety around accidentally mixing them up
10:08 < michaelfolkson> jnewbery: As you said in your notes we don't care how a soft fork was activated a long time after it has activated. "Technical debt"
10:09 -!- zas90 [62f93b5c@c-98-249-59-92.hsd1.va.comcast.net] has joined #bitcoin-core-pr-reviews     
10:09 < b10c> we want to make future softfork buries a small-as-possible code change
10:09 < glozow> yes we like to bury deployments, this PR is refactoring to make burying simpler
10:09 < jnewbery> michaelfolkson: right, that's the motivation for "burying" a deployment. This PR isn't burying any new deployments. What's it doing?
10:09 < ccdle12> it looks it provides a common interface for the code to switch on code paths according to predefined enums for certain softfork activations
10:09 < jnewbery> b10c glozow: exactly!
10:09 < jnewbery> ccdle12: yes
10:10 < jnewbery> let's get a bit more concrete
10:10 < michaelfolkson> Oh sure adding some helper functions to make it easier to bury future deployments
10:10 < jnewbery> How many ‘buried deployments’ are there? Where are they listed in the code?
10:10 < ivanacostarubio> easier way to deal with tecnical debt about burying deployments
10:10 < ccdle12> maybe 7-8?
10:10 < glozow> I counted 5: height in coinbase, CLTV, DER sigs, CSV, and segwit. They're in src/consensus/params.h.
10:11 < jnewbery> glozow: yus!
10:11 -!- effexzi [uid474242@gateway/web/irccloud.com/x-fbyhecdvuhnumzyc] has joined #bitcoin-core-pr-reviews     
10:11 -!- gchain [gustafmatr@gateway/shell/matrix.org/x-yufwyxqtvugipfum] has left #bitcoin-core-pr-reviews ["User left"]     
10:11 < jnewbery> https://github.com/bitcoin/bitcoin/blob/e72e062e5a8279864d746776dc9072c112ddc014/src/consensus/params.h#L14-L22
10:11 -!- gchain [gustafmatr@gateway/shell/matrix.org/x-yufwyxqtvugipfum] has joined #bitcoin-core-pr-reviews     
10:12 < jnewbery> A nice thing about this PR is that they're all enumerated now
10:12 < amiti> yeah, the PR makes it much easier to answer this question :)
10:12 < maqusat> 4, enum BuriedDeployment in consensus/params.h
10:12 < jnewbery> did anyone read the optech "soft fork activation" draft?
10:13 < jnewbery> I suppose we could argue that some of the very old satoshi-era softforks described here are also buried: https://deploy-preview-531--bitcoinops.netlify.app/en/topics/soft-fork-activation/#2009-hardcoded-height-consensus-nlocktime-enforcement
10:13 < maqusat> sorry 5 ;)
10:13 < jnewbery> since those were retroactively applied to the whole block chain and became part of the regular consensus rules
10:14 < jnewbery> but I like the answer 5
10:14 < amiti> that write up was fantastic!
10:14 < jnewbery> I agree!
10:14 < jnewbery> Onwards
10:14 < jnewbery> How many version bits deployments are there? Where are they listed in the code?
10:14 < glozow> question, is it ok to think of it as synonymous with BIP9 deployments?
10:15 < maqusat> 2, enum DeploymentPos in consensus/params.h
10:15 < glozow> I counted just 2, CSV and segwit but idk :(
10:15 < ccdle12> I think its `vDeployments` in chainparams?
10:15 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews     
10:16 < glozow> oh wait, i think i misunderstood the question. are we not talking about past deployments? :O
10:16 < jnewbery> glozow: right, two soft forks have been activated using version bits. What I meant to ask was "how many version bits deployments are defined in the code after this PR?"
10:16 < amiti> yeah, I think its the DeploymentPos values that are not MAX, which are assigned to chainparams vDeployments. so 2: testdummy and taproot.
10:17 < glozow> oh oops 🤦
10:17 < jnewbery> maqusat amiti: yes!
10:17 < michaelfolkson> glozow: BIP 8 and BIP 148 and BIP 91 are all version bits deployments. But in the codebase you'll only find BIP 9 reference
10:18 < jnewbery> and they're listed here: https://github.com/bitcoin/bitcoin/blob/e72e062e5a8279864d746776dc9072c112ddc014/src/consensus/params.h#L25-L31
10:18 < jnewbery> Next question. What are the advantages of using a buried deployment instead of a version bits deployment?
10:18 < b10c> It's super clear now, originaly tried to find the buried deployments and version bits on master...
10:19 < jnewbery> b10c: indeed. This is a very nice cleanup.
10:19 < amiti> with the version bits deployments there are more logical forks.. check the state to decide what validation rules to apply to a txn / block. with buried deployment you just assume the new rules apply
10:19 < jnewbery> amiti: right, it simplifies the code
10:19 < glozow> michaelfolkson: those are names of proposed activation methods not deployments
10:20 < jnewbery> any other motiviations for burying a deployment?
10:20 < ccdle12> removing technical debt/stale code
10:20 < michaelfolkson> glozow: BIP 148 was deployed in a non-Core release
10:21 < maqusat> limited bit space?
10:21 < jnewbery> ccdle12: I think that's the same as amiti's reason: simplifying the code
10:21 < ember_> maqusat versionbits get repurposed
10:22 < ember_> less logic, less potential for bugs, theoretically
10:22 < ccdle12> jnewbery: ah sorry, was just thinking in terms of just removing the code, I think I misread the original question
10:22 < jnewbery> maqusat: I _think_ the versionbits code already allowed bits to be reused if the dates don't overlap. It's certainly allowed in BIP9
10:22 < b10c> jnewbery: avoid deployment problems with super deep reorgs? not sure if the super deep reorgs are the bigger problem here
10:23 < glozow> if the code is still in there, IBD nodes will use it to calculate when to activate stuff when they're catching up. could it be possible to accidentally introduce a bug while we're touching it, and affect IBD nodes?
10:23 < glozow> i guess that falls into the technical debt category
10:23 < maqusat> oh ok thx
10:23 < jnewbery> b10c: that's not what I was thinking, but it is an interesting point. A very deep reorg could result in a consensus failure. We're talking a reorg of many years worth of blocks, and if that happens we have other problems
10:23 < jnewbery> Did anyone read the original buried deployments BIP?
10:24 < jnewbery> https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki#motivation
10:24 < michaelfolkson> jnewbery: I did, yeah
10:25 < maqusat> generally easier burying, less code changes. does it also allow for earlier testability (regtest)? seen that mentioned in one of original comments with motivations
10:25 < glozow> applying the logic for activation is more computationally expensive than just checking a block height
10:25 < michaelfolkson> Comments summary of BIP 90 was "Mostly Recommended for implementation, with some Discouragement"
10:25 < jnewbery> BIP 90 included performance as a motivation. The activation method before BIP 9 was ISM, and that was inefficient. Burying those ISM deployments is a performance win.
10:25 < jnewbery> BIP 90 is much more efficient because we cache the deployment state for each retarget period
10:26 < jnewbery> *BIP 9 is much more efficient
10:26 < michaelfolkson> I think the discouragement is in reference to that extremely large re-org risk and not burying too soon after activation
10:27 < prayank> jnewbery: BIP 90 is for achieving the same thing as this PR but Bitcoin Core already follows BIP 90. Sorry, I am confused.
10:27 < jnewbery> So the original motivation for BIP 90 was both performance and code simplicity. The performance part isn't such a consideration for burying BIP 9 deployments, but the code simplicity motivation is still there
10:28 < michaelfolkson> prayank: BIP 90 is just for buried deployments. This PR makes it easier to bury deployments. They were still possible before this PR
10:28 < jnewbery> prayank: there have been buried deployments in Bitcoin Core since BIP 90 was implemented. This PR simply refactors the code to make it simpler to bury future deployments
10:28 < b10c> prayank: this PR cleans the implementation of BIP 90 up
10:28 < prayank> Thanks
10:28 < jnewbery> let's keep moving! Since C++11, we generally prefer to use scoped enumerations. What are the advantages of using scoped enums? Are they used in this PR? Why?
10:29 < jonatack> hi     
10:29 < genef> scoped enums prevent leaking names/enum variants
10:29 < ccdle12> prevent implicit conversions
10:29 < glozow> Scoped enums are usually nice: the enumerators can't be implicitly converted to another type and they can be forward-declared.
10:29 < jonatack> scoped enums are...scoped, don't pollute the global namespace, and don't implicitly convert to int
10:30 < jnewbery> woohoo lots of c++ gurus in here :)
10:30 < b10c> but they aren't used here!
10:30 < glozow> leaking refers to, you can't confuse a `Blue::Berry` with `JNew::Berry`
10:30 < jonatack> with plain old enums, the enum type isn't explicitly defined
10:30 < jnewbery> glozow: it _is_ possible to forward declare an unscoped enum as long as you've explicitly declared the underlying type :p
10:30 < jonatack> it just has to be large enough to hold the enumerators
10:30 < glozow> jnewbery: ok tru
10:31 < jnewbery> jonatack: are you talking about the underlying type?
10:31 < glozow> here you can just say `Consensus::DEPLOYMENT_TAPROOT` when you're adding the activation code,
10:31 < glozow> and then you don't need to change it after you bury it. You just move `DEPLOYMENT_TAPROOT` from `DeploymentPos` to `DeploymentBuried`.
10:31 < jonatack> yes     
10:31 < jonatack> just went through these things for https://github.com/bitcoin/bitcoin/pull/21506
10:31 < glozow> they still don't leak into global namespace because they're in the `Consensus` namespace yeah?
10:31 < jonatack> "p2p, refactor: make NetPermissionFlags an enum class"
10:32 < jnewbery> jonatack: you can explicitly declare the underlying type (or not) for both scoped and unscoped enums
10:32 < jonatack> jnewbery: you can
10:32 < jonatack> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-enum
10:32 < jonatack> is a good resource
10:33 < amiti> glozow: +1
10:33 < jnewbery> glozow: v good! yes, the enum is declared in the Consensus namespace, so it's scoped to that namespace
10:33 < jnewbery> jonatack: yes! The cpp core guidelines are an excellent resource!
10:33 < jnewbery> everyone happy with the enums? Any questions or should we move on
10:34 < jnewbery> What is DeploymentEnabled() used for? Can it ever return false for a buried deployment?
10:34 < maqusat> determine if a deployment has a block height assigned. probably could return false for deployments that have got buried without ever being activated (not having block height assigned), though probably it's cleaner to remove such from the code altogether?
10:35 < glozow> For ongoing deployments, it checks the `BIP9Deployment` struct. For buried deployments, it uses the `DeploymentHeight()` to get a height.
10:35 < glozow> All of the buried deployments have assigned DeploymentHeights that are not `std::numeric_limits<int>::max()`, so the condition should always return true.
10:35 < glozow>    So, no, it can't return false for a buried deployment.
10:35 < glozow> I interpreted false to mean "we don't know about this deployment"
10:35 < glozow> "dis not possible"
10:36 < jnewbery> maquasat: yes, I agree
10:36 < jnewbery> glozow: is it possible for any of the buried deployments to have a height that is "std::numeric_limits<int>::max()"?
10:36 < glozow> is it? idk
10:37 < b10c> it can return false if you don't impelement the case in DeploymentHeight() (but it gave me compiler warnings when testing)
10:37 < genef> no, it's type is int16_t
10:37 < jnewbery> This is the logic we're talking about: https://github.com/bitcoin/bitcoin/blob/e72e062e5a8279864d746776dc9072c112ddc014/src/deploymentstatus.h#L46
10:38 < glozow> can you bury without assigning it an enumerator in `BuriedDeployment`?
10:38 < glozow> i confused :(
10:38 < jnewbery> glozow: oh no! What dis??? https://github.com/bitcoin/bitcoin/blob/e72e062e5a8279864d746776dc9072c112ddc014/src/chainparams.cpp#L483-L486
10:38 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
10:38 < jnewbery> "Segwit disabled for testing\n"
10:39 < glozow> ohhh
10:39 -!- Talkless [~Talkless@mail.dargis.net] has quit [Client Quit]     
10:39 < jnewbery> so currently, it _is_ possible for segwit to be 'undefined'. We use that in some of the tests.
10:39 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
10:39 -!- stortz [c8b9cbcf@unaffiliated/stortz] has joined #bitcoin-core-pr-reviews     
10:40 < jnewbery> Although I would very much like to get rid of that. It's not very useful, since segwit has been active for about 3 years now.
10:40 < jnewbery> Does that make sense to everyone?  DeploymentEnabled() can return false for segwit if we disabled it for testing
10:41 < glozow> yessir
10:41 < b10c> makes sense
10:41 < jnewbery> Next question
10:41 < jnewbery> What is the version bits cache used for?
10:42 < michaelfolkson> Caching per-period state for soft forks deployed in parallel
10:42 < b10c> caches the per-period and per-softfork deployment state. this works because all blocks in a period have the same deployment state
10:42 < michaelfolkson> Which will probably never get used?
10:43 < jnewbery> michaelfolkson: why do you say it's only for forks in parallel? All version bits deployments use the version bits cache
10:43 -!- prayank [~andr0irc@2401:4900:30de:f516:883e:9a33:9b75:ccd3] has quit [Read error: Connection reset by peer]     
10:43 -!- prayank [~andr0irc@2401:4900:30de:f516:883e:9a33:9b75:ccd3] has joined #bitcoin-core-pr-reviews     
10:43 < michaelfolkson> jnewbery: Gotcha, I misunderstood that. Thanks
10:44 < glozow> so you calculate the state for every block that's 0 mod 2016 and then use the cache for all the others?
10:44 -!- zas90 [62f93b5c@c-98-249-59-92.hsd1.va.comcast.net] has quit [Quit: Connection closed]     
10:45 < jnewbery> glozow: right
10:45 < jnewbery> state can only change on retarget boundaries
10:45 < b10c> where is the implemtation of the 'mod 2016'?
10:45 < b10c> must have missed it
10:46 < amiti> I think its in `GetStateFor`
10:46 < jnewbery> Here you go: https://github.com/bitcoin/bitcoin/blob/e72e062e5a8279864d746776dc9072c112ddc014/src/versionbits.cpp#L20-L23
10:46 < amiti> https://github.com/bitcoin/bitcoin/blob/master/src/versionbits.cpp#L22
10:46 < amiti> oh darn
10:46 < jnewbery> snap!
10:46 < amiti> you beat me :)
10:47 < jnewbery> nPeriod is 2016 for mainnet
10:47 < b10c> thanks jnewbry amiti!
10:47 < jonatack> jnewbery is really fast (recalling that scavenger hunt in NYC)
10:48 < prayank> lol     
10:48 < jnewbery> on regtest, the retarget period is 144. Look for nMinerConfirmationWindow in chainparams.cpp
10:49 < jnewbery> jonatack: (:
10:49 < glozow> why does regtest retarget at all?
10:49 < jnewbery> so we can test things
10:49 < sipa> glozow: because we want to be able to test the retargetting mechanism
10:50 < jnewbery> actually retarget boundaries are a fertile source of bugs
10:50 < jnewbery> there have been plenty of off-by-ones around those
10:50 < jnewbery> Next question. If the taproot soft fork is activated, and sometime later we want to bury that activation method, what changes need to be made to the code?
10:50 < glozow> oh mm. but it doesn't actually change difficulty right?
10:51 < jnewbery> (assuming this PR is merged)
10:51 < michaelfolkson> That why we have both DeploymentActiveAt and DeploymentActiveAfter? Because we are worried by off-by-ones?
10:51 < sugarjig> Is that where we would move the value from `DeploymentPos` to `BuriedDeployment`?
10:51 < amiti> I think you'd just need to move taproot from DeploymentPos enum to BuriedDeployment?
10:52 < sipa> glozow: consensus.fPowNoRetargeting = true;
10:52 < sipa> you're right; regtest doesn't actually retarget
10:52 < sipa> but it does still have versionbits logic
10:53 < glozow> that makes sense
10:53 < maqusat> move DEPLOYMENT_TAPROOT form DeploymentPos to BuriedDeployment
10:53 < ccdle12> apologies if this is a silly question but.. with burying taproot, I think theres still some taproot_active bools floating around, would those have to be removed as well to constitute a bury?
10:53 < felixweis> could on regtest have the diff change (recalculate) but not actually enforce?
10:54 < jnewbery> sugarjig amiti maqusat: exactly! There are a couple more small changes, but that's essentially it. Crucially, I don't think you'd need to change any logic in validation.
10:54 < glozow> also need to add the height ya?
10:54 < michaelfolkson> felixweis: I think that is what sipa and glozow concluded for regtest
10:54 < glozow> is there an rpc or something that could tell you when taproot activated?
10:54 < genef> what's the typical time to bury a deployment after activation?
10:55 < michaelfolkson> genef: SegWit was done 2 years after
10:55 < b10c> glozow: ha! :d
10:55 < jnewbery> ccdle: not a silly question at all! Where does the taproot_active bool get set?
10:55 < ccdle12> I saw it in policy.h
10:55 < ccdle12> https://github.com/bitcoin/bitcoin/blob/4a540683ec40393d6369da1a9e02e45614db936d/src/policy/policy.h#L111
10:55 < michaelfolkson> genef: No science though. Whenever a PR gets opened, reviewed and merged. As long as it isn't too soon after activation
10:56 < sipa> ccdle12: that's where it is used
10:56 < jnewbery> ccdle12: Right, it's in the function signature. Where does the caller of that function set it?
10:56 < genef> michaelfolkson: thanks
10:56 < ccdle12> ah right in validation.cpp before accepting the tx to the mempool
10:57 < b10c> glozow: I saw this: https://github.com/bitcoin/bitcoin/pull/16060/files#r290696589
10:57 < jnewbery> ccdle12: yes, and how is the bool set?
10:58 < amiti> glozow, b10c: yeah, getblockchaininfo has a `bip9_softforks` section that gives you `status`
10:58 < glozow> b10c: amiti: ooh thanks
10:58 < ccdle12> jnewbery: ThresholdState::ACTIVE
10:58 < jnewbery> It's set here: https://github.com/bitcoin/bitcoin/blob/e72e062e5a8279864d746776dc9072c112ddc014/src/validation.cpp#L718 by DeploymentActiveAt()
10:59 < jnewbery> so that code doesn't need to be changed to move the taproot deployment from versionbits to buried
10:59 < ccdle12> jnewbery: I see thank you!
10:59 < jnewbery> This is all assuming that this PR #19438 is merged, of course.
11:00 < jnewbery> ok, there was one more question that aj added that I'm afraid we don't have time for! We can leave it as an exercise for the reader.
11:00 < jnewbery> #endmeeting
11:00 < amiti> ono     
11:00 < felixweis> newer versions of the rpc seem to have gotten rid of the bip9_ prefix and its all under "softforks"
11:00 < maqusat> thank you!
11:00 < jnewbery> thanks for coming to review club 100/101/whatever it is!
11:00 < gniemeyer> thanks, lots to review
11:00 < genef> thanks for the meeting
11:00 < jnewbery> (counting is difficult)
11:00 < amiti> thank you!
11:00 < sugarjig> Thanks everyone! This was fun!
11:01 < felixweis> thanks jnewbery, all!
11:01 < alteralteregoism> Thank you.
11:01 < glozow> thanks jnewbery!
11:01 < ccdle12> thank you jnewbery!
11:01 < michaelfolkson> No urgency for this PR being merged right? Is there any benefit to it being merged in the same release as Taproot activation parameters? As long as it is merged before someone opens a PR to bury the Taproot deployment right?
11:01 < b10c> Thanks jnewbery!
11:01 < michaelfolkson> Thanks jnewbery
11:01 -!- sugarjig [d81eb60a@216.30.182.10] has left #bitcoin-core-pr-reviews []     
11:02 < emzy> Thanks jnewbery and all!
11:03 -!- maqusat [2578c6b7@37.120.198.183] has quit [Quit: Connection closed]     
11:03 -!- alteralteregoism [c5b9602d@197.185.96.45] has quit [Quit: Connection closed]     
11:04 < jonatack> Meeting log is up at https://bitcoincore.reviews/19438#meeting-log 🍰
11:06 -!- genef [~gene@198.167.192.15] has quit [Quit: genef]     
11:06 -!- gniemeyer [~gniemeyer@c-71-198-251-246.hsd1.ca.comcast.net] has quit [Quit: leaving]     
11:07 -!- musdom [~Thunderbi@202.186.69.84] has quit [Ping timeout: 245 seconds]     
11:10 < prayank> Thanks everyone. Will these meetings always be on IRC or we can move to other platforms in future. For example achow101 does few code review etc. on twitch livestream which works better for few reasons: 1
11:10 < prayank> 1. Video with screen sharing
11:10 < prayank> 2. Chat easily
11:11 -!- outfawkesd [c6368054@static-198-54-128-84.cust.tzulo.com] has joined #bitcoin-core-pr-reviews     
11:11 < prayank> 3. Tor can be used easily
11:11 < prayank> 4. More people can join and learn things
11:12 < prayank> 5. Audio
11:13 < michaelfolkson> I'm happy with these Wednesday sessions on IRC personally. You can access IRC using Tor. It doesn't stop other things and other sessions being on other platforms (like Andrew's Twitch stream)
11:13 < ember_> freenode has tor access via SASL but it's not easy
11:14 < michaelfolkson> It is a heavier ask for hosts to get set up on Twitch with screen sharing every week
11:14 < ember_> the amount of specificity and side reading that goes on during PR review, to me, doesn't lend itself to a stream where if I don't hear or see something, the info is lost
11:15 < prayank> Using IRC with TOR is not **easy**
11:15 < sipa> on freenode it isn't, indeed
11:15 < sipa> we could move to another server if that was an issue
11:15 < ember_>  yep
11:15 < prayank> That will be great
11:15 < ember_> other IRC servers have easy tor compatability
11:17 < sipa> i don't think the format lends itself well to a video stream... no log to search through, much harder to have interactivity with lots of people (i think it's more appropriate if just a few people talk)
11:17 < ember_> personally I see 1.) the privacy loss of not using Tor or 2.) the amount of effort developers need to spend to make their IRC use private as wasteful
11:18 < ember_> so I'd ack a migration to a tor routed irc server
11:18 < ember_> I also don't think many new devs appreciate how exposed they IP PII is when using irc
11:18 -!- wt-bryan [a2c4dac9@162-196-218-201.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Connection closed]     
11:19 < sipa> not sure what you mean with (2)
11:20 < michaelfolkson> I'm using a bouncer so I think I'm just leaking my remote server IP
11:20 < ember_> sipa e.g. one either chooses to use IRC with their True IP or everyone is forced to concoct their own method to obfuscate their IP (jump through SASL hoops, vpn, jumpbox etc)
11:20 < sipa> ember_: oh, sorry, i meant prayank's "2. Chat easily"
11:20 < ember_> ah     
11:20 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
11:21 < sipa> i'm on freenode using tor/sasl; i agree it's not easy
11:21 < ember_> freenode tor sasl requires an email, is that correct sipa?
11:22 < sipa> you need to be registered, i think, yes
11:22  * ember_ dreams of a lightning channel fidelity bond instead of clunky, dox your identity as fidelity bond
11:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]     
11:24 < prayank> sipa: Lot of difference. It's an app developed for such things. One example: I am using it on my phone. Minimized, watching a song on YouTube, back, oh I am logged out or something has gone wrong. On twitch I can do everything at the same time on phone.
11:24 < ember_> michaelfolkson if your bouncer doesn't run anything else -- no observability increase.  If you run anything else, there's association
11:25 -!- lukedashjr is now known as luke-jr     
11:25 < michaelfolkson> prayank: You look at the code on your phone?
11:25 < sipa> prayank: that seems like a very different goal; these review sessions are interactive code review, i hope you're not doing those on your phone
11:26 < prayank> sipa: it's not easy I agree. Maybe you remember or not. I tried asking few people including you. Didn't work. And I have been using Tor, XMPP, Darknet, etc. from few years. I just gave up. I thought let them see my IP I don't care. I need to participate in these things
11:26 < michaelfolkson> prayank: I can't watch say Andrew's Twitch streams on my phone. Need a bigger screen
11:26 < prayank> michaelfolkson: lot of times
11:27 < ember_> interface as a side channel for a nym's age
11:27 < prayank> sipa: I am on phone right now :)
11:27 < sipa> sure, so am i
11:27 < sipa> butni'm not reviewing code right now
11:27 < michaelfolkson> Chat is obviously fine on phone. Code review is highly restricted on such a small screen
11:28 < michaelfolkson> Navigation too.... much easier on a laptop
11:28 < prayank> I will and have already requested my younger brother to develop one app for me to make it easier to just click click and click. Nice GUI. Only for bitcoin core pr review club one app. He is good with Kotlin. Busy guy and thinks these things aren't important.
11:29 < sipa> i think this isn't worth spending time on
11:29 < sipa> you're not going to do decent code review on such a limited screen
11:29 < prayank> There is one GitHub app for Android
11:30 < ember_> prayank what's the resistance to using a laptop?
11:30 < ember_> assume one is available to begin with
11:30 < ember_> or RPI + screen
11:32 < prayank> ember_: I use it and also one desktop. But it makes it easier for me to be always connected and do more with mobile idk. I hate telegram and don't expect any groups that make sense on that app. So want this IRC channel which helps a lot of people to do more.
11:32 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews     
11:33 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews     
11:34 < jnewbery> prayank: all communication media come with their advantages and disadvantages. irc is no different. There are some very good reasons to use irc for these meetings:
11:34 < jnewbery> y of resources on how to review Bitcoin Core PRs. It's very quick to upload and host the logs on bitcoincore.reviews (it takes a couple of minutes). Once they're up there it's very quick to skim them or search for material.
11:34 < jnewbery> 1. One of the motivations for this club is to build up a library of resources on how to review Bitcoin Core PRs. It's very quick to upload and host the logs on bitcoincore.reviews (it takes a couple of minutes). Once they're up there it's very quick to skim them or search for material.
11:34 < jnewbery> 2. It doesn't require full attention from participants (unlike video). We have participants from all over the world, so the time of the meeting might be while someone's at work in the office, late at night, whenever. Having a text meeting is minimally disruptive in lots of circumstances.
11:35 < jnewbery> 3. Written english is usually much easier for non-native speakers than spoken english.
11:35 < jnewbery> 4. In video calls, often a small number of participants dominate. irc gives everyone the time to participate at their own pace.
11:35 < jnewbery> 5. multi-threaded conversation is much easier than video/voice.
11:35 < jnewbery> 6. people can participate with bad network connections/high latency/low hardware specs.
11:35 < jnewbery> I'm not saying it's the best medium, but there are some very compelling advantages.
11:35 < jnewbery> And it's not at all exclusive with having any other kind of meeting. If you wanted to set up a video call code review session, I'd wish you the best of luck!
11:37 -!- oldgoat5 [46bbba5f@ip70-187-186-95.oc.oc.cox.net] has quit [Quit: Ping timeout (120 seconds)]     
11:40 < prayank> jnewbery: Thanks. I think I will be okay if I can make one app which will allow anyone to join these sessions using Tor and Android app with better GUI and options. We assume everyone is  aware of IRC, how it works, these meetings and comfortable with using it. I just want to help want you are doing. I appreciate it and feel proud someone is someone took the initiative. Had mentioned this in one of the tweets rece
11:41 < prayank> https://twitter.com/prayankgahlot/status/1358617451831775236
11:48 < sipa> prayank: there are dozens of apps/services to make IRC easy; the only issue here I think is freenode making it hard to connect over tor (which i can't blame them for, spam is an issue, and via tor they can't block IPs)
11:49 < sipa> i don't see how you're going to address that, except by going somewhere else
11:55 < prayank> sipa: I tried few. Right now using AndroIRC. Works fine. For me it's just Tor I guess and for others many things that we/I can improve. Will think of some workaround or if you could share steps that someone can follow to successfully connect to this channel from scratch if using new Ubuntu VM maybe it can help.
11:56 -!- ember_ [~ember@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews []     
11:58 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Quit: leaving]     
12:04 -!- prayank [~andr0irc@2401:4900:30de:f516:883e:9a33:9b75:ccd3] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]     
12:12 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
12:19 -!- gchain [gustafmatr@gateway/shell/matrix.org/x-yufwyxqtvugipfum] has left #bitcoin-core-pr-reviews ["User left"]     
12:38 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has quit [Quit: Connection closed]     
12:43 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Quit: leaving]     
13:02 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
13:16 -!- stortz [c8b9cbcf@unaffiliated/stortz] has quit [Quit: Connection closed]     
13:21 -!- effexzi [uid474242@gateway/web/irccloud.com/x-fbyhecdvuhnumzyc] has quit [Quit: Connection closed for inactivity]     
13:34 -!- alteralteregoism [29b91d44@kgo18-nix01.hostserv.co.za] has joined #bitcoin-core-pr-reviews     
13:53 -!- alteralteregoism [29b91d44@kgo18-nix01.hostserv.co.za] has quit [Ping timeout: 240 seconds]     
14:09 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
14:12 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
14:20 < aj> #21378 has a patch that "buries" taproot -- https://github.com/bitcoin/bitcoin/pull/21378/commits/b8413a636284d883f73ccf3ff7a6fbfe56115440
14:54 -!- AdamHock [~adamhock@216.30.182.130] has quit []     
15:14 -!- prayank [~andr0irc@2401:4900:30de:f516:883e:9a33:9b75:ccd3] has joined #bitcoin-core-pr-reviews     
15:25 -!- jonatack [~jon@37.172.241.248] has quit [Ping timeout: 268 seconds]     
15:28 -!- ecola [~3cola@95.175.17.147] has quit [Ping timeout: 264 seconds]     
16:05 -!- molz_ [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 245 seconds]     
16:10 -!- mol [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews     
16:18 -!- ivanacos1 [~ivan@189.172.158.38] has joined #bitcoin-core-pr-reviews     
16:22 -!- ivanacostarubio [~ivan@189.172.172.134] has quit [Ping timeout: 272 seconds]     
17:49 -!- prayank [~andr0irc@2401:4900:30de:f516:883e:9a33:9b75:ccd3] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]     
18:41 -!- aqua42 [~aqua42@amsterdam3.jp.net] has quit [Quit: Ping timeout (120 seconds)]     
18:41 -!- aqua42 [~aqua42@amsterdam3.jp.net] has joined #bitcoin-core-pr-reviews     
20:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
20:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]     
20:29 -!- belcher_ is now known as belcher     
21:08 -!- cguida [~Adium@fixed-187-190-202-0.totalplay.net] has joined #bitcoin-core-pr-reviews     
21:08 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:1d6d:3e8d:1dc3:5f7] has quit [Read error: Connection reset by peer]     
21:22 < robert_spigler> What if you use Matrix? Since it's a bridge, only the public bridge needs to connect to freenode? You can use Tor?
21:58 -!- outfawkesd [c6368054@static-198-54-128-84.cust.tzulo.com] has quit [Ping timeout: 240 seconds]     
22:43 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews     
23:07 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-kbwqkqtcrzmuzgsc] has joined #bitcoin-core-pr-reviews     
23:12 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews     
23:12 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-kbwqkqtcrzmuzgsc] has left #bitcoin-core-pr-reviews ["User left"]     
23:12 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-kbwqkqtcrzmuzgsc] has joined #bitcoin-core-pr-reviews     
23:13 -!- mol [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 245 seconds]     
23:16 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-kbwqkqtcrzmuzgsc] has left #bitcoin-core-pr-reviews ["User left"]     
23:19 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-kbwqkqtcrzmuzgsc] has joined #bitcoin-core-pr-reviews     
23:32 -!- waxwing [~waxwing@unaffiliated/waxwing] has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in]     
23:33 -!- waxwing [~waxwing@193.29.57.116] has joined #bitcoin-core-pr-reviews     
23:33 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host]     
23:33 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-pr-reviews     
23:35 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
23:38 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
23:38 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
23:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
23:55 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:1d6d:3e8d:1dc3:5f7] has joined #bitcoin-core-pr-reviews     
23:58 -!- cguida [~Adium@fixed-187-190-202-0.totalplay.net] has quit [Ping timeout: 268 seconds]