Implementaton of BIP 179 #17429

Hello, as BIP 179 is now a Draft, I think it is time to implement it in Bitcoin Core. For people who don't know what this BIP does, in short it re defines the term "address" to "(Bitcoin) Invoice (Address)", where "Bitcoin and "Address" are optional. The reason for this is to avoid that addresses are treated as something permanent.

My current implementation plan would be to change the strings in bitcoin-qt and add them as other terms for the RPC commands (so the older ones still work). I don't plan to modify class names and file names by this because it would be probably a too big change.

I want to mostly rely on "Invoice Address" to not make it to complicated for users (in bitcoin-qt)

Feedback appreciated, anything I forgot?

I'd prefer to wait until this is adapted by the wider ecosystem. Bitcoin Core has never been leading in these kind of prescriptive language changes (same for the units discussion, like what unit people should be using), and IMO, shouldn't. If it gains traction we'll want to update the GUI.

Changing RPC command names for this seems unnecessary disruption. We already had the account→label change recently. Let's not do one immediate again… these kind of changes are disruptive for projects such as joinmarket which rely on our API.

ACK to change it in the GUI and maybe RPC help docs, but internal (c++ class names) or RPC arguments/return fields seems too disruptive

@laanwj @MarcoFalke I mean something like this:

{ "blockchain",         "getblock",               &getblock,               {"blockhash","verbosity|verbose"} },

So in our case it would be for example:

{ "wallet",             "sendtoaddress",                    &sendtoaddress,                 {"address|invoice","amount","comment","comment_to","subtractfeefromamount","replaceable","conf_target","estimate_mode","avoid_reuse"} },

This would keey backwards comp. and allows the new term. I don't want to implement new RPC commands as well.

When discussing implementing BIP179 in another project, someone pointed out that there's really no way to transition from "(Bitcoin) invoice address" to just "(Bitcoin) invoice", since a base58check or bech32 string is not a proper invoice (e.g., it doesn't contain an amount, the vendor name, or other data normally (or legally required to be) associated with invoices).

Without the transition, we get stuck with the unweildly phrase "invoice address".

@emilengler I just don't think that's worth it. not even to introduce aliases for. If you want to change end-user terminology, focus on end-user terminology and promotion of that. Make people use it on vendor sites and such, and in businesses, not internal APIs. That only reaches developers, which are probably the least likely to care about things like this.

I personally think this is a lost battle. The term "address" is so well established today that I don't expect people to be willing to change it. Even using it in the GUI will just cause confusion.

I mean that just as a caution against rushing this. Conceptually I very much would like to be wrong.

@sipa That's why the suffix 'address' is permitted to avoid confusion until a 'invoice' is established.

I'd prefer to wait until this is adapted by the wider ecosystem. I mean that just as a caution against rushing this.

ACK. It seems premature to start any sort of refactoring in Bitcoin Core for BIP 179. It seems like it'll just disrupt other work / potentially break APIs while introducing new (also ambiguous given you can pick if you want to use Bitcoin or Address) terms into the code base that haven't seen any actual usage. Given that the BIP is < 1 month old, has there been any indication that these new terms are going to be adopted by other projects/companies?

Concept NACK. Widely used terminology is extremely sticky and arguably Lindy. The term "address" has been in wide usage for well over five years which could mean it'll take five years or more of concerted effort to ensure people move away from using it. I am not convinced that the proponents of this BIP are willing to put in that concerted effort to ensure all educational resources and all businesses in the ecosystem change their terminology. I am also not convinced doing so is a good use of the proponents' time. IP "addresses" can be both static and dynamic. I don't see why Bitcoin addresses can't also be both static and dynamic. There are use cases where static Bitcoin addresses (at least in the short term) are more convenient than dynamic Bitcoin addresses e.g. posting a donation address that you have signed with your PGP key.

@harding I have also sensed the same conceptual discrepancy between the term "invoice" and "payment identifier". Perhaps this is not the best place to discuss it - please redirect me to a more appropriate place - but would "invoice id" be a better fit for the "end state" of BIP179? Ie. replacing "address" by "id" in the final transition.

The mailing list is a better place to discuss this I think