-
@ dbe0605a:f8fd5b2c
2025-02-17 06:42:38
Originally posted on Nostr: https://highlighter.com/a/naddr1qvzqqqr4gupzpklqvpdfcuch9wkh2gary7erd4275jmrf6qw0z5sz0dhj8u06kevqyvhwumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wshszxrhwden5te0ve5kcar9wghxummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9emkjmn99uqzqjn0d9hz6argv5k57ur9dck5y6t5vdhkjm3df4shqtt5xduxz6tsrdmw7l
I care deeply about bitcoin adoption and ability to use bitcoin with all features of money — saving, spending, earning. We're entering an age where more and more people realise "hodl never spend" meme is hindering bitcoin adoption. More and more of use want to use bitcoin in everyday life, because we're living on it and because it's superior in every aspect. It's also incredibly fun to use it for payments.
For money to thrive, it needs to circulate. Spending bitcoin orangepills merchants, their families and people around them — with each bitcoiner coming to a shop and paying with bitcoin, it's a point of contact that can trigger a train of though that later may fruit into action — "_Why are they so interested in bitcoin, what's actually so special about it?_" "_Hmm, maybe this time I will not exchange it for fiat immediately?_"
Global merchant adoption grows, every day new business around the world decide to start accepting bitcoin payments. Circular economies are blooming on all continents, where people live in a new, experimental, orange coin paradigm. Companies and projects like Blink, Bitcoin Jungle, Plan B, Orange Pill App do an amazing job in facilitating this — providing great wallets, tools & services for merchants, and finally onboarding merchants themself. They also often support circular economies financially or in other ways. This is very valuable and makes the road to hyperbitcoinization a tad shorter.
But there is one thing those companies are doing wrong — they're using their own, proprietary maps that display only merchants using their own wallets or POS software. I'd like to now list a few reasons why those great projects should migrate their maps into an open source, bitcoin map that is BTC Map.
## Open source, stupid
[BTCmap](https://btcmap.org/) is open source, built on OpenStreetMaps, open to both developers contributions but also for map taggers (called [shadowy supertaggers](https://www.openstreetmap.org/)). Anyone can contribute, even If you don't code. Anyone can verify merchants or add new merchants to the map. BTC Map team developed [a neat system of verifications](https://btcmap.org/verify-location) that just works better than anything before or any alternative maps today.
## Many apps, one map
BTC Map is integrated inside a dozen of wallets and apps, to name a few: Wallet of Satoshi, Coinos, Bitlocal, Fedi or Aqua. It's a public good that any bitcoin product can use and grow it's network effect.
## Uniting mappers' work
BTC Map does not discriminate bitcoin merchants, that means all the merchants from proprietary maps are being mapped by taggers to BTC Map. By mapping on a closed source, proprietary map, the same merchant is mapped two times, usually by two different people — it's duplicating the same work without any bringing any benefit to both projects. Using BTC Map also brings you way more people verifying If those merchants actually still accept bitcoin, making it easier to have an up-to-date database of actual adoption.
## More bitcoin spent at your merchants
When you have a business focused on spending bitcoin and onboarding merchants, you want as much bitcoin spent there as possible. If a bitcoiner coming to the area does not use your own map but some other map, they can be completely unaware that they can let their sats flow to your merchants. If we all use one merchants database, this problem disappears and more sats will flow. Why wouldn't you want your merchants displayed in dozens of other apps, completely for free?
## OpenStreetMap map is just better
Take a look at the image above: It's [La Pirraya](https://btcmap.org/community/bitcoin-la-pirraya), a small sleepy island town in El Salvador with a circular economy being facilitated by Bitcoin Beach. Even though Blink has many more merchants compared to BTC Map, when I visited it a few months ago I could find them. Not because they do not exist, but because the map does not show any roads and it was very hard to locate them in a dense network of narrow streets of La Pirraya. BTC Map allows you to turn multiple versions of satellite maps views, making it way easier to find your point of interest. Pins also indicate what kind of business it is, where in Blink all the pins are the same and you need to click each to find out what it is. Even then not always it's clear, since Blink only displays names, while BTC Map tells you type of the merchant, and very often shows you working hours, phone numbers, website, social links, etc.
## Excellent community tools
BTC Map is focusing providing tools for communities to maintain their merchants map. [Each community has it's own page](https://btcmap.org/communities) with own links to community website or socials, displays a list of all the merchants, shows community stats, displays merchants that were not verified for a long time, and more. It even allows to "boost" merchants to make them more visible on the map and on the list. It's perfect tooling both for communities and businesses onboarding merchants to their software.
## Easy integration & configuration
Integrating BTC Map on your website or app is easy. It's just [a few lines of code of iframe](https://arc.net/l/quote/vrdudfnn) to embed the map, but you can also use [BTC Map API](https://arc.net/l/quote/sybkpvcu) for more custom integration. Do you to display, eg. you can display only merchants from your community? No problem, you can do that. Since it's all open source, you can configure it in many ways that will suit your needs.
## Kudos
I'd like to thank projects that understood all above and integrated BTC Map already. Those are Coinos, Wallet of Satoshi, Pouch, Bolt Card, BitLocal, Fedi, Decouvre Bitcoin, Osmo, Bitcoin Rocks!, Lipa, Spirit of Satoshi, Blockstream, Satlantis, Aqua Wallet and Adopting Bitcoin
## Encouragement & an offer
I'll end that with encouragement to projects that use their own maps, but haven't embraced BTC Map yet. Those are Blink, Bitcoin Jungle, Plan B, Osmo, Athena, Orange Pill App, Inbitcoin (I probably missed some, tag them!). You are doing great work, but let's join forces and paint the world orange together!
From here I would like to offer help in tagging your merchants on BTC Map. Just reach me out, and me and other supertaggers will do the work.
Let the sats flow!
originally posted at https://stacker.news/items/888088
-
@ 47750177:8969e41a
2025-01-09 12:00:00
28.1 Release Notes
=====================
Bitcoin Core version 28.1 is now available from:
- 🌐 <https://bitcoincore.org/bin/bitcoin-core-28.1>
- 🧲 <magnet:?xt=urn:btih:60837ded9c7e11b2a44f2ae7bc8e6fe3a3d7ee5c&dn=bitcoin-core-28.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http://bitcoincore.org/bin/>
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
<https://github.com/bitcoin/bitcoin/issues>
To receive security and update notifications, please subscribe to:
<https://bitcoincore.org/en/list/announcements/join/>
How to Upgrade
==============
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
or `bitcoind`/`bitcoin-qt` (on Linux).
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.
Running Bitcoin Core binaries on macOS requires self signing.
```
cd /path/to/bitcoin-28.x/bin
xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin
codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin
```
Compatibility
==============
Bitcoin Core is supported and extensively tested on operating systems
using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin
Core should also work on most other UNIX-like systems but is not as
frequently tested on them. It is not recommended to use Bitcoin Core on
unsupported systems.
Notable changes
===============
### P2P
- When the `-port` configuration option is used, the default onion listening port will now
be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet).
This re-allows setups with multiple local nodes using different `-port` and not using `-bind`,
which would lead to a startup failure in v28.0 due to a port collision.
Note that a `HiddenServicePort` manually configured in `torrc` may need adjustment if used in
connection with the `-port` option.
For example, if you are using `-port=5555` with a non-standard value and not using `-bind=...=onion`,
previously Bitcoin Core would listen for incoming Tor connections on `127.0.0.1:8334`.
Now it would listen on `127.0.0.1:5556` (`-port` plus one). If you configured the hidden service manually
in torrc now you have to change it from `HiddenServicePort 8333 127.0.0.1:8334` to `HiddenServicePort 8333
127.0.0.1:5556`, or configure bitcoind with `-bind=127.0.0.1:8334=onion` to get the previous behavior.
(#31223)
- #30568 addrman: change internal id counting to int64_t
### Key
- #31166 key: clear out secret data in DecodeExtKey
### Build
- #31013 depends: For mingw cross compile use `-gcc-posix` to prevent library conflict
- #31502 depends: Fix CXXFLAGS on NetBSD
### Test
- #31016 test: add missing sync to feature_fee_estimation.py
- #31448 fuzz: add cstdlib to FuzzedDataProvider
- #31419 test: fix MIN macro redefinition
- #31563 rpc: Extend scope of validation mutex in generateblock
### Doc
- #31007 doc: add testnet4 section header for config file
### CI
- #30961 ci: add LLVM_SYMBOLIZER_PATH to Valgrind fuzz job
### Misc
- #31267 refactor: Drop deprecated space in `operator""_mst`
- #31431 util: use explicit cast in MultiIntBitSet::Fill()
Credits
=======
Thanks to everyone who directly contributed to this release:
- fanquake
- Hennadii Stepanov
- laanwj
- MarcoFalke
- Martin Zumsande
- Marnix
- Sebastian Falbesoner
As well as to everyone that helped with translations on
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
-
@ 3bf0c63f:aefa459d
2024-11-07 14:56:17
# The case against edits
Direct edits are a centralizing force on Nostr, a slippery slope that should not be accepted.
Edits are fine in other, more specialized event kinds, but the `kind:1` space shouldn't be compromised with such a push towards centralization, because [`kind:1` is the public square of Nostr, where all focus should be on decentralization and censorship-resistance](cd8ce2b7).
- _Why?_
Edits introduce too much complexity. If edits are widespread, all clients now have to download dozens of extra events at the same time while users are browsing a big feed of notes which are already coming from dozens of different relays using complicated outbox-model-based querying, then for each event they have to open yet another subscription to these relays -- or perform some other complicated batching of subscriptions which then requires more complexity on the event handling side and then when associating these edits with the original events. I can only imagine this will hurt apps performance, but it definitely raises the barrier to entry and thus necessarily decreases Nostr decentralization.
Some clients may be implemneted in way such that they download tons of events and then store them in a local databases, from which they then construct the feed that users see. Such clients may make edits potentially easier to deal with -- but this is hardly an answer to the point above, since such clients are already more complex to implement in the first place.
- _What do you have against complex clients?_
The point is not to say that all clients should be simple, but that it should be simple to write a client -- or at least as simple as physically possible.
You may not be thinking about it, but if you believe in the promise of Nostr then we should expect to see Nostr feeds in many other contexts other than on a big super app in a phone -- we should see Nostr notes being referenced from and injected in unrelated webpages, unrelated apps, hardware devices, comment sections and so on. All these micro-clients will have to implement some complicated edit-fetching logic now?
- _But aren't we already fetching likes and zaps and other things, why not fetch edits too?_
Likes, zaps and other similar things are optional. It's perfectly fine to use Nostr without seeing likes and/or zaps -- and, believe me, it does happen quite a lot. The point is basically that likes or zaps don't affect the content of the main post at all, while edits do.
- _But edits are optional!_
No, they are not optional. If edits become widespread they necessarily become mandatory. Any client that doesn't implement edits will be displaying false information to its users and their experience will be completely broken.
- _That's fine, as people will just move to clients that support edits!_
Exactly, that is what I expect to happen too, and this is why I am saying edits are a centralizing force that we should be fighting against, not embracing.
If you understand that edits are a centralizing force, then you must automatically agree that they aren't a desirable feature, given that if you are reading this now, with Nostr being so small, there is a 100% chance you care about decentralization and you're not just some kind of lazy influencer that is only doing this for money.
- _All other social networks support editing!_
This is not true at all. Bluesky has 10x more users than Nostr and doesn't support edits. Instagram doesn't support editing pictures after they're posted, and doesn't support editing comments. Tiktok doesn't support editing videos or comments after they're posted. YouTube doesn't support editing videos after they're posted. Most famously, email, the most widely used and widespread "social app" out there, does not support edits of any kind. Twitter didn't support edits for the first 15 years of its life, and, although some people complained, it didn't hurt the platform at all -- arguably it benefitted it.
If edits are such a straightforward feature to add that won't hurt performance, that won't introduce complexity, and also that is such an essential feature users could never live without them, then why don't these centralized platforms have edits on everything already? There must be something there.
- _Eventually someone will implement edits anyway, so why bother to oppose edits now?_
Once Nostr becomes big enough, maybe it will be already shielded from such centralizing forces by its sheer volume of users and quantity of clients, maybe not, we will see. All I'm saying is that we shouldn't just push for bad things now just because of a potential future in which they might come.
- _The market will decide what is better._
The market has decided for Facebook, Instagram, Twitter and TikTok. If we were to follow what the market had decided we wouldn't be here, and you wouldn't be reading this post.
- _OK, you have convinced me, edits are not good for the protocol. But what do we do about the users who just want to fix their typos?_
There are many ways. The annotations spec, for example, provides a simple way to append things to a note without being a full-blown edit, and they fall back gracefully to normal replies in clients that don't implement the full annotations spec.
Eventually we could have annotations that are expressed in form of simple (human-readable?) diffs that can be applied directly to the post, but fall back, again, to comments.
Besides these, a very simple idea that wasn't tried yet on Nostr yet is the idea that has been tried for emails and seems to work very well: delaying a post after the "submit" button is clicked and giving the user the opportunity to cancel and edit it again before it is actually posted.
Ultimately, if edits are so necessary, then maybe we could come up with a way to implement edits that is truly optional and falls back cleanly for clients that don't support them directly and don't hurt the protocol very much. Let's think about it and not rush towards defeat.