Re: Funding model question — unpaid exploratory work at intake

[Able One]

Hi all,

Reposting from the subscribed address — apologies for the earlier bounce.

Now that I’m properly subscribed, I wanted to repost the question with a brief, self-contained summary to avoid wasting anyone’s time.

Summary of the situation
I’ve been speaking with a few Bitcoin-adjacent grant administrators about whether paid exploratory work / experiment framing at intake is considered acceptable within open-source funding models.

The consistent response I received was that exploratory framing at intake is unpaid by definition — funding decisions are made only after work is already scoped, framed, or partially completed by the applicant.

That raised a broader design question for me, independent of any single organization:

The question
• Is expecting unpaid exploratory framing at intake a sane and sustainable grants model for open-source ecosystems?
• What incentive failures does this create (e.g., selection bias, wasted contributor time, shallow proposals)?
• Are there alternative structures that fairly price early judgment without turning grants into VC or bounties?

I’m not asking any org to defend itself here, and no one involved needs to reply. I’m genuinely interested in how people with long experience in Bitcoin and open-source view this trade-off.

Any perspective — supportive or critical — is appreciated.

Best,
Nic

[Chris Stewart]

Hi Able One,

I think this is an interesting topic. Over the past few years, I’ve been working intermittently on proposals for 64-bit arithmetic [0] and amount locks [1], which I think fall squarely into this category.

If I were sitting on a grant committee, I would want to see soft-fork proposals designed as modular components that can be reused as part of larger soft forks. When the same functionality is reimplemented across multiple proposals, that’s usually a strong signal that the feature is broadly needed.

The work I cited above was inspired by the OP_TAPLEAFUPDATEVERIFY soft-fork proposal [2]. I deconstructed that larger proposal into smaller, independent pieces. Two of those pieces were:

• Adding 64-bit arithmetic to Script to properly handle satoshi amounts, and

• Introducing an opcode (OP_INOUT_AMOUNT) to push amounts onto the stack.

After doing this, I realized that there are several other proposals in the space that could reuse this same functionality [3][4][5].

Because of this, I think funding work on small, reusable components that can be composed into “larger” soft forks could be both useful and interesting.

Below are objective milestones that a grantee could complete, with funds disbursed at each stage. Some of these milestones I’ve already achieved with the cited proposals; others are still TODO:

Level 1: Implement the proposal in a language of choice (Python, C++, Rust, etc.).
Level 2: Write a BIP describing the soft-fork proposal.
Level 3: Implement the BIP in the latest Bitcoin Core release, including Python and/or C++ test cases.
Level 4: Produce static test vectors for the BIP [6] and integrate them into a second Bitcoin implementation (e.g., btcd, bitcoin-s, bcoin).
Level 5: Validate the proposal by using it inside larger soft-fork proposals. This would involve forking existing soft-fork code, removing the original implementation of the relevant feature, and rebuilding the larger proposal using the new modular component. Examples of this approach can be found in [3][4][5].

To give a concrete example of work that could be done, there is a competing proposal to my 64-bit arithmetic proposal for arbitrary length precision in Script[7]. You could implement[3][4][5] with the arbitrary length precision proposal rather than my 64-bit arithmetic proposal to validate that the features satisfy the requirements of users of the BIP.

Best,
Chris Stewart

[0] - https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397/51

[1] - https://delvingbitcoin.org/t/op-inout-amount/549

[2] - https://gnusha.org/pi/bitcoindev/20210909064...@erisian.com.au/

[3] - https://delvingbitcoin.org/t/op-inout-amount/549/6?u=chris_stewart_5

[4] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5

[5] - https://delvingbitcoin.org/t/op-inout-amount/549/9?u=chris_stewart_5

[6] - https://github.com/bitcoin/bips/pull/2015

[7] - https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/jxl8aX0XAQAJ

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO-13RDhh4CSG3DBFjU0wrOt%2Bh18_oFHNQHEJKL1nPj0VL-2Dw%40mail.gmail.com.