Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Jeremy via bitcoin-dev]

ACK adding Kalle.

Kalle is a qualified reviewer / editor and well suited for this role.
--
@JeremyRubin 



On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.
>
> Since there is no explicit process to adding BIP editors, IMO it should be
> fine to use BIP 2's Process BIP progression:
>
> > A process BIP may change status from Draft to Active when it achieves
> > rough consensus on the mailing list. Such a proposal is said to have
> > rough consensus if it has been open to discussion on the development
> > mailing list for at least one month, and no person maintains any
> > unaddressed substantiated objections to it.
>
> A Process BIP could be opened for each new editor, but IMO that is
> unnecessary. If anyone feels there is a need for a new Process BIP, we can
> go
> that route, but there is prior precedent for BIP editors appointing new
> BIP
> editors, so I think this should be fine.
>
> Please speak up soon if you disagree.
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposed BIP editor: Kalle Alm

[Luke Dashjr via bitcoin-dev]

Unless there are objections, I intend to add Kalle Alm as a BIP editor to 
assist in merging PRs into the bips git repo.

Since there is no explicit process to adding BIP editors, IMO it should be 
fine to use BIP 2's Process BIP progression:

> A process BIP may change status from Draft to Active when it achieves
> rough consensus on the mailing list. Such a proposal is said to have
> rough consensus if it has been open to discussion on the development
> mailing list for at least one month, and no person maintains any
> unaddressed substantiated objections to it.

A Process BIP could be opened for each new editor, but IMO that is 
unnecessary. If anyone feels there is a need for a new Process BIP, we can go 
that route, but there is prior precedent for BIP editors appointing new BIP 
editors, so I think this should be fine.

Please speak up soon if you disagree.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] And Then What? Defining a Complete Process for Upgrades

[Jeremy via bitcoin-dev]

This letter is particularly aimed at addressing Rusty Russell's quest for a
development process that respects all groups in a balance of powers.
However, in the spirit of open discussion, I'm sending it directly to the
list.

This proposal is aimed to be compatible with Taproot's ST, and I hope will
help us form some rough consensus around what we try next. Some of the
concepts here are synthesized from what I've seen discussed, but I haven't
included citations of anyone's specific ideas as I'm not sure of the exact
provenance -- I won't claim to have invented this per se, I'm trying to
capture the zeitgeist of what anyone might think to be the process if
pressed to draw it out. Lemme know how I did.

The specific parameters are up for debate, but I'm trying to make sure I've
captured the relevant state transitions.

In this diagram time flows left-to-right, and transitions happen at the
beginning, end, or middle of a block of time. It should be relatively clear
when things happen, but if not, please ask to clarify.

[image: Activation.png]

Clarifications:
- ST: Speedy trial, whereby > T% signals on a block activate the rule
- neg-ST: Speedy Trial, whereby >X% signals on a block Reject the rule
- neg-ST and ST at the same time on different bits: 11 or 00 are "abstain"
votes and are discarded. only 10 or 01 are counted. The purpose of
simultaneous bits is to allow both earlier lock in and to permit early
failure, rather than just one or the other.
- PoW Fork: If a new rule is active, but there is insufficient hashrate,
the rule must be abandoned or PoW must be changed to minimize disruption.
In order to minimize disruption, a node will consider an alternative PoW
chain if < 1/4 of the typical hash rate is seen for a day. Alternative PoW
is defined as SHA-256 10,000 layers, and starts at low difficulty. This is
selected to be maximally similar to Bitcoin's existing PoW, but
sufficiently different to obviate extant ASICS. A node will consider the
new PoW to be equal in value to the old PoW, and will select between the
two based on most-work. Work can be either within a single chain. The new
PoW should have a difficulty adjustment every day for the first month, at
which point, it will relax to every 2 weeks. The details of this should be
described in a separate BIP.
- PoW Fork Lockin: PoW fork is only *required* once the new rule is active.
Thus it's not required in the case of mandatory signalling to force the
signalling contemporaneously, but it can be used to commit to forking the
PoW at some time in the future. It may make sense to not activate the new
rule till the new PoW is active. The game theory of this should be studied
carefully, it is my opinion that the safest option is to PoW fork during
signalling as otherwise miners may protest progress at all.
- Changes: Any time the underlying activation proposal is changed, the
process is restarted. E.g., suppose taproot is rejected because Quantum
Scaries, and we hash the key. The process restarts from the beginning.
Restarts can only occur during quieting periods.
- Quieting Period 1: In the first quieting period, if reached, the "Bitcoin
Core Community" can release the next step, or change the BIP. I left out
failing in this period as a change or a redeployment should always be
attempted.
- Quieting Period 2: In the second quieting period, the outcome is either
to reject the change entirely or to agree to force it. The "Bitcoin Core
Community" may also prepare the release at this stage, and sign, but should
re-label the client as "Bitcoin Community's  Forcing Client".  A
release labeled "Bitcoin Core" may also be made without mandatory
signalling and without forced activation can also be made, such a client
should have (depending on if the flag day is to use signalling) either
ability to activate in response to signalling or a hidden
activeathash parameter to allow clients to enable the feature
post-hoc of the activating block.
- Forced Signalling: It's unclear to me the merit of forced signalling
being 90% of 2016 blocks v.s. 90% of 100 blocks. A shorter forced signaling
assuages certain concerns around lost hashrate -- 1 day of disruption is a
lot better than 2 weeks.
- Timeline: As spec'd above, this whole process takes about 2 years worst
case. ST1 0 months; Quieting 1 at 3 months; ST2 at 6 months; Quieting 2 at
9 months, final attempt at 1 year. The Forcing client period should
probably be 1 yr till active. This is *a bit* slower than the "BIP8
LOT=True UASF Client", but I think not so much slower that it's unworkable.

The most contentious part of this I intuit to be the PoW Fork -- please,
let's avoid discussing the mechanic of how to most safely accomplish this.
The main point of including it in this diagram is to emphasize that if you
commit to being on a minority chain with because of a rule activation with,
say, 5% hashrate, you would experience very tangible disruption. In theory,
every fork upgrade (even signalled) entails such a risk, but 

Re: [bitcoin-dev] Decentralized Naming Protocol BIP

[Christopher Gilliard via bitcoin-dev]

Yeah, kinda, but without the alt and integrated into the other systems that
I've proposed and it maps names to onion addresses instead of ips. It's
needed for some of the applications I've been thinking about.

On Thu, Apr 22, 2021 at 1:55 PM  wrote:

> You appear to have reinvented Namecoin ;)
>
> On 2021-04-21 20:28, Christopher Gilliard via bitcoin-dev wrote:
> > I have created an additional BIP that is associated with the recent
> > BIPs that I have sent to the mailing list. This one defines a
> > decentralized naming protocol. The BIP can be found
> > here:https://github.com/cgilliard/bips/blob/naming/bip-.mediawiki
> >
> > Please reply with any feedback, questions, or comments.
> >
> > Regards,
> > Chris
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Decentralized Naming Protocol BIP

[yanmaani--- via bitcoin-dev]

You appear to have reinvented Namecoin ;)

On 2021-04-21 20:28, Christopher Gilliard via bitcoin-dev wrote:

I have created an additional BIP that is associated with the recent
BIPs that I have sent to the mailing list. This one defines a
decentralized naming protocol. The BIP can be found
here:https://github.com/cgilliard/bips/blob/naming/bip-.mediawiki

Please reply with any feedback, questions, or comments.

Regards,
Chris
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev