- cypherpunks - lists.cpunks.org

Kraken campaign succeeds!
by coderman 02 Dec '21

02 Dec '21

https://www.crowdsupply.com/krakenrf/krakensdr/updates/kraken-campaign-succ… [Kraken campaign succeeds!](https://www.crowdsupply.com/krakenrf/krakensdr/updates/kraken-ca… by KrakenRF Inc [View previous update](https://www.crowdsupply.com/krakenrf/krakensdr/updates/eu-orders-so… Thank you to everyone who has backed or been following this project. The initial funding campaign has now concluded with almost 5x our minimum funding goal! If you missed out, please don’t worry as the product will still be available for sale on Crowd Supply at the campaign price, though later orders may receive units from the second batch produced a few months after the first. Thanks to the successful funding campaign, we now have all the required parts on order and we expect the factory to receive them in a few weeks time. The final confirmation prototype is in production now, finishing touches to the enclosure are being worked on, a QC process is being developed, and EU compliance certification and logistics details are being worked through. At the same time, work on on the DFing software is continuing to progress as well. If you are testing the software with the older KerberosSDR units, please note the software is still in beta and a thorough reading of the documentation is required to understand the DAQ control parameters. As direction finding with an SDR can involve learning a lot of new technical information, we are aiming to significantly simply the knowledge needed to understand the DAQ parameters, and we hope to have a simplified version released with a tutorial by mid-December. So if you have a Kerberos, and are struggling with the setup, please kindly wait until the official release, (unless you are interested in learning all the nitty gritty technical details). Recently, we have also been working on improvements to the intermittent signal squelch handling and we are also working on multichannel DFing capabilities. We have a new developer starting work on a multi-platform networked mapping program too. We are also looking to sponsor some accelerator projects such a GNU Radio integration and beam-forming investigations for applications like radio astronomy. If you have DSP programming skills and you’re interested in helping on this, or you have the DSP skills and interest in developing another project, please email us at thekraken(a)krakenrf.com with details. :P

3 2

Spanish Lesson
by Punk-BatSoup-Stasi 2.0 02 Dec '21

02 Dec '21

Esta no es una lista de correo, es una lista de soretes de mierda. La lista incluye soretes como bigbrother, bell, la cosa del pentagono, y 'coderman', los cuatros soretes supremos y heroicos luchadores contra la peste imaginaria.

2 1

An Illustrated Guide to Elliptic Curve Cryptography Validation
by coderman 01 Dec '21

01 Dec '21

https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-elliptic-c… [Paul Bottinelli](https://research.nccgroup.com/author/pbottine/) [Cryptography](https://research.nccgroup.com/category/cryptography/), [Research](https://research.nccgroup.com/category/research/), [Tutorial/Study Guide](https://research.nccgroup.com/category/tutorial-study-guide/) November 18, 2021 12 Minutes Elliptic Curve Cryptography (ECC) has become the de facto standard for protecting modern communications. ECC is widely used to perform asymmetric cryptography operations, such as to establish shared secrets or for digital signatures. However, insufficient validation of public keys and parameters is still a frequent cause of confusion, leading to serious vulnerabilities, such as leakage of secret keys, signature malleability or interoperability issues. The purpose of this blog post is to provide an illustrated description of the typical failures related to elliptic curve validation and how to avoid them in a clear and accessible way. Even though a number of standards[1](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-… mandate these checks, implementations frequently fail to perform them. While this blog post describes some of the necessary concepts behind elliptic curve arithmetic and cryptographic protocols, it does not cover elliptic curve cryptography in detail, which has already been done extensively. The following blog posts are good resources on the topic: [A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography](https://blog.cloudflare.com/a-relatively-easy-to-understand-p… by Nick Sullivan and [Elliptic Curve Cryptography: a gentle introduction](https://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/) by Andrea Corbellini. In elliptic curve cryptography, public keys are frequently sent between parties, for example to establish shared secrets using [Elliptic curve Diffie–Hellman (ECDH)](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) The goal of public key validation is to ensure that keys are legitimate (by providing assurance that there is an existing, associated private key) and to circumvent attacks leading to the leakage of some information about the private key of a legitimate user. Issues related to public key validation seem to routinely occur in two general areas. First, transmitting public keys using digital communication requires to convert them to bytes. However, converting these bytes back to an elliptic curve point is a common source of issues, notably due to [canonicalization](https://en.wikipedia.org/wiki/Canonicalization). Second, once public keys have been decoded, some mathematical subtleties of the elliptic curve operations may also lead to different types of attacks. We will discuss these subtleties in the remainder of this blog post. TL;DR In general[3](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to…, vulnerabilities may arise when applications fail to check that: - The point coordinates are lower than the field modulus. - The coordinates correspond to a valid curve point. - The point is not the point at infinity. - The point is in the correct subgroup. An Illustrated Guide to Validating ECC Curve Points Elliptic curves are curves given by an equation of the form [y^2 = x^3 + ax + b] (called short Weierstrass form). Elliptic curve cryptography deals with the group of points on that elliptic curve, namely, a set of [(x, y)] values satisfying the curve equation. These values, called coordinates (more specifically, affine coordinates), are defined over a field. For use in Cryptography, we work with coordinates defined over a finite field. For the purpose of this blog post, we will concentrate our efforts on the field of integers modulo [p], with [p] a prime number (and [p > 3]), which we call the field modulus. Elements of this field can take any value between and [p - 1] . In the following figure, the white squares depict valid field elements while grey squares represent the elements that are larger than the field modulus. Mathematically, a value larger than the field modulus is equivalent to its reduced form (that is, in the to [p-1] range, see [congruence classes](https://en.wikipedia.org/wiki/Modular_arithmetic#Congruence_classe…) but in practice these ambiguities may lead to complex issues[4](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-…. In ECC, a public key is simply a point on the curve. Since curve points are generally first encoded to byte arrays before being transmitted, the first step when receiving an encoded curve point is to decode it. This is what we identified earlier as the first area of confusion and potential source of vulnerabilities. Specifically, what happens when the integer representation of the coordinates we decoded are larger than the field modulus? This is the first common source of issues and the reason for our first validation rules: > Check that the point coordinates are lower than the field modulus. What can go wrong? If the recipient does not enforce that coordinates are lower than the field modulus, some elliptic curve point operations may be incorrectly computed. Additionally, different implementations may have diverging interpretations of the validity of a point, possibly leading to interoperability issues, which can be a critical issue in consensus-driven deployments. In the figure below, this means that the point coordinates should be rejected if they are not in the white area in the bi-dimensional plane. Since both coordinates are elements of this finite field, it might seem that an elliptic curve point could theoretically take any value in the white area above. However, not all pairs of [(x, y)] values in this plane are valid curve points; remember that they need to satisfy the curve equation [y^2 = x^3 + ax + b] in order to be on the curve. We represent the valid curve point in blue in the figure below[5](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-e…. The number of points on the curve is referred to as the curve order. This is another common source of issues and where our second validation rule arises: > Check that the point coordinates correspond to a valid curve point (i.e. that the coordinates satisfy the curve equation). What can go wrong? If the recipient of a public key fails to verify that the point is on the curve, an attacker may be able to perform a so-called invalid curve attack[6](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-…. Some point operations being independent of the value of [b] in the elliptic curve equation, a malicious peer may carefully select a different curve (by varying the value of [b]) in which the security is reduced (namely, the discrete logarithm problem is easier than on the original curve). By then sending a point on that new curve (and provided the legitimate peer fails to verify that the point coordinates satisfy the curve equation), the attacker may eventually recover the legitimate peer’s secret. In practice, curve points are rarely sent as pairs of coordinates, which we call uncompressed. Indeed, the [y]-coordinate can be recovered by solving the curve equation for a given [x], which is why point compression was developed. Point compression reduces the amount of data to be transmitted by (almost) half, at the cost of a few more operations necessary to solve the curve equation. However, solving the equation for a given [x] may have different outcomes. It can either result in: - no solutions (in case [y^2] does not have a square root in the field, i.e. is not a quadratic residue), in which case the point should be rejected; or - two solutions, [(x, y)] and [(x, -y)], due to the fact that [y^2 = (-y)^2]. However, all coordinates must lie in the [0 \ldots p-1] range, which are all positive numbers. Since we’re working in the field of integers modulo [p], that negative [y]-coordinate is actually equivalent to the field element [p - y], which lies in the correct range. Hence, when compressing a point, an additional byte of data is used to distinguish the correct [y]-coordinate. Specifically, point encoding (following Section 2.3.3 of [SEC 1](https://www.secg.org/sec1-v2.pdf), works by prepending a byte to the coordinate(s) specifying which encoding rule is used, as follows: - Compressed point: 0x02 || x if y is even and 0x03 || x if y is odd; - Uncompressed point: 0x04 || x || y.[7](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-elli… Any other value for the first byte should result in the curve point being ignored. Point compression has a significant benefit in that it ensures that the point is on the curve, since in case there is no solution, implementation should reject the point. Now, the careful reader may have realized that the set of points in the figure above is incomplete. In order for this set to form a group (in the [mathematical sense](https://en.wikipedia.org/wiki/Group_(mathematics))) and be useful in cryptography, it needs to be supplemented with an additional element, the point at infinity. This point, also called neutral element or additive identity, is the element [\mathcal{O}] such that for any point [P] on our elliptic curve, [P + \mathcal{O} = \mathcal{O} + P = P]. The figure below shows the previous set of points on our arbitrary curve with the addition of the point at infinity, which we (artificially) positioned slightly outside our plane, in the bottom left corner. Since the point at infinity is not on the curve, it does not have well-defined [x] and [y] coordinates like other curve points. As such, its representation had to be constructed artificially[8](https://research.nccgroup.com/2021/11/18/an-illustrated-gui…. Standards (such as [SEC 1: Elliptic Curve Cryptography](https://www.secg.org/sec1-v2.pdf)) define the encoding of the point at infinity to be a single octet of value zero. Confusingly, implementations sometimes also use other encodings for the point at infinity, such as a number of zero bytes equal to the size of the coordinates. Implementations sometimes fail to properly distinguish the point at infinity, and this is where our third validation rule comes from: > Check that the point is not the point at infinity. What can go wrong? Since multiplying the point at infinity by any scalar results in the point at infinity, an adversary may force the result of a key agreement to be zero if the legitimate recipient fails to check that the point received is not the point at infinity. This goes against the principle of contributory behavior, where some protocols require that both parties contribute to the outcome of an operation such as a key exchange. Failure to enforce this check may have additional negative consequences in other protocols. Recall that the curve order, say [N], corresponds to the number of points on the curve. To make matters more complicated, the group of points on an elliptic curve may be further divided into multiple subgroups. [Lagrange’s theorem](https://en.wikipedia.org/wiki/Lagrange%27s_theorem_(group_theory)) tells us that any subgroup of the group of points on the elliptic curve has an order dividing the order of the original group. Namely, the size (i.e. the number of points) of every subgroup divides the total number of points on the curve. In cryptography, to ensure that the discrete logarithm problem is hard, curves are selected in such a way that they consist of one subgroup with large, prime order, say [n], in which all computations are performed. Some curves (such as the NIST curves[9](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-…, or the curve secp256k1[10](https://research.nccgroup.com/2021/11/18/an-illustrated-guide… used in bitcoin) were carefully designed such that [n = N], namely the prime order group in which we perform operations is the full group of points on the elliptic curve. In contrast, the popular Curve25519 has curve order [N = 8n], which means that points on this curve can belong to the large prime-order subgroup of size [n], or to a subgroup with a much smaller order, of size 2, 4 or 8, for example[11](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-t…. The value [h] such that [h = N/n] is called the cofactor, it can be thought of as the ratio between the total number of points on the curve and the size of the prime-order subgroup in which cryptographic operations are performed. To illustrate this notion, consider the figure below in which we have further subdivided our fictitious set of elliptic curve points into two groups. When performing operations on elliptic curve points, we want to stick with operations on points in the larger, prime-order subgroup, identified by the blue points below. And this is where our last validation rule comes from: > Check that the point is in the correct subgroup. This can be achieved by checking that [nP = \mathcal{O}]. Indeed, a consequence of Lagrange’s theorem is that any group element multiplied by the order of that group is equal to the neutral element. If [P] were in the small subgroup, multiplying it by [n] would not equal [\mathcal{O}]. This highlights another possible method for checking that the point belongs to the correct subgroup; one could also check that [hP \neq \mathcal{O}]. Contrary to the previous validation rules, this check is considerably more expensive since it requires a point multiplication, and as such is sometimes (detrimentally) skipped for efficiency purposes. What can go wrong? A malicious party sending a point in the orange subgroup, for example as part of an ECDH key agreement protocol, would result in the honest party performing operations limited to that small subgroup. Thus, if the recipient of a public key failed to check that the point was in the correct subgroup, the attacker could perform a so-called small subgroup attack (also known as subgroup confinement attacks) and learn information about the legitimate party’s private key[12](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-el…. Does that apply to all curves? While the presentation above is fairly generic and applies in a general sense to all curves, some curves and associated constructions were created to prevent some of these issues by design. NIST curves (e.g. P-256) and the Bitcoin curve (secp256k1) These curves have a cofactor value of 1 (namely, [h = 1]). As such, there is only one large subgroup of prime order and all curve points belong to that group. Hence, once the first 3 steps in our validation procedure have been performed, the last step is superfluous. Curve25519 Curve25519, proposed by Daniel J. Bernstein and specified in [RFC 7748](https://datatracker.ietf.org/doc/html/rfc7748), is a popular curve which is notably used in TLS 1.3 for key agreement. Although Curve25519 has a cofactor of 8, some functions using this curve were designed to prevent cofactor-related issues. For example, the X25519 function used to perform key agreement using Curve25519 mandates specific checks and performs key agreement using only [x]-coordinates, such that invalid curve attacks are avoided. Additionally, the governing RFC states in [Section 5](https://datatracker.ietf.org/doc/html/rfc7748#section-5) that > Implementations MUST accept non-canonical values and process them as if they had been reduced modulo the field prime. The non-canonical values are 2^255 – 19 through 2^255 – 1 for X25519. This seems to address most issues discussed in this post. However, there has been some debate[13](https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to… over the claimed optional nature of these checks. With the popularity of Curve25519 and the desire for cryptographers to design more exotic protocols with it, the cofactor value of 8 resurfaced as a potential source of problems. [Ristretto](https://ristretto.group/) was designed as a solution to the cofactor pitfalls. Ristretto is an abstraction layer, on top of Curve25519, which essentially restricts curve points to a prime-order subgroup. Double-Odd Elliptic Curves Finally, a strong contender in the secure-by-design curve category is the [Double-Odd](https://doubleodd.group/) family of elliptic curves, recently proposed by Thomas Pornin. These curves specify a strict and economical encoding, preventing issues with canonicalization and, even though their cofactor is not trivial, a prime order group is defined on them, similar in spirit to Ristretto’s approach, preventing subgroup confinement attacks. Conclusion With the ubiquitous use of elliptic curve cryptography, failure to validate elliptic curve points can be a critical issue which is sadly still commonly uncovered during cryptography reviews. While standards and academic publications provide ample directions to correctly validate curve points, implementations still frequently fail to follow these steps. For example, a vulnerability nicknamed [Curveball](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0… was reported in January 2020, which allowed attacker to perform spoofing attacks in Microsoft Windows by crafting public points. Recently, we also uncovered a critical vulnerability in a number of open-source ECDSA libraries, in which the verification function failed to check that the signature was non-zero, allowing attackers to forge signatures on arbitrary messages, see the technical advisory [Arbitrary Signature Forgery in Stark Bank ECDSA Libraries](https://research.nccgroup.com/2021/11/08/technical-advisory-arbi…. This illustrated guide will hopefully serve as an accessible reference on why and how point validation should be performed. Thank you The author would like to thank Eric Schorn and Giacomo Pope for their detailed review and helpful feedback. --------------------------------------------------------------- References - [Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography](https://www.secg.org/sec1-v2.pdf), Section 3.2.2.1 Elliptic Curve Public Key Validation Primitive. - [NIST Special Publication 800-56A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-…, Section 5.6.2.3.2 FFC Partial Public-Key Validation Routine and 5.6.2.3.3 ECC Full Public-Key Validation Routine. - That is, unless using an elliptic curve that was designed specifically to address these potential issues, we will come back to that at the end of this blog post. - Specifically, implementations may handle values that are larger than the field modulus in different ways. They may reject non-reduced values (i.e., non-canonical encodings), accept non-reduced values and reduce them modulo the prime order, or accept non-reduced values and discard the most significant bit(s). An interesting example happened with the cryptocurrency Zcash, where different implementations had distinct interpretations regarding the validity of curve points. Some details can be found in a [blog post](https://hdevalence.ca/blog/2020-10-04-its-25519am) by Henry de Valence, as well as in a public report following a [cryptography review](https://research.nccgroup.com/wp-content/uploads/2020/09/NCC_Group_… performed by NCC Group. - Note that this figure does not represent an actual elliptic curve; it is just an arbitrary diagram designed for illustrative purposes. - Ingrid Biehl, Bernd Meyer and Volker Müller. “Differential Fault Attacks on Elliptic Curve Cryptosystems”. In: Advances in Cryptology – CRYPTO 2000, 20th Annual International Cryptology Conference, Santa Barbara, California, USA, August 20-24, 2000, Proceedings. 2000, pp. 131–146. - Note that there is a hybrid form starting in 0x06 defined in [ANSI X9.62](https://standards.globalspec.com/std/1955141/ANSI%20X9.62), but this format is very rarely used in practice. - Note that some curves and alternate point representations (for instance, when working in projective coordinates) may allow the point at infinity to have a well-defined representation. - Standardized in [FIPS PUB 186-4: Digital Signature Standard (DSS)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf) - Standardized in [SEC 2: Recommended Elliptic Curve Domain Parameters](http://www.secg.org/sec2-v2.pdf). - The paper [Taming the many EdDSAs](https://eprint.iacr.org/2020/1244.pdf) provides some very interesting discussions around ambiguities in the Ed25519 signature verification equations (which is based on Curve25519). These ambiguities led to different interpretations of the validity of signatures, which resulted in implementations returning different validity results for some signatures, which could be critical in consensus-driven applications. - Chae Hoon Lim and Pil Joong Lee. “A Key Recovery Attack on Discrete Log-based Schemes Using a Prime Order Subgroup”. In: Advances in Cryptology – CRYPTO ’97, 17th Annual International Cryptology Conference, Santa Barbara, California, USA, August 17-21, 1997, Proceedings. 1997, pp. 249–263. - See https://moderncrypto.org/mail-archive/curves/2017/000896.html.

1 0

Apple Card and Blockchain Software Technology
by Gunnar Larson 01 Dec '21

01 Dec '21

Apple is a designer and manufacturer of electronic devices and related software and services. Apple Card, created by Apple, is the only card issued by Goldman Sachs. Honestly, communicating with Mr. Dhanani (Apple Senior Machine Learning Engineer:https://www.linkedin.com/in/jdhanani/) has been enjoyable. He is very open and honest, specific to his role with MIA Coin and NYCCoin (email thread below). Mr. Dhanani seems bright and one can only wish him the very best. That being said, what role (if any) does the Apple Card have to do with interlocking directorates and the future of blockchain software technology? Apple was the #1 Harvard Management Company holding as of September 30, 2021: https://whalewisdom.com/filer/harvard-management-co-inc#tabholdings_tab_link Harvard Management Company also holds large positions in Facebook (Meta) and Affirm, sharing common Board Directors at Kiva.org: https://www.kiva.org/about/leadership Since 2014, John D. Muller, Associate General Counsel, Facebook has served on Kiva.org's Board of Directors. John Muller is Head of Legal for Novi Financial, Inc., a subsidiary of Facebook. Novi is building mobile wallet and exchange services for the new Libra blockchain, with an emphasis on making it faster, cheaper, and easier for people to move money safely around the world. Previously, Muller was General Counsel (2000-2013) and Vice President of Payments Policy (2013-2017) for PayPal. He helped PayPal through its regulatory licensing, acquisition by eBay, launch of merchant services and international expansion. PayPal, Facebook and Kiva.org interlocking directorates lead to the Apple Card and Goldman Sachs' Board of Directors ... Specifically to Audit Chair, Mr. Oppenheimer, formerly Apple's CFO: https://www.goldmansachs.com/about-us/people-and-leadership/leadership/boar… What would Steve Jobs say about protecting blockchain software technology from manipulation? Probably something memorable. New York holds such an awesome future. The horizon is bright. -- *Gunnar Larson - xNY.io <http://www.xny.io/> | Bank.org <http://bank.org/>* MSc <https://www.unic.ac.cy/blockchain/msc-digital-currency/?utm_source=Google&u…> - Digital Currency MBA <https://www.unic.ac.cy/business-administration-entrepreneurship-and-innovat…> - Entrepreneurship and Innovation (ip) G(a)xNY.io +1-646-454-9107 New York, New York 10001 ---------- Forwarded message --------- From: Gunnar Larson <g(a)xny.io> Date: Wed, Nov 17, 2021 at 1:35 PM Subject: Re: Mining.NYC To: Jamil Dhanani <jamil.dhanani(a)gmail.com>, <jdhanani(a)apple.com> Jamil: 1. Serotonin.co seems to be running PR for Mining.NYC. Ms. Cassatt is the former CMO of Consensys. Jamil, can you please go back to your team and check to see if there is a relationship with Consensys? 2. Who is the custodial wallet? We were told a firm out of Nebraska? Can you get back to us on this? As you can imagine, it is very important and should be common knowledge. 3. With the Stacks.co and OKCoin.com's relationship with China and/or Hong Kong, how are you and Mining.NYC approaching China's new cross- border Data Security rules <https://www.orrick.com/en/Insights/2021/09/Chinas-New-Data-Security-Law-Wha…>? Is CityCoins planning to send MIA and NYCCoing data back to Beijing as the rules suggest? Sending you the very best regards. Thank you, Gunnar -- *Gunnar Larson - xNY.io <http://www.xny.io/> | Bank.org <http://bank.org/>* MSc <https://www.unic.ac.cy/blockchain/msc-digital-currency/?utm_source=Google&u…> - Digital Currency MBA <https://www.unic.ac.cy/business-administration-entrepreneurship-and-innovat…> - Entrepreneurship and Innovation (ip) G(a)xNY.io +1-646-454-9107 New York, New York 10001 On Wed, Nov 17, 2021 at 1:16 PM Jamil Dhanani <jamil.dhanani(a)gmail.com> wrote: > 1) There’s no relationship to Consensys > 2) I believe the keys are held in a custodial wallet where multiple people > manage the keys, until the city accepts the wallet. > 3) Yes, I was working from the hotel at the time and used that as the > registration address > > Let me know if you have any other questions, but some of these can only be > answered by the CityCoins team. They’re also active on the discord at > chat.citycoins.co > > — Jamil > > On Nov 17, 2021, at 9:52 AM, Gunnar Larson <g(a)xny.io> wrote: > > Hey Jamil: > > Just seeing if you could get back to me on this. > > Thank you, > > Gunnar > > On Sun, Nov 14, 2021, 10:28 PM Gunnar Larson <g(a)xny.io> wrote: > >> Do you use any https://consensys.net/ products or solutions for MIA, >> NYCCoin? >> >> On Sun, Nov 14, 2021, 4:46 PM Jamil Dhanani <jamil.dhanani(a)gmail.com> >> wrote: >> >>> Thanks for the kind words, appreciate it :) >>> >>> And also, the government of New York hasn’t claimed the City Wallet for >>> NYCCoin like Miami has. I’m not sure anyone received the reward for Miami >>> as Patrick’s been in communication with the government directly, to my >>> understanding. >>> >>> Best, >>> — Jamil >>> >>> On Nov 14, 2021, at 9:00 AM, Gunnar Larson <g(a)xny.io> wrote: >>> >>> Jamil: >>> >>> With JoinFreehold.com <http://joinfreehold.com/>, who received the the >>> reward for NYCCoin? >>> >>> Thank you, >>> >>> Gunnar >>> >>> Get mayors to adopt their CityCoin >>> Reward: >>> $25,000 per city >>> Expiration: >>> End of year >>> Supporting a city should be as simple as buying and holding its >>> associated CityCoin. Get cities to #pickupthebag. >>> >>> On Sun, Nov 14, 2021, 1:06 AM Jamil Dhanani <jamil.dhanani(a)gmail.com> >>> wrote: >>> >>>> Patrick Stanley founded CityCoins and is the current community lead, >>>> his Twitter is here: https://twitter.com/PatrickWStanley >>>> <https://twitter.com/PatrickWStanley?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%…> >>>> >>>> As to the funding, I don’t know; I’m actually fairly new to the Stacks >>>> community and wasn’t around when the funding was raised and during the >>>> initial ICO; what do you mean by CN? China? I haven’t seen too many people >>>> from China involved in the CityCoins project; most people I know that are >>>> involved are US-based. >>>> >>>> — Jamil >>>> >>>> Sent from my iPhone >>>> >>>> On Nov 13, 2021, at 9:53 PM, Gunnar Larson <g(a)xny.io> wrote: >>>> >>>> >>>> Jamil: >>>> >>>> Good to know. Thanks for your quick response. >>>> >>>> Do you know who is behind CityCoins.co <http://citycoins.co/>? The >>>> domain is registered out of Iceland :) >>>> >>>> STX has a lot of funding from CN. For crypto, how does that affect >>>> CityCoins.co <http://citycoins.co/>, if at all? >>>> >>>> Thank you, >>>> >>>> Gunnar >>>> >>>> On Sun, Nov 14, 2021, 12:47 AM Jamil Dhanani <jamil.dhanani(a)gmail.com> >>>> wrote: >>>> >>>>> That’s an old domain I used to own, I don’t own it anymore, I need to >>>>> change the registrar info for the new domains I own. I’m not affiliated >>>>> with the current owners/site of caelus.ca >>>>> >>>>> NewYorkCoin is not affiliated with NYCCoin; NYCCoin is part of the >>>>> CityCoins project (https://www.citycoins.co/) I’m not affiliated >>>>> with CityCoins directly but do work on tools around it. >>>>> >>>>> Best, >>>>> — Jamil >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Nov 13, 2021, at 9:44 PM, Gunnar Larson <g(a)xny.io> wrote: >>>>> >>>>> >>>>> Jamil: >>>>> >>>>> Great work. >>>>> >>>>> What is your affiliation (if any) with caelus.ca <j.dhanani(a)caelus.ca> >>>>> ? >>>>> >>>>> What do you think of NewYorkCoin: >>>>> https://coinmarketcap.com/currencies/newyorkcoin/ >>>>> >>>>> NYCCoin is not affiliated with NewYorkCoin (ticker: NYC)? >>>>> >>>>> Looking forward to learning more. >>>>> >>>>> Thank you, >>>>> >>>>> Gunnar >>>>> >>>>> >>>>> On Sun, Nov 14, 2021, 12:35 AM Jamil Dhanani <jamil.dhanani(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Gunnar, >>>>>> >>>>>> That’s right; I run the sites to visualize the mining statistics for >>>>>> NYCCoin (mining.nyc) and MiamiCoin (miamining.com) If you have any >>>>>> questions about them please let me know! >>>>>> >>>>>> Best, >>>>>> — Jamil >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Nov 13, 2021, at 6:21 PM, Gunnar Larson <g(a)xny.io> wrote: >>>>>> >>>>>> >>>>>> Mr. Dhanani: >>>>>> >>>>>> Are you the admin contact for Mining.NYC? >>>>>> >>>>>> Sending you the very best regards. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Gunnar >>>>>> -- >>>>>> *Gunnar Larson - xNY.io <http://www.xny.io/> | Bank.org >>>>>> <http://bank.org/>* >>>>>> MSc >>>>>> <https://www.unic.ac.cy/blockchain/msc-digital-currency/?utm_source=Google&u…> >>>>>> - Digital Currency >>>>>> MBA >>>>>> <https://www.unic.ac.cy/business-administration-entrepreneurship-and-innovat…> >>>>>> - Entrepreneurship and Innovation (ip) >>>>>> >>>>>> G(a)xNY.io >>>>>> +1-646-454-9107 >>>>>> New York, New York 10001 >>>>>> >>>>>>

2 1

Collapse of govts
by professor rat 01 Dec '21

01 Dec '21

https://www.coindesk.com/business/2021/12/01/tim-draper-on-bitcoin-and-the-… Cypherpunks collapse governments. Subject: Everyone a remailer: Everyone a Mint: Everyone an assassin https://marc.info/?l=cypherpunks&m=100872510706876&w=2 Strong-crypto, digital money, anonymous networks, pseudonyms, zero- knowledge proofs, reputations, information-markets, netwar, collapse-of-governments.

1 0

Red Notice
by professor rat 01 Dec '21

01 Dec '21

Great book ( Bill Browder ) reads like a thriller. Red-fascists release biowarfare agent. slate.com Red States Are Now Paying Unemployment Benefits to Anti-Vaxxers Who Quit Their Jobs Republican governors have decided to coddle vaccine refusers, even as they cut benefits for everyone else. saletan - 18h Across the country, Republicans have cut unemployment benefits, claiming that these benefits pay people not to work. Meanwhile, the same Republicans are passing laws that promise unemployment checks to vaccine refusers. It’s socialism for anti-vaxxers.

1 0

Re: GovCorp conspiracy theory fails again
by Stefan Claas 01 Dec '21

01 Dec '21

On Wed, Dec 1, 2021 at 6:51 PM Karl <gmkarl(a)gmail.com> wrote: > > Hi Punk, Stefan. > > Stefan asked me for off-list cryptocurrency investment advice. Sorry Karl I accidentally pushed the wrong button and thank you for your detailed reply! > - if you are a coder there is still a ton of room for automated market > making, which for some reason has not filled the digital economies > yet. same thing if you are into machine transformer models or data > processing pipelines. Yes, I agree, but personally I no longer invest time in this whole cryptocurrency market. Regards Stefan

1 0

The creation of international drug and weapons markets
by professor rat 01 Dec '21

01 Dec '21

“I can tolerate the creation of international drug and weapons markets. But NFTS is where I draw the line.” https://cointelegraph.com/news/imprisoned-silk-road-founder-causes-a-stir-w…

1 0

Trading for CryptoPunks
by professor rat 01 Dec '21

01 Dec '21

FTX US Opens Trading for CryptoPunks, Bored Apes and Other Ethereum NFTs The FTX NFTs marketplace now supports both leading platforms, letting users buy in USD with credit cards and more. https://decrypt.co/87343/ftx-us-solana-ethereum-nfts-cryptopunks-bored-apes el33th4xor - 43m 2/ The iconic ‘Love Is In The Air’ piece from Banksy will be the first art piece bought and distributed by @Collectparticle . The piece will be fractionalized into 10,000 Particles, each sold as NFTs on Avalanche.

1 0

List spam factoids
by professor rat 01 Dec '21

01 Dec '21

https://lists.cpunks.org/pipermail/cypherpunks/ The amount posted here is listed at the end of the month. So, as may be seen, more was posted in Oct this year than last month. November. It may also be noted that as the crypto-anarchist economy takes off there will invariably be more interest in this list. If you can't stand the heat then get out of the kitchen.

1 0