I personally blame the web 2 culture of agile development and sprints. Those practices have their place, but not for security design. In the last 10 years of blockchain development I’ve seen far too much “we’ll fix it when it breaks” mentality.
Another part is that the core blockchain architects (even Satoshi) did not focus on key management issues. They made assumption that those could be addressed by others or solved later. But there are few financial incentives to support wallets once they are MVP.
Nothing in the core Ethereum blockchain & smart contract architecture requires wallets to work the way they do today. Instead, the invisible architecture of the first to get to MVP and out-of-the-way enough to allow early adoption & token sales won.
RT @iang_fc: @ChristopherA @Steve_Lockstep @kimdhamilton @wycdd @chrismessina @Obstropolos @SpruceID @openid @bluesky @willnorris @selfissu…
RT @anguschampion: Thread.
“Move fast break things” is great for product market fit, awful for security. And security is more important th…
RT @Steve_Lockstep: You are sooooooo right.
Security is poorly served by #Agile methods. Security design is a thinking-intensive pencil-an…
RT @dystopiabreaker: it’s deeply funny to me that most of the people actually building the infrastructure (zk research, mpc research, key m…
For some time I’ve talked about interesting legal opportunities for digital identity, assets, and DAOs for indigenous nations around the world, especially those that cross multiple borders. The Catawba Nation has announced a Green Earth economic zone: https://catawbacorps.com/news/the-catawba-general-council-approves-digital-economic-zone-in-catawba-lands/
“similar to Estonia’s eResidency, after completing the ‘know your customer’ (KYC) requirements, anyone in the world will be able to set up an eCorporation online in the GEZ, and take advantage of policies and regulations that allow them to safely manage their digital assets”
I’m looking forward to collaborating with this year’s interns to make for a more open & interoperable, secure & compassionate digital infrastructure for our blockchain ecosystem. https://twitter.com/namcios/status/1499134246748893185
RT @jchervinsky: 1/ Russia can’t & won’t use crypto to evade sanctions.
Concerns about crypto’s use for sanctions evasion are totally unfo…
RT @CERTEU: Since @signalapp may be used to quickly coordinate and exchange information on work-related matters, we have just released a gu…
Replying to @raphacaixeta
Soon, support for recursive zk-proofs using pairing-based Halo will be released in $ZEC. However, it is possible to do these bulletproof style in secp256k1 if you swap the n & p constants (see SecQ: https://github.com/BlockchainCommons/Community/issues/71#issuecomment-410482607 ). Why aren’t secp chains ($BTC & $ETH) supporting this?
Here the authors of Halo report that their work could use secp256k1 https://twitter.com/christophera/status/1171529478108921856?s=21
Replying to @kimdhamilton
I tried as editor of TLS in 90s and was rebuffed “$5k per document please”. I argued (and wish I won) that meant we should drop X.509 support in IETF standards. ISO documents are a bit less expensive now, and you can get people to who do have access to send to you illegally. 👎
RT @SarahJamieLewis: I have very particular preferences that I use to judge software, that might not match your own, namely:
Centralizatio…
Replying to @rafathebuilder
I’ve written extensively about this. Best summary is in this series starting at: http://www.lifewithalacrity.com/2008/09/group-threshold.html
Replying to @sandyIRL, @rafathebuilder and @vanithak
Actually community thresholds are smaller than you might think. A practical Dunbar Number isn’t 150 but half that. See series starting at http://www.lifewithalacrity.com/2008/09/group-threshold.html
Replying to @Callhoun and @rafathebuilder
There is a difference between personal limits & limits to group cohesion: http://www.lifewithalacrity.com/2005/10/dunbar_group_co.html there is also differences in groups online & offline: http://www.lifewithalacrity.com/2009/03/power-laws.html
#til: The Slavic languages have a way of pronouncing Ukraine that either makes it a borderland, like in English “the West” vs. a specific place “Utah”. I can guess which Putin uses. Thus the request for English speakers to drop “the” from Ukraine https://blog.duolingo.com/ukraine-language/
RT @jb55: Here’s lnsocket, a minimal C library for sending messages on the lightning network.
git clone git://jb5…
Blockchain Commons has been building into our architecture support for @TorProjects onion services (what we call TorGap), and even sponsor a Tor exit node. We are quite appreciative of @Twitter now offering correlation resistant access to their service. Hopefully onward to DIDs! https://twitter.com/AlecMuffett/status/1501282223009542151
Replying to @riabhutoria
Our free #SmartCustody PDF book on “the care, maintenance, control, and protection of digital assets” is what you need to read to ensure that you don’t lose your Bitcoin, your Ether, or your self-sovereign identity. Available from @BlockchainComns at http://bit.ly/SmartCustodyBookV101
Replying to @riabhutoria and @BlockchainComns
We are working now toward 2nd edition with multisig scenarios. See our GitHub repo for some work-in-progress on these: https://github.com/BlockchainCommons/SmartCustody
Replying to @riabhutoria and @BlockchainComns
For more details on our plans for the final book, see https://github.com/BlockchainCommons/SmartCustodyBook/blob/master/TODO.md
Is there yet a spec for implementing something like hd-keys for ristretto (i.e. supports both hardened & unhardened derivations)? I keep seeing people naïvely trying to do hd-keys for 25519 not understanding the problem. @zmanian @durumcrustulum @jasonalaw @shea256
Replying to @bascule, @zmanian, @durumcrustulum, @JasonALaw and @shea256
I vaguely recall that @pwuille was uncomfortable with his own BIP-32 contributions to HD-Keys. It has some footguns, and people keep trying to use it in weird ways. In secp he suggested PBKF2 was often better, or sign-to-contract. The latter I know has issues in 25519.
Replying to @bascule, @zmanian, @durumcrustulum, @JasonALaw, @shea256 and @pwuille
I found @pwuille’s original comment from 2015 “just use pay-to-contract derivation … The only reason to use BIP32 is when you need the ability to exhaustively iterate children. If you don’t need that, you can avoid its complication.” https://github.com/WebOfTrustInfo/rwot1-sf/issues/25#issuecomment-152892802
Replying to @bascule, @zmanian, @durumcrustulum, @JasonALaw, @shea256 and @pwuille
Relevant old tweet from @FiloSottile https://twitter.com/FiloSottile/status/1281409041454030848?s=20&t=UeXXc4zoTFzFacpugSVSWg
Replying to @bascule, @zmanian, @durumcrustulum, @JasonALaw, @shea256, @pwuille and @FiloSottile
So if we didn’t have to deal with the large legacy of software implementations of BIP32 HD-keys and hardware implementations of them, how would today’s cryptographers do derived keys? Just simpler doing PBKDF2, or maybe instead some kind of inheritable zk-proof of derivation?
Replying to @bascule, @zmanian, @durumcrustulum, @JasonALaw, @shea256, @pwuille and @FiloSottile
I also found this interesting paper “The Exact Security of BIP32 Wallets”. Among other things I think it suggests that using BIP32 limits you to 91 bits of security, and some modest changes could make it 111. https://eprint.iacr.org/2021/1287.pdf
Replying to @bascule, @zmanian, @durumcrustulum, @JasonALaw, @shea256, @pwuille and @FiloSottile
/cc @Lhree do you have any updates on this topic from the authors (Poulami Das, Andreas Erwig, Sebastian Faust, Julian Loss, or Siavash Riahi)? Are any active on Twitter?
RT @FOUNDATIONdvcs: THE REVEAL: unveiling Passport Batch 2 and Envoy mobile app
With Batch 2 and Envoy, we built an intuitive and highly s…
This paper got less attention than I thought it would. Among its claims is that BIP32 (used extensively by Bitcoin but also many other blockchains) offers 91 bits of security. I always assumed some low n?<128, but not so low. Given BIP32 is a decade old it was overdue for review. https://twitter.com/IACR_News/status/1441463972612358151
See also discussion thread on use of BIP32 with the popular 25519 curve (our advice “don’t!”) and lack of variant for ristretto. https://twitter.com/ChristopherA/status/1501639899593666561
Here is a video by Professor Muhammed Esgin @mfesgin that also talk about this paper: https://www.monash.edu/it/ssc/cybersecurity/seminars/2021/provable-security-for-deterministic-wallets
cc/ @mfesgin do you have any updates on this topic from the authors (Poulami Das, Andreas Erwig, Sebastian Faust, Julian Loss, or Siavash Riahi) since the paper came out? Are any active on Twitter?
My key question is… https://twitter.com/ChristopherA/status/1501673066232836098?s=20&t=bkbfDC2wr_ka0PDfQoP0BA
RT @julian_loss: @ChristopherA @mfesgin For reference, BIP32 uses mpk*g^w for derivation where g generates the ellpitic curve. This conflic…
RT @SebastFaust: @Lhree @ChristopherA @bascule @zmanian @durumcrustulum @JasonALaw @shea256 @pwuille @FiloSottile @julian_loss 1/2 Yes, thi…
Replying to @theinstagibbs and @meshcollider
The risk of unintended consequences is part of why we forked from Trezor’s SLIP-32 secret sharing scheme. It does not generate the same keys from the same seed that BIP-32 & BIP-39 does. SSKR is fully interoperable. You can convert shards into BIP-39 words and vice-versa.
Over 1.1b people don’t have a valid digital identity. Over 12m are stateless, with no country to support a passport. They may be joined by the 1.7m Ukrainians fleeing the war & an unknown number of Russians fleeing in protest without visas. How do we serve them in a world of KYC?
Replying to @theinstagibbs and @meshcollider
Replying to @theinstagibbs and @meshcollider
SSKR for Users https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-users.md
Replying to @theinstagibbs and @meshcollider
SSKR cold storage https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-cold-storage.md
Replying to @theinstagibbs and @meshcollider
SSKR for developers https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-developers.md
Replying to @theinstagibbs and @meshcollider
Designing SSKR scenarios (draft) https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md
Replying to @theinstagibbs and @meshcollider
Dangers of secret sharing schemes https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Dangers.md
Replying to @theinstagibbs and @meshcollider
SSKR code & independent 3rd party security review: https://github.com/BlockchainCommons/bc-sskr
Replying to @theinstagibbs and @meshcollider
Designing multisig scenarios, including how to mix SSKR with multisig https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Multisig.md
Replying to @RebeccaRachmany
We can do better! Hopefully we will!
Else we risk tragedy. #foremembrance https://twitter.com/ChristopherA/status/1225123316916260864
I’ve had a number of people ask me for my opinion on a Bitcoin dedicated hardware wallet that features a fingerprint sensor. As a singlesig solution I have reservations, but as part of multisig I don’t. Gordian Seed Tool iOS on iPhone 8 is similar. More worried about lock-in… https://twitter.com/BitcoinMagazine/status/1502360447021891587
All of the airgap solutions that Blockchain Commons is working with the wallet ecosystem are multisig focused, but to be truly “Gordian” they must all interoperate, and have no single points of failure. This includes a single vendor or single device. We will be sharing more soon.
I worry more that Square might use it’s financial & market power to lock you into their solution. Instead, every part should be disintermediated. Choose your own node or pricing source of truth, your transaction coordinator, and each of your signers and recovery partners.
The needs of a holder that is new to Bitcoin, or is a cold whale, an active trader, a miner, or lives under different rules of law or risk (thinking US citizen in US vs a Ukrainian at home or abroad), etc. all have different risk thresholds and threats. We need to support all.
Our Gordian Principles, our #SmartCustody wallet architectures, our work with multiple wallet vendors, etc. are about creating open & interoperable, secure & compassionate Digital infrastructure, and human dignity online by enabling people to control their own digital destiny.
Replying to @csuwildcat
Public inspectable is not good enough. It needs more than just I open source but open development. I’m quite critical of vendors who have used open source to create lock-in. The ARCHITECTURE must be focused to prevent vendor lock-in.
Replying to @csuwildcat
We have almost a dozen companies, at many different spots/layers in the ecosystem, ranging from silicon chips, signers, and services, including many who are competitors. All are working towards these airgap & multisig centric solutions. Co-opetition is good!
Replying to @csuwildcat
One of moments I’m proud of was in the early days of the @iPhoneDevCamp hackathon where two iPhone Twitter clients were exchanging tips on how to better leverage Twitter APIs and improve UX. It is this kind of co-opetition that I’m beginning to see in wallet ecosystem.
Replying to @csuwildcat and @iPhoneDevCamp
But this is also a lesson about the perils of centralization. Twitter eventually became upset (pre- @Jack) that the ecosystem was becoming larger than it was, and used a centralized API token to squash the ecosystem. Both innovators are out of business today.
We’ve continued to develop Gordian Seed Tool to demonstrate best practices for signing devices. Version 1.4, out now, shows how to improve user agency for crypto-requests, how to improve resilience with better output options, and how to make a signing device convenient to use. https://twitter.com/BlockchainComns/status/1504265676692680704
Agreed! Quite ominous that a liberal nation (the UK) is taking such an illiberal stance. https://twitter.com/SarahJamieLewis/status/1504584896475328539
Replying to @parman_the
Two important tips. Choose 12 word option—24 words offers no additional security in Bitcoin & increases failure. Don’t use the 13th (or 25th) word “passphrase”—there is no checksum and is a source of large losses. For more, see free #SmartCustody book: https://www.smartcustody.com
Replying to @parman_the
We are working on 2nd edition with multisig with both sovereign and social key recovery options. You can get an early peek at https://GitHub.com/BlockchainCommons/SmartCustody
Replying to @parman_the
The 13th word as defined by BIP38. Don’t use it. Some of the largest losses are due to the mistakes with. Advanced users only.
Replying to @parman_the
https://github.com/BlockchainCommons/SmartCustodyBook/search?q=bip38
Replying to @parman_the
Not for new users. Too easy to make mistakes and a single point of failure. Large losses identified. Maybe ok for advance old school legacy hodlers. But advanced users should move to multisig.
Replying to @soundmoney6 and @parman_the
Gordian SeedTool can accept, store derive keys from 256-bit seeds, but we’ve chosen to be “opinionated” about some choices. For instance we default to multisig options. The free command-line version can do it all — 12, 18 & 24 words.
Replying to @soundmoney6 and @parman_the
I’d consider adding them to Gordian SeedTool as a “developer mode” option if you post a request as an issue so we can add it to roadmap.
Replying to @parman_the and @soundmoney6
There is no checksum on BIP38 passphrases. Even the most minor mistake can’t be noticed until you try to recover and fail. In my interviews of Bitcoin devs (who should know better) I know of $M+ of losses due to this, likely a lot more today at current prices.
Replying to @parman_the and @soundmoney6
I don’t get how it helps with inheritance planning. Many of the losses are because people didn’t write that passphrase down, or share it properly with an heir. The detailed process we suggest in #SmartCustody of test transactions, delete & restore words, can help. Too many don’t.
Replying to @parman_the and @soundmoney6
I’ve done much more research on this than you have. See my #SmartCstody book for threat model and adversarial analysis, and my work (in progress) on multisif https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Multisig.md
🤷🏻♂️ I’m wondering if it is time to refactor/rethink/scrap current 60+ old CLI (Command Line Interface) text shells. I like REPL (Read-Eval-Print Loop) but supporting the legacy of POSIX & C’s stdio in various shells stifles security. We need a fundamental change in architecture.
As the base layer, I want all the executables to be group signed (which probably means Schnorr but not 25519 as it is not safe for multisig) with optional group claims (tested, reproducible, etc). I want #SmartSignatures with at min AND/OR logic support. And signed source repos.
In addition to the error stream, I want an auth stream were all input & executables operating on that stream can validate. Starting with the ssh login, input to the REPL, for every input & output to the end output. Some tags for redacted and/or homomorphic encrypted data.
Clearly we still need redirects and pipes in this new REPL architecture, but we live now in an asynchronous world so all of these streams may split & braid back together. Await & Sync need to be fundamental. Likely also requires some Merkle-like structure to audit.
We also need basic support for binary data, not ASCII. We also need to support complex data. I don’t necessarily want to go as far as RDF/JSON Linked Data, but my experience with
jqfor JSON data in CLI says we ought to have something similar for CBOR.
I don’t want to specify a scripting language — those should sit on top of this fundamental new text shell, but clearly those can support some kind of REPL are best. I’m also not sure how this layer might best support graphical shells.
I’d also love to see some kind of native object capability style auth, but I’m willing to loose some of its more perfect features in favor of “better” or “good enough”. I also want ocap to directly leverage group, adapter, discrete and/or basic zk cryptography. Unsure how.
What am I missing? I’m fairly sure that there are other #InvisibleArchitectures from the of legacy of
shandcthat need to be carefully reviewed & potentially tossed. Feels overdue — C itself is 50 years old this year.
RT @ChristopherA: 🤷🏻♂️ I’m wondering if it is time to refactor/rethink/scrap current 60+ old CLI (Command Line Interface) text shells. I l…
I found its imagined tale of the fall of the USSR to be quite plausible. But it came out as Berlin Wall fell, so immediately was dated. Its emphatic study of WHY Russia behaves as it does was its real strength. It seems even more relevant (or even prescient) given today’s crisis.
Sad to see that Donald Kingsbury’s “The Moon Goddess and the Son” isn’t available on the Kindle. This 80s sci-fi story incidentally also tells perhaps the most in-depth history of the Russian empire from The Kahn thru the USSR. Particularly relevant today. https://www.amazon.com/dp/0671653814/ref=cm_sw_r_cp_api_i_0ZBQGMGSN2CK0N345MDZ
Replying to @csuwildcat and @Iiterature
This answer is technically correct, and is something we are working on a spec for our UR standards for wallet interoperability. There are some subtleties of cryptography you have take care of (no nonce reuse) and features like ratchets for perfect forward secrecy and redaction.
Replying to @csuwildcat and @Iiterature
There are also some long-term issues of privacy vs convenience. For instance in our current design, permits do not include the public key of either the sender or recipient. This mean the code has to iterate through all your private keys and all their public keys until decrypt OK.
Replying to @csuwildcat and @Iiterature
In a sense this makes our encryption like taproot, privacy first. We also hope to support musig/frost capable Schnorr, which means you can also encrypt or decrypt to groups. But some interesting security challenges ahead, for instance key agreement between two frost groups.
Replying to @MartyBent
I highly recommend the BIP21 community consider supporting UR standards for these. Especially as new requirements may make QRs bigger, the built-in support for animated QRs. I’ve listed the reasons why in an issue: https://github.com/sbddesign/bip21-site/issues/47#issuecomment-1074691789
Replying to @StephenDeLorme and @lounes_kmt
We’ve already done a lot of this work in the UR community for PSBTs as well as other cryptographic objects. URs already are optimized for QR compression, support animated form for larger QRs & are self-describing so that metadata can be added. See issue: https://github.com/sbddesign/bip21-site/issues/47#issuecomment-1074691789
Replying to @uxerik_
Though we’ve not added BIP21 support, they could be the UR standards used for PSBTs, hd-key requests, account lists, seeds & shards, etc. They are specifically designed to be self-describing and allow extra metadata: https://github.com/sbddesign/bip21-site/issues/47#issuecomment-1074691789
Why use the crypto-request/crypto-response specification from Blockchain Commons to share public keys, backup seeds, and sign Bitcoin multisig PSBTs? We recently wrote about it at @Blockchaincmns in a new article. [1/14] https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-request-or-crypto-psbt.md
We initially identified two common requests for all blockchain wallets: for a key based on a path; for a seed based on a digest; and for Bitcoin a request to sign based on a PSBT (Partially Signed Bitcoin Transaction). [4/14]
The idea behind crypto-request and response is to create clarity in crypto-interactions, connecting responses to their requests, and allowing for multi-level requests, sub-requests, and metadata specifying exactly what a request means. [3/14]
To back up for a moment, crypto-request and -response are a design pattern that Blockchain Commons introduced at the start of 2021, in consultation with the Airgapped Wallet Community, including @FOUNDATIONdvcs @KeystoneWallet @SparrowWallet ++ [2/14] https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2021-001-request.md
Here’s an example of a request for a Bitcoin multisig cosigner public key [m/48’/0’/0’/2’], derived from a seed of the user’s choice. This allows a transaction coordinator to request what it needs to create an account, and for a user to choose how to fulfill that request. [5/14]
Another use case is to backup a specific seed to another device, as in this crypto-request. This also demonstrates how request comments can improve user agency. Also, as this is riskier than a public key request, our reference app requires a biometric to authorize it. [6/14]
Imagine that you were sending someone a PSBT to transmit at a future time, or to check against business rules before signing, or to validate in some other way. None of those needs could be expressed within a bare PSBT, but with crypto-request/response they’re possible. [9/14]
Why is the crypto-request and response pattern better? Well, that’s what our new article is about, but generally: it allows for additional context and it will do even more in the future, making it future-proof. [8/14] https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-request-or-crypto-psbt.md
As for requests to sign a Bitcoin PSBTs? You have two ways to do this: send a crypto-psbt and get a crypto-psbt back, or send a crypto-request (wrapped around a crypto-psbt) and get a crypto-response back (wrapped around the signed crypto-psbt). [7/14]
Meanwhile, you can also try out these test vectors with our reference Gordian Seed Tool app in the iOS & Mac App Stores. This app is focused multisig signing, and works well with other wallets. [13/14] https://apps.apple.com/us/app/gordian-seed-tool/id1545088229
We encourage you to ask your wallet vendor (and Bitcoin transaction coordinators like @unchainedcap, @CasaHODL, @BtcpayServer) to support these emerging standards. Here is our latest set of UR test vectors & QRs for crypto-request & -response: [12/14] https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-request-test-vectors.mdhttps://apps.apple.com/us/app/gordian-seed-tool/id1545088229
Some of the crypto-request specifications we are beginning to design now include encrypting data in QRs, authorization for access using your keys (Wallet Connect style, but more secure), initiating Musig2 & FROST group signatures, and much more. [11/14]
All it takes is continuing to expand the crypto-request/response specification, so tell us your use cases here — or even better, post in our Airgapped Wallet Community. [10/14] https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions
If you find this type of specification work important, as we work to create an interoperable, open, secure, and compassionate internet, please support it by becoming a Blockchain Commons patron. [14/14] https://github.com/sponsors/BlockchainCommons
The deadline for applications to our virtual internship program at @BlockchainComns is one month away, on April 22. A number of interesting projects have been proposed. Got an interesting brief BTC or human-rights project idea for an intern? Add it here: https://github.com/BlockchainCommons/Community/discussions/76 https://twitter.com/ChristopherA/status/1496912289722560513
RT @csuwildcat: Chris is one of the best to ever do it in the Bitcoin and self-sovereign digital systems space, so if you want to score a s…
RT @JeremyRubin: Cool opportuntiy for mentorship!
Replying to @isabellasg3
Quite a few people have used the Spanish version of our Bitcoin developer course: Aprendiendo Bitcoin desde la Línea de Comandos https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/spanish-translation/es/README.md
RT @IndicioID: Can ‘true #SSI’ be achieved? We took a look at how the foundations of SSI can serve as a basis for a trusted data ecosystem…
Replying to @WebDevLaw
Is there any reasonable scenario where Great Britain digs itself out of the mess they created by Brexit? All I can find are scenarios of things getting worse.
Key point: “we already have laws that work - you don’t need to go crazy and write new ones”. https://twitter.com/exlawyernft/status/1507194382327328788
Replying to @ChrisBrummerDr
I’m intrigued by this, especially if we can find some way to add more privacy, voluntary disclosure, and revokable privacy. For instance, a DAO could not allow delegation of a person’s vote unless the delegate discloses to that delegee (or to the DAO) info. Otherwise max 1 vote.
RT @devrandom01: I just published “Blind Signing Considered Harmful” https://link.medium.com/ynk2YwldNob
Replying to @devrandom01
I’ve been puzzling through UX of what two-part signers should do. Part one is a personal pod with public keys, vs a more stateless wallet. For instance, this is what Gordian Seed Tool does with a crypto-request:
RT @ChristopherA: @devrandom01 I’ve been puzzling through UX of what two-part signers should do. Part one is a personal pod with public key…
More draconian digital identity & biometric bill being proposed in India. Initially for criminals (but including petty crimes) it is too easy to extend this to everyone. (Jaywalked recently?) Bad precedent. https://twitter.com/internetfreedom/status/1508749937278091269
Replying to @DCbuild3r, @rhizobtc and @samczsun
There are many fundamentals in the wallet architecture & infrastructure that are not intrinsic to Ethereum itself. To much use of singlesig hot keys, key reuse, confused deputy problems, etc. These also need to be addressed and are separate from smart contract problems.
Replying to @Asher_Wolf
Most mispronounced words by foreigners: https://jakubmarian.com/english-words-most-commonly-mispronounced-by-foreigners/
Replying to @La__Cuen
You might appreciate this presentation from my “Using the Social Web for Social Change” course that I taught in a green MBA program. Course taught about many kinds of cognitive bias and it is abused against you. https://www.slideshare.net/ChristopherA/tactics-of-persuasion-influence-bgiedu
RT @paddi_hansen: 1/ I hate to ring the alarm bell again, but the EU Parliament leaves us no choice 🚨🚨
This time it concerns a crackdown o…
Replying to @gptbrooke
No way to build trust without correlation. The question is how much for how long.