--- Log opened Mon Mar 29 00:00:10 2021
00:37 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
00:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
01:02 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
01:10 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:11 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
01:15 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation
01:16 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
01:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
01:28 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
02:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
02:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
03:30 -!- CARO1 [~Cesar@2804:7f4:c29c:4804:78fa:c4bd:b524:1373] has joined ##taproot-activation
03:31 -!- CARO2 [~Cesar@201.86.222.14] has quit [Ping timeout: 240 seconds]
03:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
05:15 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
05:26 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
05:49 < roconnor> you are using testnet as a showstopper?
06:14 -!- stortz [b1982ea0@unaffiliated/stortz] has joined ##taproot-activation
06:19 -!- common [~common@unaffiliated/common] has quit [Remote host closed the connection]
06:19 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
06:31 < roconnor> s/using/arguing/
06:53 -!- mandelb[m] [mandelbmat@gateway/shell/matrix.org/x-obggytyizfhpdrlb] has joined ##taproot-activation
07:14 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
07:19 -!- adiabat_ [~adiabat@63.209.32.102] has quit [Ping timeout: 246 seconds]
07:36 -!- belcher_ is now known as belcher
07:43 -!- stortz [b1982ea0@unaffiliated/stortz] has quit [Quit: Connection closed]
07:53 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
08:36 < roconnor> Firstly, I believe the needs of testnet come secondary to the needs of mainnet.  If a technically superior code (of any kind, but in this particular case, code that doesn't have to worry about reorgs moving MTP time across retargeting boundaries) comes to mainnet, then testnet simply needs to adapt to it.  Testnet exists to test mainnet, and it isn't mainnet's job to satisfy testnet.
08:36 < roconnor> Secondly, even if I'm wrong above and mainnet is somehow subservient to testnet's needs, MTP is still not appropriate for activation on testnet because some schmuck is just going to come by and reorg testnet in such a way to entirely skip over the activation dates anyways, etc.
08:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
08:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
08:48 <@aj> roconnor: has there ever been a three month long reorg of testnet, not just an x000 block reorg? testnet doesn't have a lot of work compared to mainnet, but random testing still gives it a modest amount, so that sounds like nonsense to me... in any event, you can't skip the activation dates until after they've passed, so even if that were the case you could still use testnet to test out activation.
08:51 <@aj> roconnor: not being able to test things before live deployment is definitely a showstopper; fortunately we created signet in time for testing taproot, but it would be preferable to test the real deployment method on a live network than not. i considered not being able to do bip148-style mandatory signalling a showstopper for MTP previously, but now no longer do.
08:55 < roconnor> wasn't there like a 1-year testnet reorg once?  I guess I haven't been following testnet very carefully?
08:56 < roconnor> I don't understand your problem testing activation on testnet with heights?  Are you worried that testnet clients are not going to "upgrade on time" due to fast blocks?
08:59 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]
08:59 <@aj> roconnor: did you read the link? achow101 picked some heights to give a three month period; they were all mined on one day
09:03 < roconnor> what link are you refering to?
09:05 <@aj> hmm, i guess the discussions marked as resolved in the PR so it's not easy to find; https://github.com/bitcoin/bips/pull/1081#discussion_r600384908
09:09 < roconnor> I still don't quite get the value that we are supposed to be getting from a testnet activation here, but I'll let other people debate the importance of it.
09:13 <@aj> it lets miners check what happens if they signal on a live network before doing it on one that's worth money? i mean why would you ever not want to test on something as close to production as possible before doing it on production?
09:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
09:14 < roconnor> I mean, it doesn't really inform you want happens when things go awry, so testing on testnet first is of very limited value.
09:17 <@aj> i don't really see why you think that; it demonstrated things going awry for s2x https://github.com/btc1/bitcoin/issues/65 eg
09:18 < jeremyrubin> aj: one counterargument agaisnt using the same activation logic for testnet is that if testnet doesn't signal activate a fork and main does we don't really care
09:18 < roconnor> :D point taken.
09:18 < jeremyrubin> (maybe we'd just reboot testnet?)
09:20 < roconnor> aj: I'm not yet really convinced but I can at least see why someone could be convinced.
09:22 <@aj> jeremyrubin: "we don't really care" isn't really an argument either way? would be easy to either do a second deployment on testnet after mainnet had activated, or possibly to just talk to some miners and perhaps do a couple-of-month reorg of testnet so it is activated and everything's consistent?
09:22 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
09:22 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
09:22 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
09:24 < jeremyrubin> it's more an argument in favor of not considering testnet at all, as what happens there is irrelevant (may as well just flag day it?)
09:26 <@aj> roconnor: my testnet node, which isn't running all that often and probably doesn't have any data before 2018, has 2160 blocks as the longest reorg its ever seen fwiw
09:29 <@aj> jeremyrubin: no test infrastructure is ever "relevant" directly, that's the point? you still want it to be as close to production as you can make it (modulo costs) so that you catch bugs in test before production. if we couldn't do a UASF of some sort, then sure, that would be way too high a cost, and just flag daying would be fine (though still hard to do that in advance of production deployment
09:29 <@aj> which sucks)
09:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
09:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
09:44 -!- adiabat_ [~adiabat@63.209.32.102] has joined ##taproot-activation
11:25 < harding> I thought the stronger part of the argument was being able to use the same MTP-based activation parameters across all signets, whereas for BIP8 each signet would require different height-based parameters.  If we want people to create their own signets for testing various other protocols, but we also want those signets to be able to easily integrate improvements activated on mainnet and minimize patch difference from Bitcoin Core master, it
11:25 < harding> seems like a sig-net-ificant advantage to be able to use a single set of activation parameters for all signets (e.g. same signaling parameters as mainnet, but maybe a shorter activation delay so that any problems manifest on signets before they appear on mainnet).
11:27 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
11:28 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
11:35 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
11:43 < roconnor> using a shorter activation delay on signet / testnet isn't using a single set of activation parameters.
11:43 < roconnor> and using "close to" the same set of activation parameters doesn't seem much better than just using different activation parameters.  Either way they end up different.
11:45 < roconnor> But AJ's activation on testnet with heights is nearly impossible is a reasonable argument, even if it isn't entirely convincing to me.
11:47 < harding> roconnor: I meant a single set of activation parameters for all signets.
11:49 < harding> (We've previously tried to activate forks on testnet prior to activating them on mainnet, usually with lower required hashrate signaling on testnet as well, so I assumed we'd be doing something similar for taproot.)
11:51 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 268 seconds]
11:51 < roconnor> From my armchair I don't see enough advantage of using a single set of activation parameters across all signets (wouldn't you want to maybe sagger them anyways?), at least not enough to justify the added complexity of MTP.  But I'm not that familiar with signet infra, so my opinion on the matter is very low value.
11:51 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
12:35 < harding> How much extra review time do you think evaluating the extra complexity of MTP requires?  If it's, say 30 minutes per reviewer times a dozen reviewers, that seems very worth it to me to allow people to be able to spin up signets for the next year without messing aronud in chainparams.cpp.  If it's many hours per reviewer, then I think it would indeed be better to put the burden on signet administrators.  (That's independent of considerations
12:35 < harding>  about testnet, and also independent of my belief that using height creates extra work of its own in worrying about accellerated block production and communicating the larger range of dates for different signaling and activation phases.)
12:37 < roconnor> what's the burden on signet administrators?
12:37 < roconnor> 30 minutes per signet for descisions not affecting Bitcoin's consensus rules?
12:37 < harding> roconnor: having to modify chainparams.cpp (easy) and then get all of the 'net's users to run that exact same code (hard IMO).
12:39 < roconnor> For me it doesn't come close to the level of worrying about edge cases in Bitcoin consensus rules.  (Again because I'm not familiar with signet infrastructure, so I very well could be overly discounting it.)
12:55 < jeremyrubin> ahhh
12:55 < jeremyrubin> I think I get the signet argument now; you want to be able to use the same binary across all these signets?
13:00 < jeremyrubin> I think this is a great idea
13:01 < jeremyrubin> I think we can also be more liberal with putting features in core with signet release params so we can better take advantage of simultaneous upgrade development
13:02 < roconnor> how does one signet binary distinguish between different signets?
13:02 < roconnor> (at the risk of getting a little off topic)
13:02 < jeremyrubin> you pick different signer scripts
13:03 < roconnor> where is this choice made?
13:03 < jeremyrubin> signetchallenge I think?
13:03 < roconnor> is that something in bitcoin.conf?
13:03 < jeremyrubin> https://twitter.com/techmedia_think/status/1339700436190687232
13:07 < roconnor> got it.
13:08 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
13:08 < harding> Do you have any suggestions about how to reduce your level of worry about using MTP?
13:09 < jeremyrubin> roconnor: have you seen https://github.com/ajtowns/bitcoin/pull/5
13:09 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Quit: jonatack]
13:09 < jeremyrubin> would that help you feel more comfortable with the skipping periods issue?
13:09 < jeremyrubin> you can assure a min # of periods
13:09 < roconnor> My level of worry over MTP is probably lower than it sounds like.  It's just that my worries over testnet are even lower.
13:10 < harding> roconnor: ha, that's fair.
13:10 < jeremyrubin> roconnor: +1 -- the signet argument is compelling to me, much moreso than the testnet one
13:11 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
13:11 < jeremyrubin> harding: I think for the signet one you'd want the min-periods too IMO, because a signet with e.g. once a day blocks would not be able to have enough time to activate
13:11 < jeremyrubin> min period ensures compatibility with any blockrate
13:11 < roconnor> jeremyrubin: I don't get the purpose of pr 5
13:12 < jeremyrubin> roconnor: you get max(periods between start and stop time, min # of periods)
13:12 < roconnor> oh I see.
13:13 < jeremyrubin> so if you wanted to do something like mandatory signalling, you could always make it happen on the nTH period, which may or may not be the last period
13:13 < jeremyrubin> (that's not the express purpose, but it gets around the concern of having too few height periods)
13:14 < roconnor> I'm not terribly excitted.  Someone suggested for MTP ST we can select dates in the middle of expected regargetting periods.  If we got with MTP I hope we do that in such a way to attempt to get 7 retargeting periods worth of signalling.
13:14 < jeremyrubin> roconnor: that was me :)
13:14 < harding> jeremyrubin: sure, although anyone doing once-a-day blocks would either need to adjust the length of the signaling and lockin periods (2016 each) or wait 11 years for activation (2016 * 2 / 365).
13:14 < roconnor> jeremyrubin: well I like that idea of yours better. :)
13:16 < jeremyrubin> harding: sure, but the problem comes up around 1+eps hour blocks right?
13:17 < harding> jeremyrubin: for a three months deployment, yeah.
13:18 < jeremyrubin> I could see someone running an hour block signet for testing, since blocks taking an hour happens regularly
13:18 < harding> Yeah, an hour sounds plausible in a way that a day didn't to me.
13:20 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
13:21 < jeremyrubin> i think the main question to me is are we trying to get a release shipped or come up with the perfect code forever. things like min_period can be patched later pretty easily onto what's already there
13:21 < jeremyrubin> if it's come up with the perfect code forever... that might take a while
13:25  * harding shares the concern
13:50 -!- realname192 [~real@37.163.20.125] has joined ##taproot-activation
13:50 -!- realname192 [~real@37.163.20.125] has quit [Client Quit]
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:03 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
14:20 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
14:21 < achow101> I don't understand why you would want the same deployment for all signets
14:23 < achow101> for a signet, why do you even need a signaling mechanism? It's run by a central signet operator. They can just flag day it.
14:25 < achow101> and what do you do if the signet is started after the deployment has come and gone?
14:26 < achow101> istm signets have such a varied set of requirements and parameters that you can't bake in parameters for all signets.
14:27 < jeremyrubin> achow101: the idea is that all extant signets can use the same activation parameters as long as they are "honest" about their MTP settings
14:29 -!- CARO [~Cesar@2804:7f4:c29c:4804:78fa:c4bd:b524:1373] has joined ##taproot-activation
14:30 < achow101> almost the same could be achieved by setting the block height to fairly high and then having a period of super fast mining to reach that height whenever the signet operator wants to activate
14:30 < achow101> but I still maintain that it doesn't make sense to have the same deployment across all signets
14:31 -!- CARO1 [~Cesar@2804:7f4:c29c:4804:78fa:c4bd:b524:1373] has quit [Ping timeout: 246 seconds]
14:33 < jeremyrubin> achow101: and what if it's in the past on that signet already?
14:34 < achow101> same problem if mtp is already past timeout
14:34 < jeremyrubin> no, because some signets run with faster block rates
14:34 < jeremyrubin> so your MTP could still be in bound but not your height
14:42 < achow101> sure
14:43 < achow101> but frankly, signets are test networks where operators can set whatever chain parameters they want. I don't think it makes sense to let that block a better deployment method for mainnet
14:44 < achow101> there needs to be a better way to specify all of the chain parameters for a signet too, and that needs to include deployment parameters
14:46 < jeremyrubin> Ah so the difference is, and I didn't get this at first, is that the custom signet params are set-once
14:46 < jeremyrubin> you don't need to set anything additional or new for activations
14:46 < jeremyrubin> it should work automatically if the operator wants to enable it or not
14:47 < achow101> if I make a new custom signet right now, I might want different parameters for everything
14:47 < achow101> and I should be allowed to do that
14:47 < jeremyrubin> nothing stops you
14:47 < jeremyrubin> this just helps people who are using signet more within normal bounds for whatever
14:49 < achow101> so the argument is that with mtp, all _currently existing_ signets can activate at ~the same time
14:50 < achow101> but that means that any _future_ signets need to set their own activation parameters if they want the new rules
14:50 < jeremyrubin> not sure I follow
14:50 < achow101> conversely, with heights, all _future_ signets can activate when they reach the specified block heights. They can choose to mine faster if they want it right away, or set different parameters
14:51 < achow101> with heights, all _currently existing_ signets will activate differently, and some may not activate if they are past the height, so such signets will need to set different parameters
14:53 < achow101> my point is that either approach trades off the ability of some signets to activate without setting different parameters. with mtp, it prevents future signets. With height, it prevents some current signets
14:53 < jeremyrubin> ah; you're slightly wrong IMO -- a new signet in the future can backdate blocks
14:53 < jeremyrubin> there's already IIRC code support for backdating a # of blocks before creating the current tip
14:54 < jeremyrubin> so you can just backdate the activations you want (2016 blocks per activation)
14:54 < achow101> additionally as soon as we want to bury a deployment for a signet, this all goes to hell
14:55 < achow101> because that's height based
14:55 < jeremyrubin> yeah i'd need to look at how we're doing that -- I thoujgt I said something to that effect but I must have left it out
14:56 < jeremyrubin> when we bury for signet do we set it to 0?
14:57 < jeremyrubin> I think we've yet to bury a deployment with signet present
14:57 < achow101> won't work if you have an invalid spend in a before activation block
14:57 < achow101> the current default signet has had taproot always active
14:58 < achow101> backdating could work, but it means that everyone is stuck in ibd until you're done with that
14:58 < achow101> iirc, once bitcoind is out of ibd, it won't accept blocks that are backdated too far
15:00 < jeremyrubin> I think that's OK because you're just setting up the network for the first time
15:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
15:04 < achow101> I think that buried deployments makes the idea of sharing deployments across all signets to be untenable
15:06 < harding> If signets are only signing blocks by miners running the default policy rules, there should be no rule-violating transactions in history, so you can safely bury to height 0.  It's also trivial for a signet operator to test whether or not the chain will sync with a buried(0) deployment---just try syncing and see if you end up on the same chaintip.
15:07 < harding> default policy rules + the signet's custom rules, assuming they don't conflict with the fork being activated*
15:08 < achow101> testnet doesn't require standardness, not sure if signet does
15:09 < harding> Oh, hmm, I don't know either.
15:12 < achow101> looks like it is default required, but can be turned off with -acceptnonstdtxn. This is the same behavior of regtest.
15:30 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds]
15:30 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 265 seconds]
15:36 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
15:37 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
15:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
15:59 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
16:01 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
16:14 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
16:58 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Quit: Leaving]
17:35 -!- setpill [~setpill@81-175-133-63.bb.dnainternet.fi] has joined ##taproot-activation
17:35 -!- setpill [~setpill@81-175-133-63.bb.dnainternet.fi] has quit [Changing host]
17:35 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
17:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
18:05 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: setpill]
18:05 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
18:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:24 <@aj> achow101: you can't have a period of "super fast" mining on signet, it uses the same difficulty adjustment rules as mainnet.
18:25 <@aj> jeremyrubin: you can't bury signet soft forks at height 0 -- if you're testing a soft fork on a signet, then you should expect to test v1 of the soft-fork, mine some txns with it, discover bugs, then iterate to v2 of the soft-fork which would consider those txns invalid. provided v2 of the soft-fork activates at an MTP later than your v1 txns, that's fine; activating at height=0 and you force a
18:25 <@aj> potentially very large chain reorg
18:27 < ghost43> presumably difficulty is low on signet so you can just timewarp attack it :P
18:31 <@aj> if you make difficulty too low, it becomes easy to spam the network with headers which isn't super desirable; and we'd like to fix the timewarp attack some day, not rely on it...
18:34 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Read error: Connection reset by peer]
18:34 < ghost43> regardless I don't get it why hardcoding activation parameters that work for every signet is important. sounds like the a main point of signet is customisable parameters, so it should be ok to have to customise this param too. compared to mainnet activation; the defaults for signets imho should be almost irrelevant
18:34 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
18:38 < luke-jr> [01:24:02] <aj> achow101: you can't have a period of "super fast" mining on signet, it uses the same difficulty adjustment rules as mainnet. <-- no, it doesn't..
18:39 < luke-jr> oh, signet, not testnet
18:40 < luke-jr> frankly, if signet is going to be treated as more than a testnet, then we shouldn't have merged it. and testnets shouldn't interfere with production.
18:46 <@aj> ghost43: no, the main point of signet is to provide a chain that you can test things on before you do them on mainnet, that doesn't have testnet's unpredictability with blocks
18:47 <@aj> ghost43: apart from who gets to sign blocks, consensus params aren't any more configurable than mainnet's
18:49 < ghost43> aj: further up in the log there was discussion how someone might be running a signet that only mines one block per hour, and how regardless of that person having configured it as such soft fork activation should work there without additional configuration for them
18:50 < ghost43> my remark is simply that I don't such issues should be seriously considered. these are test networks. if they changed some parameters, be prepared to change others.
18:50 < ghost43> don't think*
18:53 < ghost43> after all, a test network can just be reset if all else fails
18:58 < ghost43> unless you specifically want to test the activation itself, we might as well just MTP flag day all testnets
18:58 -!- BenPrentice [49eec8c3@c-73-238-200-195.hsd1.ma.comcast.net] has joined ##taproot-activation
18:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
19:20 <@aj> ghost43: doing additional consensus configuration would have an impact on every user of the signet; seems a pretty bad choice to do it that way, instead of just mining ~4032 blocks roughly all at once to get it locked in directly. if you're only mining 1 block an hour, difficulty should be at minimum, so that shouldn't take too long.
19:23 <@aj> ghost43: an advantage of having many signets is that you can do different tests on them; it's probably better to be able to have a signet that just duplicates mainnet's rules while some other signet activates new soft forks early
19:35 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
19:39 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 276 seconds]
19:41 < harding> ghost43: I think the one-block-an-hour issue was in the context of https://github.com/ajtowns/bitcoin/pull/5 , not the the main MTP PR https://github.com/bitcoin/bitcoin/pull/21377
19:43 < ghost43> ah I guess I misunderstood then
20:03 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
20:05 -!- commmon [~common@unaffiliated/common] has quit [Ping timeout: 246 seconds]
20:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
20:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
20:33 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
20:41 -!- OP_NOP_ [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
20:42 -!- OP_NOP_ [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Client Quit]
20:45 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 268 seconds]
20:53 -!- PurpleBerries is now known as nioc
20:55 < achow101> aj: isn't the point of signets to have multiple of them? In that regard, having a fixed set of rules for all signets seems counter to that goal.
21:37 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
21:37 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
21:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
22:44 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
22:47 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
22:52 <@aj> achow101: different rules for soft-forks that aren't active yet makes sense, sure; not enforcing rules that are active on mainnet not so much
22:55 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
22:59 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
23:12 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]
23:14 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
23:14 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 268 seconds]
23:14 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
23:15 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
23:16 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
23:46 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has quit [Ping timeout: 246 seconds]
--- Log closed Tue Mar 30 00:00:11 2021