This document is a work in progress.
I've read in #monero-events that the call was for:
designs for logo, graphic style, poster, banners, t-shirts, other promotional materials 50% upfront and 50% after submitting files graphic proposals by the end of March, beginning of April files to print by mid/late April
References: https://p2p.pizzaday.cz/
This document describes the search for a checksum algorithm to be used with Monero's new addressing scheme Jamtis. The purpose of the checksum is to detect accidental corruption of the address string.
Since Jamtis encodes addresses in base32, it allows the use of cyclic codes, which can provide guaranteed error detection, unlike hash-based checksums.
Monero currently uses a 32-bit hash-based checksum for its addresses. Hash-based checksums have a flat false positive rate regardless of the number of errors. Bitcoin's bech32 address format uses a degree-6 cyclic code optimized for short addresses of up to 89 characters. The cashaddr address format of Bitcoin Cash uses a degree-8 cyclic code that can detect 5 errors for lengths of up to 130 characters.
This has been deprecated for Featured Addresses.
Monero payments are not guaranteed to be spendable, when individual transactions are scanned. Only when the entire chain is scanned will you learn if an output has conflicts, and only with the private spend key can you see if one of those conflicts has been spent, already having burnt all potentially usable outputs. This makes view-only scanning of the chain insecure, under the standing policy of "credit difference", as the wallet will credit the difference even if the funds are already burnt.
It should be noted wallet2 will stop crediting the difference if it knows the key image was used, as it should, yet it will continually credit if view-only, as it'll never learn when key images are used (unless imported, which may break a desired privacy model). Unfortunately, this is not an issue with a simple fix. Solely crediting the initial transfer potentially leaves fun
Hello <>,
I notice that you accept Bitcoin as payment for your services. Increasingly, merchants whose customers care about privacy accept payments and donations in Monero (XMR). Monero offers strong privacy protections by default.
There are many ways to accept Monero, including direct acceptance, BTCPayServer, GloBee, and NOWPayments (which also can convert to an EUR bank account for settlement).
Thank you for your time, and please do not hesitate to ask if you have questions. Adding support for Monero isn't just you adding any other coin; it's the world's most used private digital payment option.
Thanks,
This document serves as a small tutorial for new and/or existing Monero node operators who wish to support I2P users by allowing their nodes to communicate p2p through I2P.
You should be able to get through this document and host an I2P node in ~20 minutes.
| # https://github.com/tiangolo/fastapi/issues/258#issuecomment-495975801 | |
| from typing import List | |
| from fastapi import FastAPI | |
| from starlette.responses import HTMLResponse | |
| from starlette.websockets import WebSocket, WebSocketDisconnect | |
| app = FastAPI() |
These are the steps I followed enable VirtualBox on my laptop without disabling UEFI Secure Boot. They're nearly identical to the process described on [Øyvind Stegard's blog][blog], save for a few key details. The images here are borrowed from the [Systemtap UEFI Secure Boot Wiki][systemtap].
src='https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo'