Redecentralizing the Web w/ @remotestorage and @kosmos. Evading winters w/ @hackerbeach. Traveling full-time since 2010. INTP.
Move slow and fix things.
| :xmpp: / ✉️ / :nostr: | raucao@kosmos.org |
| ⚡ | raucao@kosmos.org |
| Cycling, coffee, beer, food | Yes, please! |
The Google Play App review team has their own accounts. The Developer Console let's me enter test credentials. Sometimes they use those sometimes they just create new accounts. Depends on the individual reviewer.
The Play version doesn't have channel search. The only reason a reviewer would join a channel is that they explicitly entered the address or used an external search engine.
The last app update got rejected because the app hosts terrorist content.
How do browsers ever pass the test?
* Only drink coffee in the mornings
* Never drink coffee in the afternoon
* Don't drink coffee within 90 minutes of waking up
Thank you, social media health expert who listened to a Huberman podcast episode! I shall drink all my super-healthy-yet-dangerous coffee in the hour between 11 and 12 on most days, so I don't spike my caffeine levels too much.
@codewiz Context: https://github.com/bitcoin/bitcoin/pull/32359 (plus drama on X)
Which resulted in this merged solution: https://github.com/bitcoin/bitcoin/pull/32406
The statement and PR are different from what you're suggesting: if the tx is valid, then the OP_RETURN size should not be capped at an arbitrarily low limit by default, because OP_RETURN was made for storing data and can be pruned by nodes that don't care.
Why bitcoin? Because everything else has worse guarantees of persistence and integrity. Proof of Work required.
As per recent bitcoindev mailing list discussion. Also removes the code to enforce those limits, including the -datacarrier and -datacarriersize config options. These limits are easily bypassed by ...
Daniel Gultsch
Georgi
