Thank you for explaining. I never understood the aggregation of donations process.
Maybe a majority of their customers are paying $1 to 1 person?
Are there really people that give away x $1/month to multiple random internet folks? I don't get it.
I feel you should have more empathy for people that do not look like you.
For some people, race, fighting for for recognition, let alone equality, is a daily battle. You may live and work far from this conflict, but it exists, and in some part the diversity modifiers for emoji provide folks with empowerment. Don't take that away over limitations in the spec.
There are billions now who own smart phones, and want that funny Japanese Telco encoding standard to reflect their world too.
This is not a technical or standards problem, and the fitzpatrick modifiers do not decrease functionality of unicode.
I feel my point is to chill, and consider how functionality outside your perceived value might bring others joy.
So why not just use fiat? Coinbase used to offer this service, where you would 'auto-topup' your balance, but removed this because it was silly as it generated multiple tx's just to do what paying in fiat would achieve in the first place.
As time goes on, the notion that coffee or meals are suitable to be paid in bitcoin seems more absurd. You would no more pay for a meal with a gold bar than you would with a Krugerrand. It will be seen as decadent for all those pizzas, controlled substances and ransoms to have been paid in BTC -- a kings ransom for pizza?
Bitcoin will likely never be a general purpose payment network. Lightning MAY if it obtains support from legacy services like VISA and MASTERCARD. I suspect V/MC will be the lightning nodes with the most payment channel volume.
The dangers of tx replay mean that HF's like this can never be safe.
Beware those that would tell you that these forks are safe, they are not.
This is another scam from those that would try to usurp the blockchain.
You will be able to replay original bitcoin and abc tx's on each chain, unless you opt-in to some funny new untesed hash.
This will hugely disrupt the minority chain ABC, as the mempools on cash chain fill with other valid tx's from main chain.
Its going to be a bloodbath. Steer very clear!
Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.
The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.
The second method uses an OP_RETURN output which has the exact string:
Bitcoin: A Peer-to-Peer Electronic Cash System
as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.
The filter on XKS that prevents US hits on selectors has been enhanced to satisfy ruling of the court.
Its still collected in perpetuity, but under the Schrödinger approach to surveillance it no longer exists.
Maybe nothing can truly change, just as one cannot uninvent a technology -- telephony, broadcasting or social media are with us forever. Maybe true to for global passive surveillance.
go.secrets uses the libsodium sodium_memzero to clear the bytes, whereas memguard sets each byte to 0.
I feel more comfortable with the first, but can't exactly explain why. memguard seems better organised in the repo like a ready to go package; I think go.secrets would be a better solution if it was organised as well as memguard.