* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
@ 2021-03-17 8:21 Prayank
2021-03-19 10:45 ` Emil Pfeffer
0 siblings, 1 reply; 9+ messages in thread
From: Prayank @ 2021-03-17 8:21 UTC (permalink / raw)
To: emu; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]
> the last thing we need is
a rushed upgrade
Why do you think this is rushed? Speedy Trial will have few months and if UASF is required it won't involve activation immediately after ST fails. Taproot by 2022 doesn't look rushed approach IMO.
> We're not changing things that we worked out already.
Which things have we worked out that cannot be changed or not changed earlier?
> how long till we go back and change the coin supply?
Coin supply has nothing to do with soft fork activation mechanism IMO.
> I understand some of you have no patience and would like mass adoption tomorrow but those are exactly the people that do not have a say in Bitcoin development. If you want to get rich quick you do not care about Bitcoin.
Taproot activation or discussion about activation mechanism does not have 100% correlation with mass adoption. It just improves Bitcoin and helps few projects mentioned in https://en.bitcoin.it/wiki/Taproot_Uses
Nobody is talking about get rich quick schemes in Taproot Activation related meetings. At least I have not seen anyone.
> If you want faster development cycles then you have lightning to play with.
Better development cycles with less delay, less misinformation, less politics, less probability of things being exploited by mining pools or other people, organization etc. with their influence. Lightning Network is a separate project focused on layer 2 and I think it will also benefit from Taproot.
> we *DO NOT* change things we already established in the past
Interested to know who is "we" in this sentence and what are the "things" that cannot be changed.
> In order to solve the LOT debate lets give Wladimir the power to decide on his own and if he has no strong opinions he should just flip a coin.
LOT has become LOL. If this is about Bitcoin Core maintainers deciding things for Bitcoin Core, sure they already do. But users have the freedom to decide if they want to run it with default settings or use other implementation.
> MAST threshold can be even lower because it is not representative of an economic majority and it could speed up the upgrade.
Agree
> At this point involve as few people as possible and get it done. This is just about the software and the parameters of the new consesus.
Everyone should be welcome to participate in meetings, ask questions, learn more and contribute. I don't see anything wrong with it.
--
Prayank
[-- Attachment #2: Type: text/html, Size: 13426 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-17 8:21 [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC Prayank
@ 2021-03-19 10:45 ` Emil Pfeffer
2021-03-19 16:55 ` Prayank
0 siblings, 1 reply; 9+ messages in thread
From: Emil Pfeffer @ 2021-03-19 10:45 UTC (permalink / raw)
To: Prayank; +Cc: Bitcoin Dev
On Wed, Mar 17, 2021 at 09:21:39AM +0100, Prayank wrote:
> >??the last thing we need is
> a rushed upgrade
>
> Why do you think this is rushed? Speedy Trial will have few months and if UASF is required it won't involve activation immediately after ST fails. Taproot by 2022 doesn't look rushed approach IMO.
That depends on your perception of time. Back in the day we also had people that thought 10 min avg block time is too much.
Taproot by the end of 2022 *using a single activation method* is not rushed. Taproot
by 2022 by all means necessary is tyranny. (will add to this later on)
>
> >??We're not changing things that we worked out already.??
>
> Which things have we worked out that cannot be changed or not changed earlier?
>
Plenty. Starting from the parameters of bitcoin consensus to the way Bitcoin Core
is organized to the minimum time of 18 months an upgrade needs to last. (based on prior experience)
If you want to challenge any of the old rules it takes more than ignoring them
and doing whatever you feel like (is useful to get the result you want (again the tyrant theme)).
I would go as far as to say that 18 months is not ideal and we might need 24 to 36
and that any upgrade of this kind needs to take at least the amount of time the
previous one took but ideally longer.
The motivation is pretty straight forward. If you pretend users decide then you will
understand users have others things to do than continously keeping up with Bitcoin
and in order for them to make an informed decision there needs to be plenty of time.
Otherwise you're repeating the tyranical argument which has become a recurring theme
of the discourse of some of the Bitcoin Core developers. (which is a loose term)
> > how long till we go back and change the coin supply?
>
> Coin supply has nothing to do with soft fork activation mechanism IMO.
Thats true but not what I said.
>
> > I understand??some of you have no patience and would like mass adoption tomorrow but??those are exactly the people that do not have a say in Bitcoin development. If you want to get rich quick you do not care about Bitcoin.
>
> Taproot activation or discussion about activation mechanism does not have 100% correlation with mass adoption. It just improves Bitcoin and helps few projects mentioned in??https://en.bitcoin.it/wiki/Taproot_Uses
> Nobody is talking about get rich quick schemes in Taproot Activation related meetings. At least I have not seen anyone.
>
Thats also true but also not what I said.
> > If you??want faster development??cycles then you have lightning to play with.
>
> Better development cycles with less delay, less misinformation, less politics, less probability of things being exploited by mining pools or other people, organization etc. with their influence. Lightning Network is a separate project focused on layer 2 and I think it will also benefit from Taproot.
>
This is the recurring theme of the tyrant that shows up in a lot of the posts on this
list.
Who is this entity that gets to decide what happens regardless of what everyone
else has to say? You seem to believe that there exists some entity that gets to decide what goes on and gets to exclude anyone it wants from the decision making process.
> >??we *DO NOT* change things we already established in the past
>
> Interested to know who is "we" in this sentence and what are the "things" that cannot be changed.
"we" is a reference to "we're all Satoshi" and the "things" you will learn by learning the past.
>
> >??In order to solve the LOT debate lets give Wladimir the power??to decide on his own and if he has no strong opinions he should just flip a coin.
>
> LOT has become LOL. If this is about Bitcoin Core maintainers deciding things for Bitcoin Core, sure they already do. But users have the freedom to decide if they want to run it with default settings or use other implementation.
This is your way of passing the buck around. If you do not yet know what your
responsabilities are that does not make you not responsable for anything.
Bitcoin Core has responsabilities regardless of the rethoric.
>
> >??MAST threshold can be even lower because it is not representative of an economic majority??and it could speed up the upgrade.
>
> Agree
>
> >??At this point involve as few people as possible and get it done. This is just about the??software and the parameters of the new consesus.
>
> Everyone should be welcome to participate in meetings, ask questions, learn more and contribute. I don't see anything wrong with it.
That depends on the scope of the meetings. If the meeting is about making progress on
an issue very few people have any clue about then it is desirable that the people
that are looking to learn should do so using other venues.
> --
> Prayank
--
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-19 10:45 ` Emil Pfeffer
@ 2021-03-19 16:55 ` Prayank
0 siblings, 0 replies; 9+ messages in thread
From: Prayank @ 2021-03-19 16:55 UTC (permalink / raw)
To: Emil Pfeffer; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]
> back in the day we also had people that thought 10 min avg block time is too much.
Not sure what some people thought about block time interval has to do with me. Also these are the things written by Greg Maxwell and Chris Belcher about it that I agree with and been sharing from sometime now on many platforms:
https://twitter.com/prayankgahlot/status/1269164956899049474
https://bitcoin.stackexchange.com/a/103289/
> Starting from the parameters of bitcoin consensus to the way Bitcoin Core is organized to the minimum time of 18 months an upgrade needs to last. (based on prior experience) If you want to challenge any of the old rules it takes more than ignoring them and doing whatever you feel like (is useful to get the result you want (again the tyrant theme)).
I was assuming Bitcoin is a protocol for p2p decentralized network and Bitcoin Core is just one implementation which is used by most of the people for lot of reasons but things can be improved and I am hopeful will improve with time. Users were, are and will be free to run whatever they feel like: Bitcoin Core or fork of Bitcoin Core or Other implmenations but still use Bitcoin.
> You seem to believe that there exists some entity that gets to decide what goes on and gets to exclude anyone it wants from the decision making process.
No I don't. You seem to have lot of assumptions. My comments were expectations from the people who are more experienced than me and know more about Bitcoin development. Things can change, you can always go out of the box to improve things.
> "we" is a reference to "we're all Satoshi" and the "things" you will learn by learning the past.
Satoshi if was a person and not group would be disappointed about few things but anyways. "We" should not discourage people from discussion about soft forks that everyone agrees will improve Bitcoin. I don't know everything about past but again thanks for the assumptions.
> If the meeting is about making progress on an issue very few people have any clue about then it is desirable that the people that are looking to learn should do so using other venues.
Any suggestions which venues will work better for Taproot related meeting that you don't have issues with?
--
Prayank
[-- Attachment #2: Type: text/html, Size: 2940 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-15 17:20 Luke Dashjr
2021-03-15 19:14 ` Jeremy
@ 2021-03-16 17:42 ` Emil Pfeffer
1 sibling, 0 replies; 9+ messages in thread
From: Emil Pfeffer @ 2021-03-16 17:42 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
On Mon, Mar 15, 2021 at 05:20:04PM +0000, Luke Dashjr via bitcoin-dev wrote:
> At the previous meeting, there was consensus for BIP8 activation parameters
> except for LOT, assuming a release around this time. Since then, a release
> has not occurred, and the new idea of Speedy Trial has been proposed to
> preempt the original/main activation plan.
>
> It's probably a good idea to meet up again to discuss these things and adjust
> accordingly.
>
> Agenda:
>
> - Speedy Trial: Can we get a comparable consensus on the proposal?
> (Note: current draft conflicts with original plan timeline)
Definitely not. This looks like a hijacking attempt.
We are already bombarded with too much information, the last thing we need is
a rushed upgrade. Even if it works out it is not a good precedent.
The current timeline of 18 months if the minimum that is acceptable for upgrades
such as taproot. We're not changing things that we worked out already. What next?
and how long till we go back and change the coin supply?
I understand some of you have no patience and would like mass adoption tomorrow
but those are exactly the people that do not have a say in Bitcoin development.
if you want to get rich quick you do not care about Bitcoin. If you want faster
development cycles then you have lightning to play with.
I have to reiterate: we *DO NOT* change things we already established in the past.
There are reasons everything is as it is and if you want to develop Bitcoin you have
to build upon the already established rules.
> - Main activation, post ST: Moving startheight (and timeoutheight?) later
> is probably a good idea at this point, both because too little progress has
> been made on it, and to avoid the conflict with the current ST draft.
There is no conflict. We're not upgrading Bitcoin using fancy new tools.
We're still on track with the already established timeline.
Although one is better than the other it doesn't really matter because we know
which way is going to go. In order to solve the LOT debate lets give Wladimir the
power to decide on his own and if he has no strong opinions he should just flip a coin.
the MAST threshold can be even lower because it is not representative of an economic
majority and it could speed up the upgrade.
>
> - Making progress: To date, too few people have been involved in materialising
> the main activation plan. If it's going to move forward, more people need to
> get actively involved. This should not wait for ST to complete, unless we
> want another 4-5 month slip of the timeline.
Nope. This is not the time where people need to get involved. There is no need for
more noise. People will get involved progressivly as time advances but as long
as Core does not release the parameters of the game there are no incentives for
the actors that will play the Taproot upgrade to show up. If Taproot is what the
market wants then the game theoretics of Bitcoin will get us there but since an
upgrade essentially means a change in consensus then some disturbance is expected and guaranteed.
At this point involve as few people as possible and get it done. This is just about
the software and the parameters of the new consesus. Theres plenty of time
for the show that's about to come, the market will do what the market does.
Worst case scenario Luke get some people behind and fork off Core with LOT=true and
lower MAST threshold. The market wants to play.
>
> This meeting is tentatively scheduled for *tomorrow*, March 16th at the usual
> time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If turnout
> is too low, we can postpone it a week, but it'd be nice to get things
> resolved and moving sooner.
>
> As a reminder, the channel is also open for ongoing discussion 24/7, and there
> is a web chat client here:
>
> https://webchat.freenode.net/?channel=##taproot-activation
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-15 20:59 ` Jeremy
@ 2021-03-15 21:46 ` Luke Dashjr
0 siblings, 0 replies; 9+ messages in thread
From: Luke Dashjr @ 2021-03-15 21:46 UTC (permalink / raw)
To: Jeremy; +Cc: Bitcoin Protocol Discussion
I am referring to the timeline and recommendation from the meeting on February
16th, which has been slowly making progress toward a release:
https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
The first period from height 693504-695520 here overlaps with the last period
of AChow's ST pull request.
A release today is impossible of course. But 1 or 2 days late is nothing
compared to waiting a week and not having even gotten started. :)
I expect/hope that there will be consensus to adapt around ST, shifting
everything later, but I'm just one person.
roconnor pointed out that the best solution is probably to just enclose ST's
timeline; something like this:
https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files#diff-e43ac101b32b6804209cfdf26da4d122e54b994eb7f1538d4378f6a508dab817L529
Luke
On Monday 15 March 2021 20:59:11 Jeremy wrote:
> Can you expand on the timeline issue? Which timelines are incompatible and
> why?
>
> It does seem like a release done *today* cannot happen anyways, so it
> sounds like it's already too late... or do you mean beginning the release
> process today?
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr <luke@dashjr•org> wrote:
> > While I agree 24 hours is too short notice, if someone wishes to insist
> > on keeping the current timeline, software supporting it should be
> > released _today_. Putting the meeting off a week would almost necessarily
> > imply rejection of any desires to stick to the original plan.
> >
> > So for that reason, I think we need to at least try to have a meeting
> > tomorrow, at least to give anyone who won't agree to such a delay a
> > chance to
> > speak up before it's too late, and have his argument fairly considered.
> >
> > We can still have a meeting next week. The idea of having one every other
> > week
> > seems like a good idea to avoid this in the future, too.
> >
> > Luke
> >
> > On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > > Please announce such meetings with more than ~24 hours notice -- this
> > > has happened several times and while I recognize the pace of
> > > development on this issue I think that slotting a consensus meeting
> > > with less than 24 hours is inappropriate.
> > >
> > > I think we should proactively postpone it a week so that there isn't an
> > > arbitrary "too low turnout" measure and instead anyone who really wants
> >
> > to
> >
> > > be present for the meeting can plan to be.
> > >
> > > So as not to lose momentum on having a discussion, I propose to plan to
> > > hold a general discussion tomorrow at that time and a meeting (with the
> > > intent of resolving issues in a more binding way) next week. It may be
> > > a good idea to hold the time slot every other week for the next while
> > > so
> >
> > that
> >
> > > we can avoid this 24 hour thing altogether.
> > >
> > > It sucks to lose another week but a precedent of 24 hour notice
> > > meetings for non urgent changes is very negative.
> > >
> > > (This isn't any comment on if ST is OK or not -- the schedules proposed
> >
> > for
> >
> > > ST thus far seem acceptable to me)
> > >
> > > Best,
> > >
> > > Jeremy
> > > --
> > > @JeremyRubin <https://twitter.com/JeremyRubin>
> > > <https://twitter.com/JeremyRubin>
> > >
> > >
> > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> > >
> > > bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > > At the previous meeting, there was consensus for BIP8 activation
> > > > parameters
> > > > except for LOT, assuming a release around this time. Since then, a
> > > > release has not occurred, and the new idea of Speedy Trial has been
> > > > proposed to preempt the original/main activation plan.
> > > >
> > > > It's probably a good idea to meet up again to discuss these things
> > > > and adjust
> > > > accordingly.
> > > >
> > > > Agenda:
> > > >
> > > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > > > (Note: current draft conflicts with original plan timeline)
> > > >
> > > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> >
> > later
> >
> > > > is probably a good idea at this point, both because too little
> >
> > progress
> >
> > > > has
> > > > been made on it, and to avoid the conflict with the current ST
> > > > draft.
> > > >
> > > > - Making progress: To date, too few people have been involved in
> > > > materialising
> > > > the main activation plan. If it's going to move forward, more
> > > > people need to
> > > > get actively involved. This should not wait for ST to complete,
> >
> > unless
> >
> > > > we want another 4-5 month slip of the timeline.
> > > >
> > > > This meeting is tentatively scheduled for *tomorrow*, March 16th at
> > > > the usual
> > > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > > > turnout
> > > > is too low, we can postpone it a week, but it'd be nice to get things
> > > > resolved and moving sooner.
> > > >
> > > > As a reminder, the channel is also open for ongoing discussion 24/7,
> >
> > and
> >
> > > > there
> > > > is a web chat client here:
> > > >
> > > > https://webchat.freenode.net/?channel=##taproot-activation
> > > >
> > > > Luke
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists•linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-15 19:37 ` Luke Dashjr
@ 2021-03-15 20:59 ` Jeremy
2021-03-15 21:46 ` Luke Dashjr
0 siblings, 1 reply; 9+ messages in thread
From: Jeremy @ 2021-03-15 20:59 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4325 bytes --]
Can you expand on the timeline issue? Which timelines are incompatible and
why?
It does seem like a release done *today* cannot happen anyways, so it
sounds like it's already too late... or do you mean beginning the release
process today?
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr <luke@dashjr•org> wrote:
> While I agree 24 hours is too short notice, if someone wishes to insist on
> keeping the current timeline, software supporting it should be released
> _today_. Putting the meeting off a week would almost necessarily imply
> rejection of any desires to stick to the original plan.
>
> So for that reason, I think we need to at least try to have a meeting
> tomorrow, at least to give anyone who won't agree to such a delay a chance
> to
> speak up before it's too late, and have his argument fairly considered.
>
> We can still have a meeting next week. The idea of having one every other
> week
> seems like a good idea to avoid this in the future, too.
>
> Luke
>
>
> On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > Please announce such meetings with more than ~24 hours notice -- this has
> > happened several times and while I recognize the pace of development on
> > this issue I think that slotting a consensus meeting with less than 24
> > hours is inappropriate.
> >
> > I think we should proactively postpone it a week so that there isn't an
> > arbitrary "too low turnout" measure and instead anyone who really wants
> to
> > be present for the meeting can plan to be.
> >
> > So as not to lose momentum on having a discussion, I propose to plan to
> > hold a general discussion tomorrow at that time and a meeting (with the
> > intent of resolving issues in a more binding way) next week. It may be a
> > good idea to hold the time slot every other week for the next while so
> that
> > we can avoid this 24 hour thing altogether.
> >
> > It sucks to lose another week but a precedent of 24 hour notice meetings
> > for non urgent changes is very negative.
> >
> > (This isn't any comment on if ST is OK or not -- the schedules proposed
> for
> > ST thus far seem acceptable to me)
> >
> > Best,
> >
> > Jeremy
> > --
> > @JeremyRubin <https://twitter.com/JeremyRubin>
> > <https://twitter.com/JeremyRubin>
> >
> >
> > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> >
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > At the previous meeting, there was consensus for BIP8 activation
> > > parameters
> > > except for LOT, assuming a release around this time. Since then, a
> > > release has not occurred, and the new idea of Speedy Trial has been
> > > proposed to preempt the original/main activation plan.
> > >
> > > It's probably a good idea to meet up again to discuss these things and
> > > adjust
> > > accordingly.
> > >
> > > Agenda:
> > >
> > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > > (Note: current draft conflicts with original plan timeline)
> > >
> > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> later
> > > is probably a good idea at this point, both because too little
> progress
> > > has
> > > been made on it, and to avoid the conflict with the current ST draft.
> > >
> > > - Making progress: To date, too few people have been involved in
> > > materialising
> > > the main activation plan. If it's going to move forward, more people
> > > need to
> > > get actively involved. This should not wait for ST to complete,
> unless
> > > we want another 4-5 month slip of the timeline.
> > >
> > > This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> > > usual
> > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > > turnout
> > > is too low, we can postpone it a week, but it'd be nice to get things
> > > resolved and moving sooner.
> > >
> > > As a reminder, the channel is also open for ongoing discussion 24/7,
> and
> > > there
> > > is a web chat client here:
> > >
> > > https://webchat.freenode.net/?channel=##taproot-activation
> > >
> > > Luke
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists•linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 6359 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-15 19:14 ` Jeremy
@ 2021-03-15 19:37 ` Luke Dashjr
2021-03-15 20:59 ` Jeremy
0 siblings, 1 reply; 9+ messages in thread
From: Luke Dashjr @ 2021-03-15 19:37 UTC (permalink / raw)
To: Jeremy; +Cc: Bitcoin Protocol Discussion
While I agree 24 hours is too short notice, if someone wishes to insist on
keeping the current timeline, software supporting it should be released
_today_. Putting the meeting off a week would almost necessarily imply
rejection of any desires to stick to the original plan.
So for that reason, I think we need to at least try to have a meeting
tomorrow, at least to give anyone who won't agree to such a delay a chance to
speak up before it's too late, and have his argument fairly considered.
We can still have a meeting next week. The idea of having one every other week
seems like a good idea to avoid this in the future, too.
Luke
On Monday 15 March 2021 19:14:02 Jeremy wrote:
> Please announce such meetings with more than ~24 hours notice -- this has
> happened several times and while I recognize the pace of development on
> this issue I think that slotting a consensus meeting with less than 24
> hours is inappropriate.
>
> I think we should proactively postpone it a week so that there isn't an
> arbitrary "too low turnout" measure and instead anyone who really wants to
> be present for the meeting can plan to be.
>
> So as not to lose momentum on having a discussion, I propose to plan to
> hold a general discussion tomorrow at that time and a meeting (with the
> intent of resolving issues in a more binding way) next week. It may be a
> good idea to hold the time slot every other week for the next while so that
> we can avoid this 24 hour thing altogether.
>
> It sucks to lose another week but a precedent of 24 hour notice meetings
> for non urgent changes is very negative.
>
> (This isn't any comment on if ST is OK or not -- the schedules proposed for
> ST thus far seem acceptable to me)
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
>
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> > At the previous meeting, there was consensus for BIP8 activation
> > parameters
> > except for LOT, assuming a release around this time. Since then, a
> > release has not occurred, and the new idea of Speedy Trial has been
> > proposed to preempt the original/main activation plan.
> >
> > It's probably a good idea to meet up again to discuss these things and
> > adjust
> > accordingly.
> >
> > Agenda:
> >
> > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > (Note: current draft conflicts with original plan timeline)
> >
> > - Main activation, post ST: Moving startheight (and timeoutheight?) later
> > is probably a good idea at this point, both because too little progress
> > has
> > been made on it, and to avoid the conflict with the current ST draft.
> >
> > - Making progress: To date, too few people have been involved in
> > materialising
> > the main activation plan. If it's going to move forward, more people
> > need to
> > get actively involved. This should not wait for ST to complete, unless
> > we want another 4-5 month slip of the timeline.
> >
> > This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> > usual
> > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > turnout
> > is too low, we can postpone it a week, but it'd be nice to get things
> > resolved and moving sooner.
> >
> > As a reminder, the channel is also open for ongoing discussion 24/7, and
> > there
> > is a web chat client here:
> >
> > https://webchat.freenode.net/?channel=##taproot-activation
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
2021-03-15 17:20 Luke Dashjr
@ 2021-03-15 19:14 ` Jeremy
2021-03-15 19:37 ` Luke Dashjr
2021-03-16 17:42 ` Emil Pfeffer
1 sibling, 1 reply; 9+ messages in thread
From: Jeremy @ 2021-03-15 19:14 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]
Please announce such meetings with more than ~24 hours notice -- this has
happened several times and while I recognize the pace of development on
this issue I think that slotting a consensus meeting with less than 24
hours is inappropriate.
I think we should proactively postpone it a week so that there isn't an
arbitrary "too low turnout" measure and instead anyone who really wants to
be present for the meeting can plan to be.
So as not to lose momentum on having a discussion, I propose to plan to
hold a general discussion tomorrow at that time and a meeting (with the
intent of resolving issues in a more binding way) next week. It may be a
good idea to hold the time slot every other week for the next while so that
we can avoid this 24 hour thing altogether.
It sucks to lose another week but a precedent of 24 hour notice meetings
for non urgent changes is very negative.
(This isn't any comment on if ST is OK or not -- the schedules proposed for
ST thus far seem acceptable to me)
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> At the previous meeting, there was consensus for BIP8 activation
> parameters
> except for LOT, assuming a release around this time. Since then, a release
> has not occurred, and the new idea of Speedy Trial has been proposed to
> preempt the original/main activation plan.
>
> It's probably a good idea to meet up again to discuss these things and
> adjust
> accordingly.
>
> Agenda:
>
> - Speedy Trial: Can we get a comparable consensus on the proposal?
> (Note: current draft conflicts with original plan timeline)
>
> - Main activation, post ST: Moving startheight (and timeoutheight?) later
> is probably a good idea at this point, both because too little progress
> has
> been made on it, and to avoid the conflict with the current ST draft.
>
> - Making progress: To date, too few people have been involved in
> materialising
> the main activation plan. If it's going to move forward, more people
> need to
> get actively involved. This should not wait for ST to complete, unless we
> want another 4-5 month slip of the timeline.
>
> This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> usual
> time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> turnout
> is too low, we can postpone it a week, but it'd be nice to get things
> resolved and moving sooner.
>
> As a reminder, the channel is also open for ongoing discussion 24/7, and
> there
> is a web chat client here:
>
> https://webchat.freenode.net/?channel=##taproot-activation
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5273 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
@ 2021-03-15 17:20 Luke Dashjr
2021-03-15 19:14 ` Jeremy
2021-03-16 17:42 ` Emil Pfeffer
0 siblings, 2 replies; 9+ messages in thread
From: Luke Dashjr @ 2021-03-15 17:20 UTC (permalink / raw)
To: bitcoin-dev
At the previous meeting, there was consensus for BIP8 activation parameters
except for LOT, assuming a release around this time. Since then, a release
has not occurred, and the new idea of Speedy Trial has been proposed to
preempt the original/main activation plan.
It's probably a good idea to meet up again to discuss these things and adjust
accordingly.
Agenda:
- Speedy Trial: Can we get a comparable consensus on the proposal?
(Note: current draft conflicts with original plan timeline)
- Main activation, post ST: Moving startheight (and timeoutheight?) later
is probably a good idea at this point, both because too little progress has
been made on it, and to avoid the conflict with the current ST draft.
- Making progress: To date, too few people have been involved in materialising
the main activation plan. If it's going to move forward, more people need to
get actively involved. This should not wait for ST to complete, unless we
want another 4-5 month slip of the timeline.
This meeting is tentatively scheduled for *tomorrow*, March 16th at the usual
time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If turnout
is too low, we can postpone it a week, but it'd be nice to get things
resolved and moving sooner.
As a reminder, the channel is also open for ongoing discussion 24/7, and there
is a web chat client here:
https://webchat.freenode.net/?channel=##taproot-activation
Luke
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-03-19 16:55 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-17 8:21 [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC Prayank
2021-03-19 10:45 ` Emil Pfeffer
2021-03-19 16:55 ` Prayank
-- strict thread matches above, loose matches on Subject: below --
2021-03-15 17:20 Luke Dashjr
2021-03-15 19:14 ` Jeremy
2021-03-15 19:37 ` Luke Dashjr
2021-03-15 20:59 ` Jeremy
2021-03-15 21:46 ` Luke Dashjr
2021-03-16 17:42 ` Emil Pfeffer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox