[bitcoin-dev] Sign up for Taproot BIP review by October 30

[Steve Lee via bitcoin-dev]

Hello everyone,

The schnorr/taproot/tapscript BIPs are ready for review at this point, and
we want to get as much in-depth review from as broad a range of people as
we can before we go further on implementation/deployment. Reviewing the
BIPs is hard in two ways: not many people are familiar with reviewing BIPs
in the first place, and there are a lot of concepts involved in the three
BIPs for people to get their heads around.

This is a proposal  for a
structured review period. The idea is that participants will be given some
guidance/structure for going through the BIPs, and at the end should be
able to either describe issues with the BIP drafts that warrant changes, or
be confident that they’ve examined the proposals thoroughly enough to give
an “ACK” that the drafts should be formalised and move forwards into
implementation/deployment phases.

Benefits of participating:
* Deeply understand schnorr and taproot
* Be a stakeholder in Bitcoin consensus development
* Support/safeguard decentralisation of Bitcoin protocol development
* Have fun!

If you are interested in participating, please sign up here
.

Special thanks to AJ Towns for doing most of the heavy lifting to get this
going!

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

[bitcoin-dev] Taproot activation discussion

[Steve Lee via bitcoin-dev]

Hello all,

A new Freenode IRC channel ##taproot-activation has been created for
discussion about various activation proposals, community outreach, and
general next steps to gain adoption. Feel free to engage, lurk, or ignore.

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

Re: [bitcoin-dev] activation mechanism considerations

[Steve Lee via bitcoin-dev]

+1 for calm and patience as we navigate the activation mechanism.

On Thu, Mar 4, 2021 at 3:24 AM Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Consensus is important for both taproot and separately for the activation
>> mechanism.  There are more soft-forks that Bitcoin will need, so it is
>> important to achieve positive progress on the activation topic also, not
>> get impatient and rush something ill-considered.  Not all future soft-forks
>> maybe as widely supported as taproot, and yet it could become existentially
>> critical that Bitcoin prevails in achieving a future upgrade in dramatic
>> circumstances, even against powerful interests counter to Bitcoin user and
>> investors interests.  We should treat the activation topic in a considered
>> way and with decorum, provide tight non-emotive reasoning devoid of
>> frustration and impatience.  This is a low drama and convenient time to
>> incrementally improve activation.  People have varied views about the
>> deciding factor, or even which factors resulted in segwit activating after
>> BIP 141 failed using BIP 9.  We do not have to solve everything in one
>> step, incremental improvement is good, for complex unintuitive topics, to
>> learn as we go - and it should not be hard to do less badly than what
>> transpired leading up to BIP 148 and BIP 91.  Failure to upgrade if
>> permanent, or demoralizing to protocol researchers could be a systemic risk
>> in itself as there are more upgrades Bitcoin will need.  We are not Ents
>> but we should use our collective ingenuity to find an incremental
>> improvement for activation.
>>
>
> Great high level thoughts
>
> The Ents themselves were created in Tolkien's fork of Shakespeare, when he
> was frustrated to learn that trees didnt actually march :)
>
> Having followed standards for 10+ years consensus can be tricky
>
> IIRC last time with segwit there was a straw poll in the wiki where devs
> could express leanings in an informal, async way.  Something like that
> could be of value.
>
> There's an insightful spec written at the IETF "On Consensus and Humming
> in the IETF", then IMHO is worth reading
>
> https://tools.ietf.org/html/rfc7282
>
> That said, if we could find an incorruptible machine that could gather the
> highest fee tx from the mempool and post it every 10 minutes, bitcoin would
> largely run itself.  So, while understanding the gravity of each change, we
> could perhaps have the mindset that there are a finite number, such that
> when complete bitcoin will move to an endgame where for the user it 'just
> works', much like the internet.  If devs and changes are needed less, that
> could be viewed as a sign of success.  This is a hand wavy way of saying
> that forks could potentially be a diminishing issue over time
>
> Just my 2 satoshis
>
>
>>
>> John R
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

[Steve Lee via bitcoin-dev]

That's a good point. Agree!

On Thu, Jan 13, 2022 at 10:54 AM Alex Schoof  wrote:

> > I also don't see why Alex or anyone should be denied the opportunity to
> comment on future soft forks or anything about bitcoin. Alex should have no
> more or less right to participate and his comments should be judged on
> their merit, just like yours and mine.
>
> I think the concern is something like: "I disagree with a board member of
> the defense fund about [insert contentious issue]. If I disagree with them
> publicly (especially if there are clear economic implications in that
> disagreement), am I putting myself at risk in the future where I won't be
> able to get support from the fund because I spoke out against a board
> member?" That kind of concern can be mitigated through policy and
> governance, but is the kind of thing you want to tackle before it becomes
> an issue.
>
> Cheers,
>
> (a different) Alex
>
> On Thu, Jan 13, 2022 at 1:49 PM Steve Lee via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I think the word "The" is important. The title of the email and the name
>> of the fund is Bitcoin Legal Defense Fund. It is "a" legal defense fund;
>> not THE Bitcoin Legal Defense Fund. There is room for other funds and
>> strategies and anyone is welcome to create alternatives.
>>
>> I also don't see why Alex or anyone should be denied the opportunity to
>> comment on future soft forks or anything about bitcoin. Alex should have no
>> more or less right to participate and his comments should be judged on
>> their merit, just like yours and mine.
>>
>> On Thu, Jan 13, 2022 at 9:37 AM Prayank via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Jack,
>>>
>>>
>>> > The main purpose of this Fund is to defend developers from lawsuits
>>> regarding their activities in the Bitcoin ecosystem, including finding and
>>> retaining defense counsel, developing litigation strategy, and paying legal
>>> bills. This is a free and voluntary option for developers to take advantage
>>> of if they so wish. The Fund will start with a corps of volunteer and
>>> part-time lawyers. The board of the Fund will be responsible for
>>> determining which lawsuits and defendants it will help defend.
>>>
>>> Thanks for helping the developers in legal issues. Appreciate your
>>> efforts and I understand your intentions are to help Bitcoin in every
>>> possible way.
>>>
>>>
>>> Positives that I see in this initiative:
>>>
>>> 1.Developers don't need to worry about rich scammers and can focus on
>>> development.
>>>
>>> 2.Financial help for developers as legal issues can end up in wasting
>>> lot of time and money.
>>>
>>> 3.People who have misused courts to affect bitcoin developers will get
>>> better response that they deserve.
>>>
>>>
>>> I had few suggestions and feel free to ignore them if they do not make
>>> sense:
>>>
>>> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense
>>> Fund' can be confusing or misleading for newbies. There is nothing official
>>> in Bitcoin however people believe things written in news articles and some
>>> of them might consider it as an official bitcoin legal fund.
>>>
>>> 2.It would be better if people involved in such important funds do not
>>> comment/influence soft fork related discussions. Example: Alex Morcos had
>>> some opinions about activation mechanism during Taproot soft fork IIRC.
>>>
>>>
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F
>>> ___
>>> 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
>>
>
>
> --
>
>
> Alex Schoof
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Spiral is Hiring Bitcoin Wizards

[Steve Lee via bitcoin-dev]

Note: I checked with the moderators prior to posting this as normally job
postings to this list would be frowned upon. I felt like it was appropriate
in this case since (a) Spiral is 100% non-commercial FOSS bitcoin (b) many
on this list would either be interested in this opportunity or know people
who would be.


Spiral is hiring bitcoin “wizards,” though we will settle for bitcoin
mages, sorcerers and sorceresses, witches, warlocks, and druids.

About Spiral
Spiral is the first free and open-source, internal, non-profit bitcoin
organization within a major tech company. We contribute to bitcoin by
writing code, funding projects and individuals, educating, entertaining,
and testing the limits of what a tiny team can do to impact the future of
money. Although many see bitcoin only as digital gold, via the Lightning
Network, Spiral envisions bitcoin fulfilling its promise and potential as
the global standard for peer-to-peer payments.

To date, Spiral’s full-time engineering team has focused exclusively on
developing LDK, a kit that simplifies how developers add the Lightning
Network to apps and wallets. This year, we plan to build an R team within
Spiral that will focus on improving bitcoin’s security, decentralization,
privacy, scaling, and expressivity beyond LDK. The projects might include
applying novel cryptography, developing existing protocol proposals, and
creating new innovative protocol proposals. The possibilities aren’t
endless, per se, but they are numerous.

Job Responsibilities
* Identify and drive forward multiple projects in collaboration with the
Spiral team and the greater bitcoin development community.
* Develop a project plan for each active project.
* For a given project, do whatever it takes to make progress toward the
goal, including:
   * Building prototypes
   * Writing tests
   * Developing production code
   * Developing performance benchmarks
   * Creating simulations
   * Being thoughtful about how to gain consensus on changes
   * Recruiting other FOSS devs to help
   * Writing bitcoin-dev email posts
   * Participating in podcasts and speaking at conferences
* Regularly review bitcoin-dev and lightning-dev email lists, relevant
“wizards” channels, Bitcoin Optech, relevant research papers, and R from
other cryptocurrency projects. When possible, engage and provide
constructive feedback.
* Propose new protocol designs building on what others have done or wholly
new ideas.

Qualifications
Applicants should have a deep technical understanding of bitcoin and be
comfortable engaging on bitcoin topics and on bitcoin channels such as
bitcoin-dev or lightning-dev email lists, local bitdevs, or in a “wizards”
channel such as IRC #bitcoin-wizards.

Applicants should also know which projects they’d like to work on. At a
minimum, they should be able to identify three projects worth your time,
why they benefit bitcoin, and how your involvement would improve them.

Finally, strong people skills are a must. Many projects will require
attaining developer consensus, including the bitcoin consensus protocol,
bitcoin p2p policy, and the LN protocol. To successfully navigate this
requires more than just coding talent. Applicants should be ego-free,
willing to detach themselves from a particular proposal, and be prepared to
conclude a proposal if something learned has made it untenable. Applicants
should also seek collaborators and co-authors, be patient yet persistent,
and incorporate peer feedback. We undeniably expect a lot from whoever
fills these roles. But there’s no other job like them in bitcoin or
elsewhere.

Example Projects
Here is a list of project examples Spiral would find valuable. Again, we
expect candidates to drive the process of which projects they will work on,
so this list is merely a tool to help a candidate calibrate the scope and
depth of future projects.

Scaling innovation
* New methods to share UTXOs among users as trustless and efficiently as
possible
* Lightning efficiency innovation
* Cross-input signature aggregation

Security innovation
* BIP324
* Mining pool decentralization
* Threshold signatures for LN
* Mempool/bitcoin p2p security for L2
* Evaluate security risks to bitcoin stemming from MEV, tokens,
stablecoins, etc and provide recommendations

Privacy innovation
* Applied ZKP for LN gossip to hide UTXO funding

Bitcoin expressivity innovation
* Bitcoin script opcode innovation, tradeoff evaluation, and driving (CTV,
CSFS, TLUV, OP_VAULT, etc.)

The Position
This full-time role includes full-time worker benefits. Spiral supports you
working anywhere, but you need a home base in a country whose talent pool
Block can legally hire from. If you’re not sure whether we can hire from
where you live, just reach out and ask. We’ll check.

How to Apply
Sound good? Not too confused? Great. You’ve cleared the first hurdle. Shoot
us an email with the top 3 project ideas you want to work on along with
supporting evidence that you’ll successfully complete them: 

Re: [bitcoin-dev] BIP for OP_VAULT

[Steve Lee via bitcoin-dev]

"want bitcoin to be money and money means different things for people in
this world"

I think we can all agree that a property of money is fungibility, and by
its very definition NFTs are not fungible and thus not money.

On Wed, Mar 29, 2023 at 4:56 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Zac,
>
> Let me share what those parasites achieved:
>
> - Fees paid: 150 BTC
> - Lot of users and developers trying bitcoin that either never tried or
> gave up early in 2013-15
> - Mempools of nodes of being busy on weekends and got lots of transactions
> - PSBT became cool and application devs are trying their best to use it in
> different ways
> - Some developers exploring taproot and multisig
> - AJ shared things how covenants could help in fair, non-custodial,
> on-chain auction of ordinals that is MEV resistant although I had shared it
> earlier which involves more steps:
> https://twitter.com/144bytes/status/1634368411760476161
> - Investors exploring about funding projects
> - Bitcoin more than Bitcoin and people excited about it
>
> We can have difference of opinion, however I want bitcoin to be money and
> money means different things for people in this world. Please respect that
> else it will become like Linux, something used by 1% of world.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > I’m not sure why any effort should be spent on theorizing how new
> opcodes might be used to facilitate parasitical use cases of the blockchain.
> >
> > If anything, business models relying on the ability to abuse the
> blockchain as a data store must be made less feasible, not more.
> >
> > Zac
> >
> >
> > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via
> bitcoin-dev wrote:
> > > > I think there are perhaps four opcodes that are interesting in this
> class:
> > > >
> > > > idx sPK OP_FORWARD_TARGET
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output have a particular scriptPubKey (given
> > > > by sPK).
> > > >
> > > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have almost the same scriptPubKey as this
> > > > input, _except_ that the current leaf is replaced by "script",
> > > > with that script prefixed by "n" pushes (of values given by [...])
> > > >
> > > > idx OP_FORWARD_SELF
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have the same scriptPubKey as this input
> > > >
> > > > amt OP_FORWARD_PARTIAL
> > > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > > rather than the entire balance. opcodes after that affect the
> > > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > > 0, the next OP_FORWARD_* becomes a no-op.
> > >
> > > The BIP 345 draft has been updated [0] [1] and now pretty much defines
> > > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE
> above,
> > > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > > that, for this email I'm going to continue using the OP_FORWARD_*
> > > naming convention.
> > >
> > > Given the recent controversy over the Yuga labs ordinal auction [2],
> > > perhaps it's interesting to consider that these proposed opcodes come
> > > close to making it possible to do a fair, non-custodial, on-chain
> auction
> > > of ordinals [3].
> > >
> > > The idea here is that you create a utxo on chain that contains the
> ordinal
> > > in question, which commits to the address of the current leading
> bidder,
> > > and can be spent in two ways:
> > >
> > > 1) it can be updated to a new bidder, if the bid is raised by at least
> > > K satoshis, in which case the previous bidder is refunded their
> > > bid; or,
> > >
> > > 2) if there have been no new bids for a day, the current high bidder
> > > wins, and the ordinal is moved to their address, while the funds
> > > from their winning bid are sent to the original vendor's address.
> > >
> > > I believe this can be implemented in script as follows,
> > > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced
> above),
> > > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> > > are all available.
> > >
> > > First, figure out the parameters:
> > >
> > > * Set VENDOR to the scriptPubKey corresponding to the vendor's address.
> > > * Set K to the minimum bid increment [5].
> > > * Initially, set X equal to VENDOR.
> > > * Initially, set V to just below the reserve price (V+K is the
> > > minimum initial bid).
> > >

Re: [bitcoin-dev] Bitcoin ungibility and inscribed sats

[Steve Lee via bitcoin-dev]

"want bitcoin to be money and money means different things for people in
this world"

I interpreted your above statement to mean that to some people,
inscriptions/NFTs are money. That is what I was responding to.



On Fri, Mar 31, 2023 at 9:26 AM alicexbt  wrote:

> Hi Steve and Bitcoin Developers,
>
> I have created a new thread as requested by one of the developers. I
> respect him and the readers of this list.
>
> > "want bitcoin to be money and money means different things for people in
> this world"
>
> > I think we can all agree that a property of money is fungibility, and by
> its very definition NFTs are not fungible and thus not money.
>
> Inscriptions do not affect fungibility of bitcoin:
>
> - There is no token standard being used. These are just sats being
> considered as inscription in an external protocol or explorer. Bitcoin
> nodes do not consider them as something special.
> - Users can always sell those inscribed sats or UTXO as normal bitcoin on
> bisq or any exchange.
> - They can use different amounts for it using tools like
> https://raritygarden.inscribetheplanet.com/ which is created by super
> testnet who is active dev in bitcoin and ln.
> - Inscribed sats are different from Ethereum tokens because they will
> never go to zero and you can always consolidate lot of them to use as
> normal bitcoin.
>
> Bitcoin fungibility is anyways debatable and I cannot change anything
> about it even though working on a coinjoin implmentation as some post mix
> UTXOs are censored on some exchanges and its easy to identify them. Some
> coinjoin implementation themselves work with chain analysis companies to
> censor inputs used for rounds.
>
> Ordinals theory is a parallel universe in which some users believe in and
> they have been trying to learn how bitcoin works. Example: I did call with
> someone this evening to explain how PSBT and multisig works who never used
> bitcoin before
>
> Developers are interested to build things and they have tried to create
> BIP, DEX, look for libraries, ask questions, projects implementing PSBT etc.
>
> I do not live in first world country and do not attend bitdevs but always
> wanted bitcoin to be here. I have tried my best but failed. Please let
> people do what they want with bitcoin without changing consensus rules. It
> will help Bitcoin.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

Isn't this as simple as anyone (in particular Core project contributors)
can express their view in this PR?
https://github.com/bitcoin/bitcoin/pull/27604

On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>> > Essentially my concern is going forward current maintainers will
>> > decide which proposed new maintainers to add and which to block.
>>
>> This is how a large percentage of organizations are run.  The current
>> members of a board or other governance group choose who will become a
>> new board member.
>>
>
> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
> independent contributors merging different pull requests or patches. The
> github controls are merely because that is how github works. There is also
> a secondary issue of people tending to confuse Bitcoin Core with the
> bitcoin protocol in general:
> https://blog.lopp.net/who-controls-bitcoin-core/
> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>
> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>
> - Bryan
> https://twitter.com/kanzure
> ___
> 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] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
agrees or disagrees, the same process is being used. Anyone can NACK and
give a reason for Russ as well.

On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
michaelfolk...@protonmail.com> wrote:

> Hi Steve
>
> > Isn't this as simple as anyone (in particular Core project
> contributors) can express their view in this PR?
> https://github.com/bitcoin/bitcoin/pull/27604
>
> Nope. The extent to which the rationale for blocking Vasil as a maintainer
> applies or doesn't apply to ryanofsky (or future potential maintainers)
> isn't discussed. From now on the precedent is proposed maintainers can be
> blocked for unknown and/or potentially inconsistent reasons by the existing
> maintainers.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message ---
> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Isn't this as simple as anyone (in particular Core project contributors)
> can express their view in this PR?
> https://github.com/bitcoin/bitcoin/pull/27604
>
> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>> > Essentially my concern is going forward current maintainers will
>>> > decide which proposed new maintainers to add and which to block.
>>>
>>> This is how a large percentage of organizations are run. The current
>>> members of a board or other governance group choose who will become a
>>> new board member.
>>>
>>
>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
>> independent contributors merging different pull requests or patches. The
>> github controls are merely because that is how github works. There is also
>> a secondary issue of people tending to confuse Bitcoin Core with the
>> bitcoin protocol in general:
>> https://blog.lopp.net/who-controls-bitcoin-core/
>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>
>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>
>> - Bryan
>> https://twitter.com/kanzure
>> ___
>> 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] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

I see it was merged since my original post. I agree that is a very short
window of time. In particular, if a long-time Core contributor wasn't able
to attend the in-person meeting or last week's IRC meeting, they'd have had
to really been on the ball.

On Wed, May 10, 2023 at 10:22 AM Michael Folkson <
michaelfolk...@protonmail.com> wrote:

> > Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and
> give a reason for Russ as well.
>
> With respect Steve the process for Vasil was keeping Vasil's PR open for
> up to 5 months with zero NACKs and two maintainers refusing to engage on
> why it wasn't being merged or what it needed for it to be merged. Followed
> by a later justification for blocking it that they've refused to discuss
> whether it applies to Russ.
>
> The process for Russ was the maintainers deciding privately there was a
> need for a maintainer "who understood our interfaces and modularization
> efforts well" and his PR was merged within 2 days.
>
> If that's the same process to you I don't know what to say. We have
> different perspectives on what constitutes a decision process.
>
> (I'm sure this is clear but just to reiterate in case it isn't none of
> this is a criticism of Russ.)
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Wednesday, May 10th, 2023 at 17:36, Steve Lee 
> wrote:
>
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and
> give a reason for Russ as well.
>
> On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
> michaelfolk...@protonmail.com> wrote:
>
>> Hi Steve
>>
>> > Isn't this as simple as anyone (in particular Core project
>> contributors) can express their view in this PR?
>> https://github.com/bitcoin/bitcoin/pull/27604
>>
>> Nope. The extent to which the rationale for blocking Vasil as a
>> maintainer applies or doesn't apply to ryanofsky (or future potential
>> maintainers) isn't discussed. From now on the precedent is proposed
>> maintainers can be blocked for unknown and/or potentially inconsistent
>> reasons by the existing maintainers.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> --- Original Message ---
>> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Isn't this as simple as anyone (in particular Core project contributors)
>> can express their view in this PR?
>> https://github.com/bitcoin/bitcoin/pull/27604
>>
>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>> > Essentially my concern is going forward current maintainers will
>>>> > decide which proposed new maintainers to add and which to block.
>>>>
>>>> This is how a large percentage of organizations are run. The current
>>>> members of a board or other governance group choose who will become a
>>>> new board member.
>>>>
>>>
>>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
>>> independent contributors merging different pull requests or patches. The
>>> github controls are merely because that is how github works. There is also
>>> a secondary issue of people tending to confuse Bitcoin Core with the
>>> bitcoin protocol in general:
>>> https://blog.lopp.net/who-controls-bitcoin-core/
>>>
>>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>>
>>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>>
>>> - Bryan
>>> https://twitter.com/kanzure
>>> ___
>>> 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] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

I don't see any reason to be antagonistic in your responses.

One piece of advice I'd offer to you and Michael is to consider whether
your responses are effective. To persuade other people it takes more than
making good points or being right, but you need to find a communication
style and communication path that is effective. My observation is that your
styles need reflection.


On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Andrew,
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past.
>
>
> Can we learn something from past?
>
> Bitcoin's initial release was in 2009 with one developer and few others
> experimenting with it. It is considered decentralized in 2023 however we
> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
> or not and this includes some trying to implement their ideas without soft
> fork using mempool policies.
>
> We need better process to add maintainers. I am disappointed with the way
> last last pull request was merged. It says more about maintainers and
> leader Michael Ford. If you are so scared about opinions on a pull request
> why not just make him maintainer without pull request?
>
> Maybe you will understand this if your PR to add maintainer was kept open
> for 4 months.
>
> /dev/fd0
> floppy disk
>
>
> Sent with Proton Mail  secure email.
>
> --- Original Message ---
> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>
> The decision process for adding a new maintainer was according to the IRC
> meeting that the maintainers decided privately there was a need for a
> maintainer “who understood our interfaces and modularization efforts well”
> and that ryanofsky was a “good fit for that”. I don’t know whether this was
> decided in a private IRC channel or was decided at the recent in person
> Core Dev meeting. Regardless, many have had no input into the discussion on
> what kind of maintainer the project needs going forward and it seems the
> maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a
> maintainer has always been made by existing maintainers. When the
> maintainers feel that there is a need for additional maintainers, they may
> have an open call for volunteers, or may have a candidate already in mind
> and suggest that specific person for maintainership. Contributors generally
> are not consulted in the decision to seek a new maintainer as they would
> not know whether there are things that are being overlooked or that there
> is maintainership load that needs to be distributed. Even so, it wouldn't
> be appropriate to add a maintainer if many contributors disagreed with it,
> just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past. I think our modern concept of maintainers with
> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
> Marco Falke were simply announced by Wladimir. There was no public
> discussion, and some IRC logs refer to private emails between the them and
> the current maintainers at that time. After that, meshcollider was added as
> a maintainer after a public "call for maintainers" where a recurring topic
> for a while was finding a maintainer for the wallet. He had volunteered to
> do it by contacting Wladimir privately before it was discussed during an
> IRC meeting and then on Github. Fanquake was added as a maintainer during a
> CoreDev event in Amsterdam during a discussion initiated and led by the
> maintainers. This was also "private" insofar as the discussion was limited
> to those in attendance, although there was some opportunity for public
> discussion in the PR opened on Github. For myself, it was also initially
> private as I messaged Wladimir to volunteer for it after meshcollider
> stepped down. There was some discussion on IRC and on Github, but it was
> also obvious that many already expected me to be the wallet maintainer
> after meshcollider. Hebasto was added with basically no fanfare or
> discussion - the only mention I can find is the PR itself. My understanding
> is that the maintainers asked him he wanted to do it before the PR was
> opened. Glozow was nominated to be a maintainer by some of the current
> maintainers, and her nomination was really the first time that there was
> significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from
> the current maintainers, one was volunteering following an actual "call for
> maintainer", and one was an obvious successor. It's obvious and common
> sense that the maintainers decide when they need help shouldering the load,
> and then find somebody