From: Chris Stewart <stewart.chris1234@gmail.com>
To: Able One <able1plus@gmail.com>
Cc: bitcoindev@googlegroups.com, nic.anthony@pm.me,
"abubakar@btrust.tech" <abubakar@btrust.tech>,
"mike@brink.dev" <mike@brink.dev>
Subject: Re: [bitcoindev] Re: Funding model question — unpaid exploratory work at intake
Date: Sat, 3 Jan 2026 07:32:29 -0600 [thread overview]
Message-ID: <CAGL6+mFqwC8ySFs3A0xQSzyhqYa+5EH1_q5cBmvGCeu57KHqEg@mail.gmail.com> (raw)
In-Reply-To: <CAO-13RDhh4CSG3DBFjU0wrOt+h18_oFHNQHEJKL1nPj0VL-2Dw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5626 bytes --]
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/20210909064138.GA22496@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
On Thu, Jan 1, 2026 at 8:34 AM Able One <able1plus@gmail.com> wrote:
> 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
>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAO-13RDhh4CSG3DBFjU0wrOt%2Bh18_oFHNQHEJKL1nPj0VL-2Dw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAO-13RDhh4CSG3DBFjU0wrOt%2Bh18_oFHNQHEJKL1nPj0VL-2Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmFqwC8ySFs3A0xQSzyhqYa%2B5EH1_q5cBmvGCeu57KHqEg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10526 bytes --]
prev parent reply other threads:[~2026-01-03 13:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 5:40 Able One
2026-01-03 13:32 ` Chris Stewart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGL6+mFqwC8ySFs3A0xQSzyhqYa+5EH1_q5cBmvGCeu57KHqEg@mail.gmail.com \
--to=stewart.chris1234@gmail.com \
--cc=able1plus@gmail.com \
--cc=abubakar@btrust.tech \
--cc=bitcoindev@googlegroups.com \
--cc=mike@brink.dev \
--cc=nic.anthony@pm.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox