Proposal talk:Cryptocurrencies with payment tag

Also on areas

Resolved: Changed the node only usage recommendation to nodes and areas.

Just like payment=*, I wouldn't restrict the usage to nodes only but also allow them on areas. There are situations where the payment information needs to be on the area. It also depends on the country if shop information is placed on an adres node or the building outline.

For the rest, I like the proposal. I agree that crypto is a payment it self and that via namespacing you can define the crypto that can be used --Cartographer10 (talk) 15:46, 28 August 2021 (UTC)

I think you're right, I'll edit the proposal to recommend using it with nodes and ways (areas) and only discourage relations. --Andrasfuchs (talk) 18:46, 28 August 2021 (UTC)

Why this proposal is needed?

Resolved: Changed the main key to use from payment to currency. We are going to use commonly accepted and used codes for identifying coins and tokens, not their full names or their ISO codes.

Why not simply use existing method documented at https://wiki.openstreetmap.org/wiki/Key:payment#Cryptocurrencies and matching other payment methods? Mateusz Konieczny (talk) 18:45, 28 August 2021 (UTC)

It wants to deprecate some sub-keys to unify them under this sub-key.

I disagree with payment:*=*. payment:*=* should used for wallets, or the method (POS terminal and ATM not limited to QR code; can use card or phone NFC, and Bluetooth). currency:*=* should be favored, as suggested in Key:payment#Cryptocurrencies. Although, there are no obvious syntax to format them together now, which poses a problem for including the Lightning Network protocol here.

*:cryptocurrency:BTC=* is fine, because XBT isn't an official ISO 4217 standard yet. But this hasn't explained using the informal codes vs full name (perhaps useful for less popular ones).

---- Kovposch (talk) 20:22, 28 August 2021 (UTC)

At most LN can be represented in payment:*=* somehow. Needs some more in-depth consideration and organization. ---- Kovposch (talk) 20:38, 28 August 2021 (UTC)

Yes, its main goal is to unify the cryptocurrency related keys in a way that is more future-proof and reflect the currently available options.

Merchants can't limit what wallet the customer needs to use, they can only limit the protocol options. They can set up their system to accept multiple cryptos or only one, using Lightning Network or not. Both the merchants backends, POS systems and customer wallets are continuously in development and change, so tagging QR/NFC capabilities might not be that relevant, because they will probably change over time. QR codes are different for different cryptos as well, so a merchant might support QR codes for BTC, but not for LTC. So I'm not saying it's a bad idea, it would be a nice-to-have, but layer-1 and layer-2 protocol support is the most important for both the merchant and the customer, because they can transact only if they have a protocol match.

As you said cryptocurrencies are not ISO standards yet, and they are unlikely to become one soon. Also, if we waited for ISO standardization for every crypto before starting using it on OpenStreetMap we would miss a lot of opportunities with early adapters. The current definition of the currency:*=* needs an ISO 4217 if I understand it correctly, so we should not use cryptos there in my opinion.

I would prefer codes to full names because they can be used at other services or APIs. Working with another service like an exchange rate provider would be much easier with codes. Full names and codes of the mayor cryptos should be listed on the Wiki if the proposal gets approved to help the contributors.

LN is just one of the currently available layer-2 protocols, but it's important to indicate if the merchant accepts it, because it means instant payment confirmation and tiny fees to the customer. Just for clarification: LN builds on the top of the cryptocurrency, so BTC+LN, LTC+LN are valid combinations, but LN on itself is not a valid protocol definition. ---- Andrasfuchs (talk) 22:36, 28 August 2021 (UTC)

1. Since the medium or even payment is still evolving, I would like to focus on it as a currency:[[Key:|]]=* first.
2. There's a problem in Key:currency with confusion between official and "compliant" codes, resulting in XBT is being promoted, and an "XLT" is separately invented for local currency (without knowing a potential clash with Litecoin). If the standard is a 3-character code, using something else can already indicate another meaning, viz currency:others=no. This syntax issue shouldn't prevent crypto from being expressed as a currency, which will enable making this data more uniform.
3. By "protocol", I mean payment protocol. But can you explain things like BIP21 to us as well? I don't know much about crypto either, not to mention all possible users that's going to be voters of this more technical proposal to deprecate. Eg I read BOLT-11 is used in LN, should this be used instead? The reason behind my perspective is this situation reminds me of EMV ODA transactions, and Apple Pay's Express Transit mode. If possible, a more compatible general format should be formulated.

---- Kovposch (talk) 22:17, 28 August 2021 (UTC)

1. I see what you mean, and I understand your perspective better now. So, if the currency key would be a better fit, do you think it would be an acceptable solution to have a "crypto" subkey there? For example, instead of payment:cryptocurrencies:BTC=yes we would use currency:crypto:BTC=yes or currency:crypto:LTC=yes? ((A similar solution could solve the local currency problem you mentioned above too.))
2. I get your point, so it wouldn't make too much sense to complicate the definitions with technical details, right? I could explain BIP21 or BOLT-11, but it would not be practical to include them in the proposal or in the keys. I see two options then: a, ignore the Lightning Network and other layer-2 technologies, having information about cryptocurrency acceptance in a store is enough for now b, let people define the LN support in a predefined way, like BTC+LN, so the tag would look like currency:crypto:BTC+LN=yes or currency:crypto:LTC+LN=no. I can imagine that in the future LN would be the de-facto standard and this extra indication with +LN wouldn't be needed, but at the moment it is useful for the customer.
3. I still think that codes are better than full names, and we should use the codes that the current crypto community uses (and not the ISO codes, those are very rarely seen in the crypto world). The coinmarketcap.com website is a fairly good source for matching coins with their commonly used codes.
4. If the proposal gets accepted, what will happen with the existing payment.bitcoin tags? Is someone allowed to do a batch modification on those nodes to change payment.bitcoin=yes to currency:crypto:BTC=yes for example?

---- Andrasfuchs (talk) 08:54, 29 August 2021 (UTC)

1. Yes, this is good.
2. currency:crypto:*+LN=* is interesting to use plus symbol for special purposes. Unfortunately usually colon currency:crypto:*:LN=* is used. You can ask for feedback on this.
3. Ok same as 1.
4. I'm not familiar with this. You must follow Automated Edits code of conduct, or alternatively create MapRoulette tasks for manual review.

---- Kovposch (talk) 10:22, 29 August 2021 (UTC)

Thank you for your valuable feedback, I'll modify the proposal accordingly.

---- Andrasfuchs (talk) 14:47, 29 August 2021 (UTC)

Syntax for layer-2 support

Resolved: We are going to use option 1 for layer-2 support.

The proposal would make it possible to indicate both layer-1 (BTC, LTC, DASH, ETH, etc.) and layer-2 (Lightning Network or LN, etc.) protocol support. For the layer-1 only case the indication of the cryptocurrency acceptance is fairly simple, following the format of currency:crypto:<layer-1 cryptocurrency code>=yes e.g. currency:crypto:BTC=yes.

Since layer-2 support is independent from the cryptocurrency that is used with, it can be seen as an "extension" or a "booster" of the cryptocurrency it is used with. To indicate this, we would need to have a format that describes this relationship, and there are two proposals at the moment:

1. currency:crypto:<layer-1 cryptocurrency code>:<layer-2 protocol code>=yes e.g. currency:crypto:BTC:LN=yes
2. currency:crypto:<layer-1 cryptocurrency code>+<layer-2 protocol code>=yes e.g. currency:crypto:BTC+LN=yes

Which one do you think is better? -- Andrasfuchs (talk) 14:59, 29 August 2021 (UTC)

I would go for option 1 with the :. That is the default in OSM and more clear in my opinion. The + sign seems like a typo because a : is used in OSM. --Cartographer10 (talk) 16:23, 29 August 2021 (UTC)

The reason I'm willing to give this a thought is it's not really a sub-currency, so the colon doesn't have much meaning. In ISO 4217, USN and previously USS are used for next-day and same-day US dollar, as a funds code. In this respect, currency:crypto:*+LN=*, or currency:crypto:*_LN=*, sorta augments the cryptocurrency in how it is paid. ---- 17:29, 29 August 2021 (UTC)

Actually let's use currency:crypto:BTC=LN? In addition to currency:crypto:BTC=yes. Avoids adding too much. ---- 17:29, 29 August 2021 (UTC)

I would go for option 1 too. I gave it more thought and there are a few reasons why I think that is the better way:

1. A merchant can decide to accept Bitcoin (or other crypto) on layer-1 (or "on-chain") and not to use Light Network at all. Of course, he/she can decide to enable Lightning Network too. Transactions on Lightning Network are on layer-2 (or "off-chain"). But, surprisingly he/she can also decide to allow layer-2 transactions, but do not allow layer-1 transactions. So these options must be defined separately even if they are all running on the BTC network. This latter case would be defined with two tags currency:crypto:BTC=no and currency:crypto:BTC:LN=yes.
2. If we suppose that there will be other layer-2 technologies in the future, we must be able to define a case where a merchant accept both LN and another (let's say Thunderstorm Network, or TN). This case would be defined with three tags currency:crypto:BTC=yes, currency:crypto:BTC:LN=yes and currency:crypto:BTC:TN=yes.
3. This is more like a technical argument, but when someone wants to participate on the Lightning Network as an operator, they need to "freeze" some of their BTC, effectively changing their on-chain bitcoins to "LN bitcoins". From this perspective it's something like another currency (based on BTC), and it can only be changed back to on-chain BTC sometime later. They are closely realted, because they have the same unit (and exchange rate), but they are technically different.
4. If we want to support Ethereum (ETH) based tokens as well, the notation with the semicolon makes sense there too, because ETH tokens are kind of currencies that live on the ETH network. For them we could logically use the ETH:<token code> notation, e.g. currency:crypto:ETH:ENJ=yes. (Sorry that I didn't mention this before in the proposal, I'll edit it to include information about these tokens too.) They are nearly never used as a way of payment today, but I think it's important to include them as well if we really want to future-proof this tag definition for many coins and tokens to come.

-- Andrasfuchs (talk) 22:15, 29 August 2021 (UTC)

Very useful arguments, especially 3. ---- Kovposch (talk) 10:45, 30 August 2021 (UTC)

"Cryptocurrencies"

Resolved: We are going to keep payment:cryptocurrencies and currency:crypto notations in the proposal.

I've put some thought into this and wonder if the usage of the term "cryptocurrencies" in any future proof tagging scheme is a good idea. Since the more widely they are adopted the less they are likely to be referred to or seen as "cryptocurrencies" and just regular digital cash instead. Especially once the technology is adopted by governments. They aren't going to be called "cryptocurrency dollars." In the meantime, the term "cryptocurrency" is more of a tech industry buzz word then something people IRL use. No one is going to an ATM to withdraw "Bitcoin cryptocurrency." They are just taking out Bitcoin.

So, I really feel like the addition of "cryptocurrencies" to this is redundant, doesn't serve a purpose outside of sounding "tech smart", and also won't help this to be future proof. Since it's pretty likely the term won't be used that much in the future as cryptocurrencies become more widespread or adopted by the general population. Who is mostly tech literate and doesn't care what backend technology their payment system is using. For instance credit cards use encryption, but no one knows or cares about it. Nor is it reflected in the various tags we use for credit card payments. --Adamant1 (talk) 18:50, 5 September 2021 (UTC)

This is an inspiring perspective, but underlying are some theoretical and practical issues:

Ideally: Mainly, the currency is issued decentralized with cryptography control, not only encrypted in storage and transaction. Cryptocurrency starts with a "Not to be confused with" header, where you can be see a Virtual_currency#The_money_matrix table inside showing many other Digital currency.

Pragmatically: Indeed, eg currency:digital:*=* would already have a potential conflict with currency:XLT=* local currencies (User:FrViPofm/Key:local currency) if treated similarly, as mentioned in Talk:Proposed_features/Cryptocurrencies_with_payment_tag#Why this proposal is needed? above.

---- Kovposch (talk) 20:40, 5 September 2021 (UTC)

Hhhmm, your comment is something to think about. Off the top of my head though, it's wrong that cryptocurrencies are decentralized. Some are but ones like Libre, which would have been controlled by Facebook if it ever got off the ground, aren't. Except maybe philosophically in the way that anyone can trade them, but the same goes for regular fiat currencies. That said, I don't see how if cryptocurrencies are decentralized or not is relevant anyway. Maybe you can enlighten me?

Also, while I get the need to not have conflicts with local currencies realistically there isn't going to ever be local currencies called "Bitcoin" or "Ethereum." So the conflict only occurs when using abbreviations. If anyone ever creates a conflict around BTC, the answer would be to re-tag it to the non-abbreviated form. Not create a whole new tagging scheme. In the case of XLT, just re-tag it to Nexalt and be done with it. We shouldn't be using abbreviations anyway. --Adamant1 (talk) 22:07, 5 September 2021 (UTC)

I might misunderstand your point, but the currency:crypto sub-key would be a good way to elevate the need to confirm with ISO 4217. In this way we could say that currency is ISO compliant, but currency:crypto only needs to use a code that is accepted widely within the crypto community.

Using codes instead of full names have many benefits I think, including that they can be used with different APIs, doesn't need capitalization for comparisons, they are the same in all languages, they are shorter, and they are similar in format to the fiat currency ISO codes. They are more practical in general.

At this stage of the cryptocurrencies adaption I think it is very important to note what crypto is accepted in what way. Defining the underlying technology (like layer-2) would be optional of course, but since it defines what wallets are compatible with the merchant it is very relevant for the user.

Your suggestion that "if anyone ever creates a conflict around BTC, the answer would be to re-tag it to the non-abbreviated form" would cause a lot of confusion, it would require automated edits, and it would make the solution not future-proof at all.

If you still have doubts about the proposal or the naming in its current form, please provide some example tags showing your recommended solution, so that I can see your point of view better.

--Andrasfuchs (talk) 10:51, 6 September 2021 (UTC)

@Andrasfuchs: I might be wrong, but as far as I know ISO 4217 is a standard for "real" currencies and therefore doesn't support cryptocurrency. There is no globally accepted alternative that does either. It's a little weird to front this proposal as being "ISO compliant" when cryptocurrencies aren't even supported by the ISO standard. Ultimately cryptocurrencies aren't regulated and anyone can create one with whatever three letter abbreviation they want to. So, there will probably be conflicts anyway between cryptocurrencies. Again, the answer is to not abbreviate the names. Not act like there's some kind of standard for abbreviating cryptocurrencies that doesn't exist that will magically keep conflicts from happening if OSM adopts it.

Re: "changing to the none abbreviated form would require automated edits" no it wouldn't. People are already using payment:bitcoin=* and there's currently no uses of currency:crypto:BTC=*. I'm simply saying stick to how cryptocurrencies are already being tagged. A person changing "BTC" to "bitcoin" to fit currently used tagging standards isn't an "automated edit." Although, changing all the currently existing uses of payment:bitcoin=* to currency:crypto:BTC=* like this proposal wants to would be an automated edit. I think the only argument that could be made for abbreviations is better API support, but that could just as well be accomplished with a tag similar to short_name=* but for cryptocurrencies. Which wouldn't require completely reinventing the wheel for no reason. --Adamant1 (talk) 18:08, 6 September 2021 (UTC)

Alright, so we have different opinions about this, but different opinions can make the proposal better. I will create a new section here to debate the codes vs. full names, others might want to join the conversation too.

What other changes would this proposal need to be more acceptable for you? (If there is a way for you to accept this new notation using the currency=* instead of payment=*.)

--Andrasfuchs (talk) 08:20, 7 September 2021 (UTC)

Full names vs. currency codes

Resolved: We are going to use option 2, using codes with currency:crypto, e.g. currency:crypto:BTC for Bitcoin.

There are more than 11'000 cryptocurrencies and tokens in circulation at the moment. Unlike the ISO standardization for fiat currencies, there is no centralized authority to decide which currency can use which code. The community needs to decide on its own what new cryptocurrency can use which 3 or 4 letter code. There has been disputes about these, but in general there is a consensus that are used on crypto-sites and exchanges, like coinmarketcap.com.

The question is, what is the best way to reference cryptocurrencies in OSM? There are several options, they all have their pros and cons:

1. Use their full names currency:crypto:Bitcoin=yes

+ makes it obvious for the non-crypto users what currency we refer to

+ we don't need to wait until the community settles for a cryptocurrency code

- capitalization might become a problem, because of inconsistencies (Bitcoin vs. bitcoin)

- makes the integration into other systems difficult, because most APIs use codes instead of full names

- although unlikely, they could be different in different languages

- if they contain spaces, special or language-specific characters, those could cause problems in the notation (Bitcoin Cash vs. BitcoinCash)

2. Use their codes currency:crypto:BTC=yes

+ makes working with other APIs easy

+ doesn't have any of the cons as option 1

+ it looks similar to the ISO-standard fiat currency codes

- it might be not obvious at first what code means which cryptocurrency, especially for unpopular cryptos

3. Use both their full names and their codes in one tag currency:crypto:Bitcoin-BTC=yes

+ helps the non-informed user to see what cryptocurrency the tag refers to, and makes the communication with APIs possible

- capitalization might become a problem (Bitcoin-BTC vs. bitcoin-btc vs. bitcoin-BTC)

- although unlikely, they could be different in different languages

- if they contain spaces, special or language-specific characters, those could cause problems in the notation (Bitcoin Cash-BCH vs. BitcoinCash-BCH)

4. Use both their full names and their codes in two tags currency:crypto:Bitcoin=yes + currency:crypto:BTC=yes

+ has all the pros of 1, and 2, so it satisfies both user groups who prefer 1, or 2,

- has nearly all the cons of 1, and 2,

- needs an extra administration to make sure that they are both there for all nodes/areas

5. Use full names and add short codes separately as a sub-key currency:crypto:Bitcoin=yes + currency:crypto:Bitcoin:short_name=BTC

- needs an extra administration to make sure that they are both there for all nodes/areas

- potentially confusing to use the short_name in the place of the layer-2 protocol definition

Which one do you like the most?

(Let me know if I missed a con/pro I'll add them to the list above.)

--Andrasfuchs (talk) 09:25, 7 September 2021 (UTC)

1. I don't really get what your point about capitalization of the name "bitcoin" is. It's already not being capitalized and there hasn't been any problems because of it. I don't see why there would ever be one either since most tagging schemes are lower case.

2. All of the cryptocurrency ATMs I've seen use the full name of the currency. Can you provide some examples where that's not the case?

3. Do you have any examples of current APIs that integrate with OSM and cryptocurrency where full names have caused problems? Because I don't think a tagging scheme should be created purely on hunches that something "might become a problem" later. -Adamant1 (talk) 02:48, 8 September 2021 (UTC)

If you check out the cryptocurrency section of the payment=* page, it's already recommended to use currency=* instead. Currency uses codes, not full names, so it would be advisable not to make an exception for cryptos. This proposal aims to unify and standardize the notation, so it doesn't really matter what tags crypto ATMs have at the moment. Fiat ATMs use currency=* and currency codes. As we discussed above payment:bitcoin should be replaced with currency:crypto:Bitcoin or currency:crypto:BTC anyway. Why do you think the full name would be better if we use currency=*, did I miss some advantages? Do you prefer option 1 then or you would prefer some of the others?

I have used some crypto APIs (all used codes), but none of them integrate OSM, partly because crypto acceptance tagging isn't consistent in OSM at the moment (e.g. both payment:bitcoin and currency:XBT are used, and it's not defined how non-ISO altcoins should be used). This proposal could change this. Do you agree though that we should standardize the way and move from payment=* to currency=* permanently?

--Andrasfuchs (talk) 08:15, 8 September 2021 (UTC)

1. Your kind of misconstruing things. What the article says is "Consider using currency:XBT." Which is just a suggestion. People can edit articles to suggest whatever they want. In no way is a suggestion anything like a mandate. In the meantime, currency:XBT only has 490 uses and payment:bitcoin has 7,500. So it's pretty clear which format is the preferred one and it's not abbreviations. I've already said I don't really care about conforming to non-existing, fantasy "standards." I care about how things are actually tagged, right now.

2. Re: "It doesn't really matter what tags crypto ATMs have at the moment because fait ATMs use currency codes." Good for fait ATMs. Their clearly different though. If a crypto ATM just says "Bitcoin" then whoever is mapping it will add "Bitcoin" to OSM. Not XBT or whatever. It's rather obtuse and slightly "tech broish" to expect mappers to look through a table of codes to add an ATM machine. The fact that Bitcoin has two abbreviations now just goes to show it. In the meantime though, it's never not going to be called Bitcoin. Realistically, if you actually want this to be future proof and "standardized" is it better to use an abbreviation that's likely to change in three years, or a full name that's not ever going to? Which is more likely to cause mapping errors and edit wars, two or more abbreviations that change over time or a single name that doesn't?

3. If you don't have any examples of API's that use OSM and cryptocurrencies, let alone examples of where there's been problems with the current tagging scheme, then you shouldn't use better integration with APIs as a reason to embrace this proposal. Especially if the concern comes at the cost of mappers. Which it really seems to. --Adamant1 (talk) 00:07, 9 September 2021 (UTC)

Thank you for sharing your thoughts again, and investing your valuable time into this proposal. I understand where you are coming from better now. I feel that you are against the whole proposal, not just the naming standard, so I stop trying to convince you.

I have been working on crypto-related project as a developer in the past 5 years and I see this proposal as an opportunity for both these projects and OSM, but I can see now, that this proposal can be seen as a problem, an unnecessary risk for some. That's fine, I'll post it for voting anyway knowing that I couldn't win your vote.

Again, thank you for sharing!

--Andrasfuchs (talk) 08:33, 9 September 2021 (UTC)

So your doing this proposal because you think it would be good for your pet projects? Nice. I'll keep my opinions about the bad faithed, colonialist style grifting involved in the cryptocurrency space out of this for now. Just an FYI though, proposals and feedback about them aren't a black or white thing, where just because someone gives feedback it means they are against the proposal. I'm actually pretty neutral on it, because I think it's premature and you haven't provided any evidence to back up your assertions. Does that mean I'm against it though? Not really.

It would have a much better chance of passing, and I'd totally vote for it, if you kept your personal opinions out of the proposal and provided references to actual problems it solves. But I'm not going to just take your word at face value that this would be better then what we currently have. In the meantime, there's zero reason we can't wait until there's actual ISO standards to create a proposal from. OSM doesn't have to, nor should it, adopt to every new cutting edge technology that comes along. Especially not because of feelings or it benefiting someone's pet project. --Adamant1 (talk) 20:00, 9 September 2021 (UTC)

1. This is caused by payment:*=* using full name as a standard, while the opposite is the norm in currency=*. Not necessarily one format is "preferred" everywhere. ---- Kovposch (talk) 12:54, 9 September 2021 (UTC)

"So your doing this proposal because you think it would be good for your pet projects? Nice. " this is 100% fine, though "I need it for my project" is not sufficient to justify tagging changes. BTW, nearly all new tags that I introduced/invented/promoted were because I needed them for some of my pet projects. For example see Proposed features/man made=bridge Mateusz Konieczny (talk) 11:11, 18 September 2021 (UTC)

Consider trimming ad at start

Resolved: Removed the questionable statements.

For example ""more than 11'000 cryptocurrencies" - and vast majority are failed, scams or failed scams.

"More than 10% of merchants accepted them in Venezuela at the end of 2020" - this is misrepresentation! From article itself "will surpass 10% of stores in 2020" - so it is merely prediction! From the start of the year! And BTC-adjacent stories are filled with failed predictions and blatant lies. And source itself is heavily biased.

Please remove all such misleading statements promoting cryptocurrencies.

Mateusz Konieczny (talk) 11:17, 18 September 2021 (UTC)

Yes, I think you are right, I removed the questionable statements.

--Andrasfuchs (talk) 11:03, 22 September 2021 (UTC)

Many new users voting in this proposal

When looking for spam and good faith edits by new users, I saw that many new user accounts voted in favour of this proposal. In order of account creation those users are Pozo, Strophy, Tao of Satoshi, Thefeiter, Spades, Dholliday5, Kot, Gubbes, and Bananabrain. Is that an issue? --Tigerfell  (Let's talk) 20:48, 13 October 2021 (UTC)

Tigerfell Those accounts are real. We created them in order to vote. We received word of this proposal through the DASH discord. --Spades 15:59, 13 October 2021 (UTC)

I am also a real person. We have had the experience of trying to build a Dash-only mapping service, which ended impossible to maintain. I am voting for this because I genuinely believe it is a better path forward to improve the metadata of a maps-first service than to try and bolt a mapping service on to a list of businesses accepting crypto. --Strophy 08:15, 14 October 2021 (UTC)

I would say that it depends on whether they are actual OSM editors or people who got instructions what to do (or single person making multiple accounts). Have they ever edited anything in OSM? I really dislike when I am right in cases like this (Proposed features/change vote counting rules proposed "one person voting multiple times or votes from people who are not involved in OSM mapping at all[1] must be ignored" with requirement to somehow link Wiki account and OSM account).Mateusz Konieczny (talk) 15:57, 14 October 2021 (UTC)

I am thinking about pinging users listed here and asking them about whether they ever edited anything in OSM and about their user account Mateusz Konieczny (talk) 15:57, 14 October 2021 (UTC)

Referring to suggested rules in one of your failed proposals is not a valid argument against this one. According to the current rules, you can surely try to prove that multiple votes were created by one user or account, but - as it was already explained above - it is very unlikely the case. --Andrasfuchs (talk) 18:48, 14 October 2021 (UTC)

Tigerfell, Mateusz Konieczny I'm a real user, deeply involved in crypto-space. I work for Dash Core Group, where we maintained our own mapping service, but it was very inefficient (due to multiple reasons). I find this proposal a big chance to expand both OSM and crypto user base and build very valuable use case for both. If this proposal is approved, I will be more than happy to contribute with updates. Kot 08:26, 15 October 2021 (UTC)

Being involved in cryptocurrency business means that you have a conflict of interest and your vote should not be counted. It does not matter what is written down in the proposal process rules due to the way how OSM works (insert explanation about free form tagging and absence of hard rules here). This means, if the result of this voting is influenced by the participation of users without sufficient OSM contribution in the past, the voting cannot be used as an argument in debates about how to tag things and if a tag should be used by editor presets. --Nakaner (talk) 10:09, 18 October 2021 (UTC)

I would be fine with people involved in cryptocurrency stuff that are actually OSM mappers. But mass registration of people who never did anything in OSM and brigading just present once more type of people involved in cryptocurrency gambling (I would not describe it as a business) Mateusz Konieczny (talk) 21:23, 18 October 2021 (UTC)

Personally, I wouldn't say that being involved in crypto is an issue if you are a mapper. However, if you haven't cared for OSM one bit until now, and sign up only to +1 a proposal, then that is problematic. It's exactly why I've voted no on this - I think it will invite a ton of one-trick ponies to OSM who do nothing else but add their own favourite crypto currency method to a few places (and then even forget to remove it when the crypto fan attention train moves on). --Woodpeck (talk) 18:39, 19 October 2021 (UTC)

To reiterate Nakaner's point: a wiki vote can be gamed easily, but a gamed wiki vote will inevitably be ignored. In fact, brigading would be self-defeating, dissuading the community from considering anything related to cryptocurrency in the future, regardless of the merits of a future proposal. – Minh Nguyễn ^💬 02:15, 20 October 2021 (UTC)

Excellent summary. --Nakaner (talk) 13:42, 20 October 2021 (UTC)