February 2023 - cypherpunks@lists.ogf.org

AI prediction markets
by professor rat 17 Feb '23

17 Feb '23

– Will ChatGPT remain free through April 30?: https://polymarket.com/event/will-chatgpt-remain-free-through-april-30 – Will GPT-4 have 500b+ parameters?: https://polymarket.com/event/will-gpt-4-have-500b-parameters – Will OpenAI release GPT-4 by May 31?: https://polymarket.com/event/will-openai-release-gpt-4-by-may-31 – Will Bing’s market share be >4% in February?: https://polymarket.com/event/will-bings-market-share-be-4-in-february All raise the question Will conservatives be shot like floppy rabbits for trying to corrupt net intelligence with GIGO? ( That's a rhetorical question - I know at least one will be )

1 0

APster into AmeriKa
by professor rat 17 Feb '23

17 Feb '23

ASSASSINATE all congress-critters! https://twitter.com/emptywheel/status/1626343504027828224?cxt=HHwWgIC-hZuz9… Reposts not Zerzanian energy pumped into gaseous balloons

2 1

Utopia, dystopia, and Star Trek.
by professor rat 16 Feb '23

16 Feb '23

http://www.anarresproject.org/voices/orosco/ Reposts not endorsements of Odo-ism or blanket pacifism

1 0

[ot[[spam][crazy] tiny decision tranaformer lib
by Undescribed Horrific Abuse, One Victim & Survivor of Many 16 Feb '23

16 Feb '23

https://github.com/xloem/datadecisions/blob/main/testcase.py new inhibited puzzle. this lib project rose as incentive for me to share idea steps publicly in the future # write here a way to reproduce the tutorial more usefully and simply # ensure it is easy to make new environments and provide custom data, # without needing to refer to external documentation or many different files

1 24

Cryptocurrency: Action - Squeeze George Soros Evil Nutsack Till He Pays
by grarpamp 16 Feb '23

16 Feb '23

Soros shorted Silvergate (SI) the crypto friendly bank, so now crypto coiners are throwing money into SI to force Soros and the rest of the anti-crypto shorts to buy back at an infinite price squeeze. Justice Served Soros Style ;-) search: Silvergate Squeeze Soros https://www.youtube.com/watch?v=QSyczwuTQfo Soros Psychopath Long history of amoral diabolical activities easily searched, from Globalist, Fiat gambling country wrecker, hypocrite Jewish persecutor, Socialist Marxist Communist funder and supporter of violence, and now to Anti-Crypto friend of GovBankCorpPolFiat. Sound money crypto has already achieved global charitable giving and, when held and used distributed in the hands of a Free Conscious Humanity, shall end these global tyrants and politicians, and their wars, genocide, theft, murder, and rape.

1 0

Revealed: USAID’s workforce crisis
by Gunnar Larson 16 Feb '23

16 Feb '23

Low morale and empty desks, aid workers who say they are treated like office supplies, warnings against organized strikes, and a “virtual caste system” of inequitable hiring mechanisms — the U.S. Agency for International Development is in the throes of a workforce crisis. For years, USAID has been warned that its workforce system is broken. Now, it’s becoming harder to ignore. Interviews with key members of Administrator Samantha Power’s team and aid workers bearing the brunt of two decades of dysfunction, and dozens of reports and internal documents, paint a picture of an agency in an increasingly untenable position. The situation is threatening its ability to respond to unprecedented levels of humanitarian need. Power has pledged to tackle the issue — but can she?

1 0

[ot][spam][crazy] having working memory issues is like being a short context model
by Undescribed Horrific Abuse, One Victim & Survivor of Many 16 Feb '23

16 Feb '23

except you make human behavior instead of marketing

1 0

[spam][crazy] coping around codex32 share
by Undescribed Horrific Abuse, One Victim & Survivor of Many 16 Feb '23

16 Feb '23

codex32

1 13

Private Key Recovery Fwd: [bitcoin-dev] Codex32
by Undescribed Horrific Abuse, One Victim & Survivor of Many 16 Feb '23

16 Feb '23

---------- Forwarded message ---------- From: Russell O'Connor via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> Date: Wed, 15 Feb 2023 21:16:02 -0500 Subject: [bitcoin-dev] Codex32 To: Bitcoin Protocol Discussion <bitcoin-dev(a)lists.linuxfoundation.org> I've been asked by Dr. Curr and Professor Snead to forward this message to this mailing list, as it may be of general interest to Bitcoin users. Dear Colleague: In 1967, during excavation for the construction of a new shopping center in Monroeville, Pennsylvania, workers uncovered a vault containing a cache of ancient scrolls[1]. Most were severely damaged, but those that could be recovered confirmed the existence of a secret society long suspected to have been active in the region around the year 200 BC. Based on a translation of these documents, we now know that the society, the Cult of the Bound Variable, was devoted to the careful study of computation, over two millennia before the invention of the digital computer. While the Monroeville scrolls make reference to computing machines made of sandstone, most researchers believed this to be a poetic metaphor and that the "computers" were in fact the initiates themselves, carrying out the unimaginably tedious steps of their computations with reed pens on parchment. Within the vault, a collection of sandstone wheels marked in a language consisting of 32 glyphs was found. After 15 years of study, we have successfully completed the translation of what is known as "Codex32," a document that describes the functions of the wheels. It was discovered that the wheels operate a system of cryptographic computations that was used by cult members to safeguard their most valuable secrets. The Codex32 system allows secrets to be carved into multiple tablets and scattered to the far corners of the earth. When a sufficient number of tablets are brought together the stone wheels are manipulated in a manner to recover the secrets. This finding may be of particular interest to the Bitcoin community. Below we provide a summary of the cult's secret sharing system, which is graciously hosted at < https://github.com/apoelstra/bips/blob/2023-02--volvelles/bip-0000.mediawiki >. We are requesting a record assignment in the Bibliography of Immemorial Philosophy (BIP) repository. Thank you for your consideration. Dr. Leon O. Curr and Professor Pearlwort Snead Department of Archaeocryptography Harry Q. Bovik Institute for the Advancement [1] http://www.boundvariable.org/task.shtml -----BEGIN BIP----- <pre> BIP: ???? Layer: Applications Title: codex32 Author: Leon Olsson Curr and Pearlwort Sneed <pearlwort(a)wpsoftware.net> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: ???? Created: 2023-02-13 License: BSD-3-Clause Post-History: FIXME </pre> ==Introduction== ===Abstract=== This document describes a standard for backing up and restoring the master seed of a [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032] hierarchical deterministic wallet, using Shamir's secret sharing. It includes an encoding format, a BCH error-correcting checksum, and algorithms for share generation and secret recovery. Secret data can be split into up to 31 shares. A minimum threshold of shares, which can be between 1 and 9, is needed to recover the secret, whereas without sufficient shares, no information about the secret is recoverable. ===Copyright=== This document is licensed under the 3-clause BSD license. ===Motivation=== BIP-0032 master seed data is the source entropy used to derive all private keys in an HD wallet. Safely storing this secret data is the hardest and most important part of self-custody. However, there is a tension between security, which demands limiting the number of backups, and resilience, which demands widely replicated backups. Encrypting the seed does not change this fundamental tradeoff, since it leaves essentially the same problem of how to back up the encryption key(s). To allow users freedom to make this tradeoff, we use Shamir's secret sharing, which guarantees that any number of shares less than the threshold leaks no information about the secret. This approach allows increasing safety by widely distributing the generated shares, while also providing security against the compromise of one or more shares (as long as fewer than the threshold have been compromised). [https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039] has essentially the same motivations as this standard. However, unlike SLIP-0039, this standard also aims to be simple enough for hand computation. Users who demand a higher level of security for particular secrets, or have a general distrust in digital electronic devices, have the option of using hand computation to backup and restore secret data in an interoperable manner. Note that hand computation is optional, the particular details of hand computation are outside the scope of this standard, and implementers do not need to be concerned with this possibility. [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] serves the same purpose as this standard: encoding master seeds for storage by users. However, BIP-0039 has no error-correcting ability, cannot sensibly be extended to support secret sharing, has no support for versioning or other metadata, and has many technical design decisions that make implementation and interoperability difficult (for example, the use of SHA-512 to derive seeds, or the use of 11-bit words). ==Specification== ===codex32=== A codex32 string is similar to a Bech32 string defined in [ https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173]. It reuses the base32 character set from BIP-0173, and consists of: * A human-readable part, which is the string "ms" (or "MS"). * A separator, which is always "1". * A data part which is in turn subdivided into: ** A threshold parameter, which MUST be a single digit between "2" and "9", or the digit "0". *** If the threshold parameter is "0" then the share index, defined below, MUST have a value of "s" (or "S"). ** An identifier consisting of 4 Bech32 characters. ** A share index, which is any Bech32 character. Note that a share index value of "s" (or "S") is special and denotes the unshared secret (see section "Unshared Secret"). ** A payload which is a sequence of up to 74 Bech32 characters. (However, see '''Long codex32 Strings''' below for an exception to this limit.) ** A checksum which consists of 13 Bech32 characters as described below. As with Bech32 strings, a codex32 string MUST be entirely uppercase or entirely lowercase. The lowercase form is used when determining a character's value for checksum purposes. For presentation, lowercase is usually preferable, but uppercase SHOULD be used for handwritten codex32 strings. ===Checksum=== The last thirteen characters of the data part form a checksum and contain no information. Valid strings MUST pass the criteria for validity specified by the Python3 code snippet below. The function <code>ms32_verify_checksum</code> must return true when its argument is the data part as a list of integers representing the characters converted using the bech32 character table from BIP-0173. To construct a valid checksum given the data-part characters (excluding the checksum), the <code>ms32_create_checksum</code> function can be used. <source lang="python"> MS32_CONST = 0x10ce0795c2fd1e62a def ms32_polymod(values): GEN = [ 0x19dc500ce73fde210, 0x1bfae00def77fe529, 0x1fbd920fffe7bee52, 0x1739640bdeee3fdad, 0x07729a039cfc75f5a, ] residue = 0x23181b3 for v in values: b = (residue >> 60) residue = (residue & 0x0fffffffffffffff) << 5 ^ v for i in range(5): residue ^= GEN[i] if ((b >> i) & 1) else 0 return residue def ms32_verify_checksum(data): if len(data) >= 96: # See Long codex32 Strings return ms32_verify_long_checksum(data) if len(data) <= 93: return ms32_polymod(data) == MS32_CONST return False def ms32_create_checksum(data): if len(data) > 80: # See Long codex32 Strings return ms32_create_long_checksum(data) values = data polymod = ms32_polymod(values + [0] * 13) ^ MS32_CONST return [(polymod >> 5 * (12 - i)) & 31 for i in range(13)] </source> ===Error Correction=== A codex32 string without a valid checksum MUST NOT be used. The checksum is designed to be an error correcting code that can correct up to 4 character substitutions, up to 8 unreadable characters (called erasures), or up to 13 consecutive erasures. Implementations SHOULD provide the user with a corrected valid codex32 string if possible. However, implementations SHOULD NOT automatically proceed with a corrected codex32 string without user confirmation of the corrected string, either by prompting the user, or returning a corrected string in an error message and allowing the user to repeat their action. We do not specify how an implementation should implement error correction. However, we recommend that: * Implementations make suggestions to substitute non-bech32 characters with bech32 characters in some situations, such as replacing "B" with "8", "O" with "0", "I" with "l", etc. * Implementations interpret "?" as an erasure. * Implementations optionally interpret other non-bech32 characters, or characters with incorrect case, as erasures. * If a string with 8 or fewer erasures can have those erasures filled in to make a valid codex32 string, then the implementation suggests such a string as a correction. * If a string consisting of valid Bech32 characters in the proper case can be made valid by substituting 4 or fewer characters, then the implementation suggests such a string as a correction. ===Unshared Secret=== When the share index of a valid codex32 string (converted to lowercase) is the letter "s", we call the string a codex32 secret. The subsequent data characters in a codex32 secret, excluding the final checksum of 13 characters, is a direct encoding of a BIP-0032 HD master seed. The master seed is decoded by converting the data to bytes: * Translate the characters to 5 bits values using the bech32 character table from BIP-0173, most significant bit first. * Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or less, and is discarded. Note that unlike the decoding process in BIP-0173, we do NOT require that the incomplete group be all zeros. For an unshared secret, the threshold parameter (the first character of the data part) is ignored (beyond the fact it must be a digit for the codex32 string to be valid). We recommend using the digit "0" for the threshold parameter in this case. The 4 character identifier also has no effect beyond aiding users in distinguishing between multiple different master seeds in cases where they have more than one. ===Recovering Master Seed=== When the share index of a valid codex32 string (converted to lowercase) is not the letter "s", we call the string an codex32 share. The first character of the data part indicates the threshold of the share, and it is required to be a non-"0" digit. In order to recover a master seed, one needs a set of valid codex32 shares such that: * All shares have the same threshold value, the same identifier, and the same length. * All of the share index values are distinct. * The number of codex32 shares is exactly equal to the (common) threshold value. If all the above conditions are satisfied, the <code>ms32_recover</code> function will return a codex32 secret when its argument is the list of codex32 shares with each share represented as a list of integers representing the characters converted using the bech32 character table from BIP-0173. <source lang="python"> bech32_inv = [ 0, 1, 20, 24, 10, 8, 12, 29, 5, 11, 4, 9, 6, 28, 26, 31, 22, 18, 17, 23, 2, 25, 16, 19, 3, 21, 14, 30, 13, 7, 27, 15, ] def bech32_mul(a, b): res = 0 for i in range(5): res ^= a if ((b >> i) & 1) else 0 a *= 2 a ^= 41 if (32 <= a) else 0 return res def bech32_lagrange(l, x): n = 1 c = [] for i in l: n = bech32_mul(n, i ^ x) m = 1 for j in l: m = bech32_mul(m, (x if i == j else i) ^ j) c.append(m) return [bech32_mul(n, bech32_inv[i]) for i in c] def ms32_interpolate(l, x): w = bech32_lagrange([s[5] for s in l], x) res = [] for i in range(len(l[0])): n = 0 for j in range(len(l)): n ^= bech32_mul(w[j], l[j][i]) res.append(n) return res def ms32_recover(l): return ms32_interpolate(l, 16) </source> ===Generating Shares=== If we already have ''t'' valid codex32 strings such that: * All strings have the same threshold value ''t'', the same identifier, and the same length * All of the share index values are distinct Then we can derive additional shares with the <code>ms32_interpolate</code> function by passing it a list of exactly ''t'' of these codex32 strings, together with a fresh share index distinct from all of the existing share indexes. The newly derived share will have the provided share index. Once a user has generated ''n'' codex32 shares, they may discard the codex32 secret (if it exists). The ''n'' shares form a ''t'' of ''n'' Shamir's secret sharing scheme of a codex32 secret. There are two ways to create an initial set of ''t'' valid codex32 strings, depending on whether the user already has an existing master seed to split. ====For an existing master seed==== Before generating shares for an existing master seed, it first must be converted into a codex32 secret, as described above. The conversion process consists of: * Choosing a threshold value ''t'' between 2 and 9, inclusive * Choosing a 4 bech32 character identifier ** We do not define how to choose the identifier, beyond noting that it SHOULD be distinct for every master seed the user may need to disambiguate. * Setting the share index to "s" * Setting the payload to a Bech32 encoding of the master seed, padded with arbitrary bits * Generating a valid checksum in accordance with the Checksum section Along with the codex32 secret, the user must generate ''t''-1 other codex32 shares, each with the same threshold value, the same identifier, and a distinct share index. The set of share indexes may be chosen arbitrarily. The payload of each of these codex32 shares is chosen uniformly at random such that it has the same length as the payload of the codex32 secret. For each share, a valid checksum must be generated in accordance with the Checksum section. The codex32 secret and the ''t''-1 codex32 shares form a set of ''t'' valid codex32 strings from which additional shares can be derived as described above. ====For a fresh master seed==== In the case that the user wishes to generate a fresh master seed, the user chooses a threshold value ''t'' and an identifier, then generates ''t'' random codex32 shares, using the generation procedure from the previous section. As before, each share must have the same threshold value ''t'', the same identifier, and a distinct share index. With this set of ''t'' codex32 shares, new shares can be derived as discussed above. This process generates a fresh master seed, whose value can be retrieved by running the recovery process on any ''t'' of these shares. ===Long codex32 Strings=== The 13 character checksum design only supports up to 80 data characters. Excluding the threshold, identifier and index characters, this limits the payload to 74 characters or 46 bytes. While this is enough to support the 32-byte advised size of BIP-0032 master seeds, BIP-0032 allows seeds to be up to 64 bytes in size. We define a long codex32 string format to support these longer seeds by defining an alternative checksum. <source lang="python"> MS32_LONG_CONST = 0x43381e570bf4798ab26 def ms32_long_polymod(values): GEN = [ 0x3d59d273535ea62d897, 0x7a9becb6361c6c51507, 0x543f9b7e6c38d8a2a0e, 0x0c577eaeccf1990d13c, 0x1887f74f8dc71b10651, ] residue = 0x23181b3 for v in values: b = (residue >> 70) residue = (residue & 0x3fffffffffffffffff) << 5 ^ v for i in range(5): residue ^= GEN[i] if ((b >> i) & 1) else 0 return residue def ms32_verify_long_checksum(data): return ms32_long_polymod(data) == MS32_LONG_CONST def ms32_create_long_checksum(data): values = data polymod = ms32_long_polymod(values + [0] * 15) ^ MS32_LONG_CONST return [(polymod >> 5 * (14 - i)) & 31 for i in range(15)] </source> A long codex32 string follows the same specification as a regular codex32 string with the following changes. * The payload is a sequence of between 75 and 103 Bech32 characters. * The checksum consists of 15 Bech32 characters as defined above. A codex32 string with a data part of 94 or 95 characters is never legal as a regular codex32 string is limited to 93 data characters and a long codex32 string is at least 96 characters. Generation of long shares and recovery of the master seed from long shares proceeds in exactly the same way as for regular shares with the <code>ms32_interpolate</code> function. The long checksum is designed to be an error correcting code that can correct up to 4 character substitutions, up to 8 unreadable characters (called erasures), or up to 15 consecutive erasures. As with regular checksums we do not specify how an implementation should implement error correction, and all our recommendations for error correction of regular codex32 strings also apply to long codex32 strings. ==Rationale== This scheme is based on the observation that the Lagrange interpolation of valid codewords in a BCH code will always be a valid codeword. This means that derived shares will always have valid checksum, and a sufficient threshold of shares with valid checksums will derive a secret with a valid checksum. The header system is also compatible with Lagrange interpolation, meaning all derived shares will have the same identifier and will have the appropriate share index. This fact allows the header data to be covered by the checksum. The checksum size and identifier size have been chosen so that the encoding of 128-bit seeds and shares fit within 48 characters. This is a standard size for many common seed storage formats, which has been popularized by the 12 four-letter word format of the BIP-0039 mnemonic. The 13 character checksum is adequate to correct 4 errors in up to 93 characters (80 characters of data and 13 characters of the checksum). This is somewhat better quality than the checksum used in SLIP-0039. For 256-bit seeds and shares our strings are 74 characters, which fits into the 96 character format of the 24 four-letter word format of the BIP-0039 mnemonic, with plenty of room to spare. A longer checksum is needed to support up to 512-bit seeds, the longest seed length specified in BIP-0032, as the 13 character checksum isn't adequate for more than 80 data characters. While we could use the 15 character checksum for both cases, we prefer to keep the strings as short as possible for the more common cases of 128-bit and 256-bit master seeds. We only guarantee to correct 4 characters no matter how long the string is. Longer strings mean more chances for transcription errors, so shorter strings are better. The longest data part using the regular 13 character checksum is 93 characters and corresponds to a 400-bit secret. At this length, the prefix <code>MS1</code> is not covered by the checksum. This is acceptable because the checksum scheme itself requires you to know that the <code>MS1</code> prefix is being used in the first place. If the prefix is damaged and a user is guessing that the data might be using this scheme, then the user can enter the available data explicitly using the suspected <code>MS1</code> prefix. ==Backwards Compatibility== codex32 is an alternative to BIP-0039 and SLIP-0039. It is technically possible to derive the BIP32 master seed from seed words encoded in one of these schemes, and then to encode this seed in codex32. For BIP-0039 this process is irreversible, since it involves hashing the original words. Furthermore, the resulting seed will be 512 bits long, which may be too large to be safely and conveniently handled. SLIP-0039 seed words can be reversibly converted to master seeds, so it is possible to interconvert between SLIP-0039 and codex32. However, SLIP-0039 '''shares''' cannot be converted to codex32 shares because the two schemes use a different underlying field. The authors of this BIP do not recommend interconversion. Instead, users who wish to switch to codex32 should generate a fresh seed and sweep their coins. ==Reference Implementation== * [https://secretcodex32.com/docs/2023-02-14--bw.ps Reference PostScript Implementation] * FIXME add Python implementation * FIXME add Rust implementation ==Test Vectors== ===Test vector 1=== This example shows the codex32 format, when used without splitting the secret into any shares. The data part contains 26 Bech32 characters, which corresponds to 130 bits. We truncate the last two bits in order to obtain a 128-bit master seed. codex32 secret (Bech32): <code>ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw</code> Master secret (hex): <code>318c6318c6318c6318c6318c6318c631</code> * human-readable part: <code>ms</code> * separator: <code>1</code> * k value: <code>0</code> (no secret splitting) * identifier: <code>test</code> * share index: <code>s</code> (the secret) * data: <code>xxxxxxxxxxxxxxxxxxxxxxxxxx</code> * checksum: <code>4nzvca9cmczlw</code> ===Test vector 2=== This example shows generating a new master seed using "random" codex32 shares, as well as deriving an additional codex32 share, using ''k''=2 and an identifier of <code>NAME</code>. Although codex32 strings are canonically all lowercase, it's also valid to use all uppercase. Share with index <code>A</code>: <code>MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM</code> Share with index <code>C</code>: <code>MS12NAMECACDEFGHJKLMNPQRSTUVWXYZ023FTR2GDZMPY6PN</code> * Derived share with index <code>D</code>: <code>MS12NAMEDLL4F8JLH4E5VDVULDLFXU2JHDNLSM97XVENRXEG</code> * Secret share with index <code>S</code>: <code>MS12NAMES6XQGUZTTXKEQNJSJZV4JV3NZ5K3KWGSPHUH6EVW</code> * Master secret (hex): <code>d1808e096b35b209ca12132b264662a5</code> Note that per BIP-0173, the lowercase form is used when determining a character's value for checksum purposes. In particular, given an all uppercase codex32 string, we still use lowercase <code>ms</code> as the human-readable part during checksum construction. ===Test vector 3=== This example shows splitting an existing 128-bit master seed into "random" codex32 shares, using ''k''=3 and an identifier of <code>cash</code>. We appended two zero bits in order to obtain 26 Bech32 characters (130 bits of data) from the 128-bit master seed. Master secret (hex): <code>ffeeddccbbaa99887766554433221100</code> Secret share with index <code>s</code>: <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code> Share with index <code>a</code>: <code>ms13casha320zyxwvutsrqpnmlkjhgfedca2a8d0zehn8a0t</code> Share with index <code>c</code>: <code>ms13cashcacdefghjklmnpqrstuvwxyz023949xq35my48dr</code> * Derived share with index <code>d</code>: <code>ms13cashd0wsedstcdcts64cd7wvy4m90lm28w4ffupqs7rm</code> * Derived share with index <code>e</code>: <code>ms13casheekgpemxzshcrmqhaydlp6yhms3ws7320xyxsar9</code> * Derived share with index <code>f</code>: <code>ms13cashf8jh6sdrkpyrsp5ut94pj8ktehhw2hfvyrj48704</code> Any three of the five shares among <code>acdef</code> can be used to recover the secret. Note that the choice to append two zero bits was arbitrary, and any of the following four secret shares would have been valid choices. However, each choice would have resulted in a different set of derived shares. * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qpte35dvzkjpt0r</code> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qzfatvdwq5692k6</code> * <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qrsx6ydhed97jx2</code> ===Test vector 4=== This example shows converting a 256-bit secret into a codex32 secret, without splitting the secret into any shares. We appended four zero bits in order to obtain 52 Bech32 characters (260 bits of data) from the 256-bit secret. 256-bit secret (hex): <code>ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100</code> * codex32 secret: <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code> Note that the choice to append four zero bits was arbitrary, and any of the following sixteen codex32 secrets would have been valid: * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqpj82dp34u6lqtd</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqzsrs4pnh7jmpj5</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqrfcpap2w8dqezy</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqy5tdvphn6znrf0</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq9dsuypw2ragmel</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqx05xupvgp4v6qx</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq8k0h5p43c2hzsk</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqgum7hplmjtr8ks</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqf9q0lpxzt5clxq</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq28y48pyqfuu7le</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqt7ly0paesr8x0f</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqvrvg7pqydv5uyz</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqd6hekpea5n0y5j</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqwcnrwpmlkmt9dt</code> * <code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq0pgjxpzx0ysaam</code> ===Test vector 5=== This example shows generating a new 512-bit master seed using "random" codex32 characters and appending a checksum. The payload contains 103 Bech32 characters, which corresponds to 515 bits. The last three bits are discarded when converting to a 512-bit master seed. This is an example of a '''Long codex32 String'''. * Secret share with index <code>S</code>: <code>MS100C8VSM32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06FHPV80UNDVARHRAK</code> * Master secret (hex): <code>dc5423251cb87175ff8110c8531d0952d8d73e1194e95b5f19d6f9df7c01111104c9baecdfea8cccc677fb9ddc8aec5553b86e528bcadfdcc201c17c638c47e9</code> ==Appendix== ===Mathematical Companion=== Below we use the Bech32 character set to denote values in GF[32]. In Bech32, the letter <code>Q</code> denotes zero and the letter <code>P</code> denotes one. The digits <code>0</code> and <code>2</code> through <code>9</code> do ''not'' denote their numeric values. They are simply elements of GF[32]. The generating polynomial for our BCH code is as follows. We extend GF[32] to GF[1024] by adjoining a primitive cube root of unity, <code>ζ</code>, satisfying <code>ζ^2 = ζ + P</code>. We select <code>β := G ζ</code> which has order 93, and construct the product <code>(x - β^i)</code> for <code>i</code> in <code>{17, 20, 46, 49, 52, 77, 78, 79, 80, 81, 82, 83, 84}</code>. The resulting polynomial is our generating polynomial for our 13 character checksum: x^13 + E x^12 + M x^11 + 3 x^10 + G x^9 + Q x^8 + E x^7 + E x^6 + E x^5 + L x^4 + M x^3 + C x^2 + S x + S For our long checksum, we select <code>γ := E + X ζ</code>, which has order 1023, and construct the product <code>(x - γ^i)</code> for <code>i</code> in <code>{32, 64, 96, 895, 927, 959, 991, 1019, 1020, 1021, 1022, 1023, 1024, 1025, 1026}</code>. The resulting polynomial is our generating polynomial for our 15 character checksum for long strings: x^15 + 0 x^14 + 2 x^13 + E x^12 + 6 x^11 + F x^10 + E x^9 + 4 x^8 + X x^7 + H x^6 + 4 x^5 + X x^4 + 9 x^3 + K x^2 + Y x^1 + H (Reminder: the character <code>0</code> does ''not'' denote the zero of the field.) -----END BIP-----

1 3

Fwd: A New Era of Tech for Social Good
by Karl Semich 16 Feb '23

16 Feb '23

point #1 below was the point of everything. not there yet but so gratifying. the problem was that things were too poorly known about for people to take and sustain action. that has likely changed! [/crazy] ---------- Forwarded message ---------- From: Center for Humane Technology <hello(a)humanetech.com> Date: Thu, 16 Feb 2023 16:16:13 +0000 Subject: A New Era of Tech for Social Good To: 0xloem(a)gmail.com And how you can join our kick off event for pro-social technology subscribe (https://www.humanetech.com/join?utm_source=Movement+for+Humane+Technology&u…) | view as a webpage (https://mailchi.mp/humanetech.com/designing-tech-for-social-cohesion?e=c78f…) THURSDAY, FEBRUARY 16, 2023 The Catalyst Our newsletter explores technology, human behavior, ethics, and systems reform. Did someone forward you this email? Sign up here (https://www.humanetech.com/join?utm_source=Movement+for+Humane+Technology&u…) . First: An excerpt of a piece written by the co-founders of the newly launched Council for Tech and Social Cohesion (https://techandsocialcohesion.org/?utm_source=Movement+for+Humane+Technolog…) . Then: A new Your Undivided Attention (https://www.humanetech.com/podcast/the-race-to-cooperation-with-david-sloan…) podcast episode that explores conscious evolution. https://www.eventbrite.com/e/designing-tech-for-social-cohesion-tickets-473… ** The Promise of Designing Tech for Social Cohesion ------------------------------------------------------------ By Tristan Harris, Co-founder of the Center for Humane Technology, Shamil Idriss, CEO of Search for Common Ground, and Lisa Schirch, Professor of the Practice, University of Notre Dame The attention-based economy yields platforms that hurt us and make collaborative problem-solving increasingly impossible. Over the past few years, the externalities of this business model have become even more pronounced with the global rise in toxic polarization. The cracks in the foundation of this attention economy open a real opportunity to build platforms that are both better for all of us and profitable over the long run. Digital tools can support democracy and social cohesion. In order to do so, we need a new conversation on how the design of digital platforms can help us depolarize and find a way forward. What if more computer engineers designed digital platforms with the goal of increasing human dignity, emphasizing shared values, and building bridges between polarized groups? What if more platforms optimized their algorithms and business models to find common ground between groups in conflict, or incentivized pro-social behaviors like asking questions or listening to diverse points of view? These are the questions that motivated the three of us (Tristan Harris, Shamil Idriss, and Lisa Schirch) to join forces to establish the Council on Technology and Social Cohesion (https://techandsocialcohesion.org/?utm_source=Movement+for+Humane+Technolog…) . We represent a broad coalition of leaders from the technology, bridge-building movement, and peacebuilding field motivated to encourage products designed to create shared understanding – rather than outrage and division. ** DESIGNING TECH FOR SOCIAL COHESION LAUNCH EVENT ------------------------------------------------------------ Next week, from February 23-25, we’re hosting a conference called “Designing Tech for Social Cohesion (https://www.eventbrite.com/e/designing-tech-for-social-cohesion-tickets-473…) ” in San Francisco to bring together practitioners and tech innovators and explore how innovative new digital platforms are enabling civic action, bridge-building, and enhancing movements for human dignity. The Council shares the belief that tech products can measurably decrease polarization and increase social cohesion, and we want to show the world how that’s possible. Here are three places we can start: 1. Tech developers must learn from peacebuilders and bridgebuilders who have spent decades helping societies remain cohesive in the face of conflict and increasing diversity. 2. Large tech platforms need to learn from the innovation of smaller start-ups that are already building platforms that support social cohesion. For example, Remesh has helped United Nations peacebuilding efforts (https://www.washingtonpost.com/technology/2021/04/23/ai-un-peacekeeping/?ut…) in Libya and Yemen, while Polis has assisted the government of Taiwan (https://www.theguardian.com/world/2020/sep/27/taiwan-civic-hackers-polis-co…) reach solutions in more than 30 public policy issues. 3. Policymakers must incentivize the development of technology for social cohesion. They should provide public grants for innovation and step up their regulation of tech to not only discourage and penalize products that amplify polarization but also reward products that amplify social cohesion. This better version of technology that we envision – one that makes design choices for the social good rather than for short-term profits at the expense of humanity – can be reality. It's a reality we're committed to, and we welcome all in the tech industry and beyond to join us in building this future together. Learn more and register for Designing Tech for Social Cohesion (https://www.eventbrite.com/e/designing-tech-for-social-cohesion-tickets-473…) . For those that can't join us in person, the event will be live-streamed on Search for Common Ground's YouTube (https://www.youtube.com/@SearchforCommonGroundHQ?utm_source=Movement+for+Hu…) . JOIN US AT THE LAUNCH EVENT (https://www.eventbrite.com/e/designing-tech-for-social-cohesion-tickets-473…) ** ABOUT THE COUNCIL ON TECH AND SOCIAL COHESION ------------------------------------------------------------ The Council facilitates collaboration between tech sector leaders eager to improve the impact of technology platforms on social cohesion, and peacebuilders eager to better leverage the innovation and scale of the tech sector. This is a collaboration between Center for Humane Technology (https://www.humanetech.com/?utm_source=Movement+for+Humane+Technology&utm_c…) , Search for Common Ground (https://www.sfcg.org/?utm_source=Movement+for+Humane+Technology&utm_campaig…) , Toda Peace Institute (https://toda.org/?utm_source=Movement+for+Humane+Technology&utm_campaign=8c…) , Braver Angels (https://braverangels.org/?utm_source=Movement+for+Humane+Technology&utm_cam…) , More in Common (https://www.moreincommon.com/?utm_source=Movement+for+Humane+Technology&utm…) , the University of Notre Dame (https://www.nd.edu/?utm_source=Movement+for+Humane+Technology&utm_campaign=…) , Civic Health Project (https://www.civichealthproject.org/?utm_source=Movement+for+Humane+Technolo…) , and the Alliance for Peacebuilding (https://www.allianceforpeacebuilding.org/?utm_source=Movement+for+Humane+Te…) . ** PODCAST EPISODE: The Race to Cooperation ------------------------------------------------------------ Could our world focus on cooperation instead of competition? In our latest (https://www.humanetech.com/podcast/the-race-to-cooperation-with-david-sloan…) Your Undivided Attention, we speak with evolutionary theorist, author, and professor David Sloan Wilson about his work documenting where an enlightened game – one of cooperation rather than competition – is possible. https://www.humanetech.com/who-we-are?utm_source=Movement+for+Humane+Techno… In 2022, our team worked together to impact runaway technology through consumer awareness, legislation, litigation, and insider and technologist activation. See the full report to learn about our work. (https://www.humanetech.com/who-we-are?utm_source=Movement+for+Humane+Techno…) ** CALL FOR TIKTOK RABBIT HOLE STORIES ------------------------------------------------------------ Have you, or one of your loved ones, tumbled down a rabbit hole on TikTok? Bloomberg Businessweek reporter Olivia Carville wants to talk to users of the app who have experienced the dark side of filter bubbles. She’s writing a magazine feature on the harmful consequences of filter bubbles and wants to hear real human stories. Read some of her previous work on TikTok's viral challenges (https://www.bloomberg.com/news/features/2022-11-30/is-tiktok-responsible-if…) and complex content moderation situations (https://www.bloomberg.com/news/features/2022-12-12/-teentok-influencers-tes…) . Reach out to Olivia here: ocarville1(a)bloomberg.net (mailto:ocarville1@bloomberg.net) . We thank you for participating in this movement. - The CHT Team ============================================================ ** Twitter (https://twitter.com/humanetech_?utm_source=Movement+for+Humane+Technology&u…) ** LinkedIn (https://www.linkedin.com/company/the-center-for-humane-technology?utm_sourc…) ** Facebook (https://www.facebook.com/humanetechnology?utm_source=Movement+for+Humane+Te…) ** YouTube (https://www.youtube.com/channel/UCFECM-p3CF81Tp_l2sJsiyg?utm_source=Movemen…) ** Website (https://www.humanetech.com/?utm_source=Movement+for+Humane+Technology&utm_c…) Copyright © 2023 Center for Humane Technology, All rights reserved. You are receiving this email because you opted in to stay updated about news, actions and community events related to the Center for Humane Technology. Our mailing address is: Center for Humane Technology 77 Van Ness Ave Ste 101-1601 San Francisco, CA 94102-6041 USA We respect your right to privacy—** view our policy (https://www.humanetech.com/privacy-policy?utm_source=Movement+for+Humane+Te…) Want to change how you receive these emails? You can ** update your preferences (https://humanetech.us14.list-manage.com/profile?u=3d7bd9c46b50614ffd2c11c51…) or ** unsubscribe from this list (https://humanetech.us14.list-manage.com/unsubscribe?u=3d7bd9c46b50614ffd2c1…) .

1 0