- Redefine bitcoin base unit to smallest unit
- Propose BIP 21Q: Redefine bitcoin base unit to smallest indivisible unit
- Adds comments acknowledging and handling sats and satoshis
- Make use of "base unit" and variations more consistent and intentional
- Make "bitcoin" v "Bitcoin" consistent
- Made "bitcoin" v "Bitcoin" consistent by using Bitcoin for the protocol and idea, and bitcoin for the units, which I believe is conventional style.
As Bitcoin has grown, the introduction of new address formats
describing new forms of payment instructions has become
increasingly fraught with compatibility issues. Not only does there
exist traditional on-chain addresses, but some recipients wish to
receive Lightning (when the sender supports it) or newer formats
such as Silent Payments.
This has led to increasing use of the BIP 21 query parameters to
encode further optional payment instructions.
Looking forward, as new payment instructions get adopted, it makes
much more sense to include them in query parameters rather than
replace the existing address field, ensuring compatibility with
senders and recipients who may or may not be upgraded to support
all the latest payment instructions.
This updates BIP 321 to suggest that future address formats do this.
Further, it updates BIP 321 to allow an empty bitcoin address in
cases where new payment instructions have moved to becoming
mandatory. This isn't a backwards-incompatible change any more than
switching to a new address format is, so doesn't impact existing
BIP 21 implementations in a new way, however provides a nice
conclusion to the query-parameter-based upgrade path - once a form
of payment instructions has broad adoption, senders can simply drop
the existing address field, keeping their existing query parameter
encoding, rather than replace the existing address field. It also
addresses the question of what to do if a wallet no longer wishes
to receive some legacy on-chain address, but has multiple payment
instruction formats that they wish to include - deciding which one
to place in the address field would be a difficult task.
Finally, it defines a new query parameter, the `pop` parameter,
which allows the initiating application to receive callbacks for
proof of payment completion.
This commit implements the subtraction operator (sub) for the GE (Group Element) class in the secp256k1.py file as requested in the TODO comment in reference.py.
The implementation is straightforward, leveraging the existing neg method to define subtraction as addition with the negated element: self + (-a).
After implementing the operator, the code in reference.py was simplified by replacing expressions like:
s * G + (-e * A) with s * G - e * A
This makes the code more readable and directly matches the mathematical notation used in the BIP-0374 specification.
Co-Authored-By: Sebastian Falbesoner <sebastian.falbesoner@gmail.com>
See https://github.com/bitcoin/bips/commits/master/bip-0340 for a list
of contributors. I have obtained permission to do this change from all
contributors in private. Nevertheless, it would be good to get an ACK
from every contributor in order to have publicly available evidence.
- [ ] @sipa
- [ ] @jonasnick
- [ ] @theStack
- [ ] @ysangkok
I haven't contacted @Sajjon and @satsie, whose contributions constitute
of fixing not more than two typos and are thus below the threshold of
originality required for copyright to be applicable.
Reading from top to bottom, the passive voice "they become BIP's author or deputy" left me wondering
how it would concretely work in practice. Link to the transferring ownership section for
clarification.
Shareholder refers to an individual or a legal entity owning a share of a company's share capital.
Since the Bitcoin system is not a company, but different actors across the industry have a stake in
its operation, i think the word "stakeholder" better conveys the intended meaning of the original
author here.
