RIPEMD-160 - BitcoinWiki

Hilarious ChannelBSV show. This is my 3rd ticker symbol as a Bitcoiner. I ain't gonna give bullshiters, tricksters & con-artists any time. I call out all this bullshit about RIPEMD-160 to the guy spreading it! (links in comments)

Hilarious ChannelBSV show. This is my 3rd ticker symbol as a Bitcoiner. I ain't gonna give bullshiters, tricksters & con-artists any time. I call out all this bullshit about RIPEMD-160 to the guy spreading it! (links in comments) submitted by jim-btc to bitcoincashSV [link] [comments]

Bitcoin Cash's hash functions are now available in WebAssembly (SHA-256, SHA-512, SHA-1, and RIPEMD-160)

Bitcoin Cash's hash functions are now available in WebAssembly (SHA-256, SHA-512, SHA-1, and RIPEMD-160) submitted by bitjson to btc [link] [comments]

Just released: Bitcoin crypto using WebAssembly (SHA-256, SHA-512, SHA-1, and RIPEMD-160)

Just released: Bitcoin crypto using WebAssembly (SHA-256, SHA-512, SHA-1, and RIPEMD-160) submitted by bitjson to Bitcoin [link] [comments]

Bitcoin Cash's hash functions are now available in WebAssembly (SHA-256, SHA-512, SHA-1, and RIPEMD-160)

Bitcoin Cash's hash functions are now available in WebAssembly (SHA-256, SHA-512, SHA-1, and RIPEMD-160) submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

RIPEMD-160 is surely going to collide... /r/Bitcoin

RIPEMD-160 is surely going to collide... /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Simple question: a Bitcoin address is the public key of an ECDSA pair, hashed with SHA-256 and then hashed with RIPEMD-160. Correct?

Finding it pretty hard to get a source that states it in so many words, so I don't know if I got it, or if I missed a step or I have the steps completely wrong.
Also, after going through both passes, it's encoded in base64 for display?
submitted by bitcoinfused to Bitcoin [link] [comments]

Eric Lombrozo (Co-CEO & CTO Ciphrex): "SHA1 has been broken. RIPEMD-160, used to protect Bitcoin, might be too weak at also 160 bits. SegWit supports 256-bit security."

Eric Lombrozo (Co-CEO & CTO Ciphrex): submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Why was the RIPEMD-160 hash algorithms chosen before SHA-1? [bitcoin.SE]

Why was the RIPEMD-160 hash algorithms chosen before SHA-1? [bitcoin.SE] submitted by sroose to Bitcoin [link] [comments]

Reddcoin (RDD) 02/20 Progress Report - Core Wallet v3.1 Evolution & PoSV v2 - Commits & More Commits to v3.1! (Bitcoin Core 0.10, MacOS Catalina, QT Enhanced Speed and Security and more!)

Reddcoin (RDD) Core Dev Team Informal Progress Report, Feb 2020 - As any blockchain or software expert will confirm, the hardest part of making successful progress in blockchain and crypto is invisible to most users. As developers, the Reddcoin Core team relies on internal experts like John Nash, contributors offering their own code improvements to our repos (which we would love to see more of!) and especially upstream commits from experts working on open source projects like Bitcoin itself. We'd like tothank each and everyone who's hard work has contributed to this progress.
As part of Reddcoin's evolution, and in order to include required security fixes, speed improvements that are long overdue, the team has up to this point incorporated the following code commits since our last v3.0.1 public release. In attempting to solve the relatively minor font display issue with MacOS Catalina, we uncovered a complicated interweaving of updates between Reddcoin Core, QT software, MacOS SDK, Bitcoin Core and related libraries and dependencies that mandated we take a holistic approach to both solve the Catalina display problem, but in doing so, prepare a more streamlined overall build and test system, allowing the team to roll out more frequent and more secure updates in the future. And also to include some badly needed fixes in the current version of Core, which we have tentatively labeled Reddcoin Core Wallet v3.1.
Note: As indicated below, v3.1 is NOT YET AVAILABLE FOR DOWNLOAD BY PUBLIC. We wil advise when it is.
The new v3.1 version should be ready for internal QA and build testing by the end of this week, with luck, and will be turned over to the public shortly thereafter once testing has proven no unexpected issues have been introduced. We know the delay has been a bit extended for our ReddHead MacOS Catalina stakers, and we hope to have them all aboard soon. We have moved with all possible speed while attempting to incorproate all the required work, testing, and ensuring security and safety for our ReddHeads.
Which leads us to: PoSV v2 activation and the supermajority on Mainnet at the time of this writing has reached 5625/9000 blocks or 62.5%. We have progressed quite well and without any reported user issues since release, but we need all of the community to participate! This activation, much like the funding mechanisms currently being debated by BCH and others, and employed by DASH, will mean not only a catalyst for Reddcoin but ensure it's future by providing funding for the dev team. As a personal plea from the team, please help us support the PoSV v2 activation by staking your RDD, no matter how large or small your amount of stake.
Every block and every RDD counts, and if you don't know how, we'll teach you! Live chat is fun as well as providing tech support you can trust from devs and community ReddHead members. Join us today in staking and online and collect some RDD "rain" from users and devs alike!
If you're holding Reddcoin and not staking, or you haven't upgraded your v2.x wallet to v3.0.1 (current release), we need you to help achieve consensus and activate PoSV v2! For details, see the pinned message here or our website or medium channel. Upgrade is simple and takes moments; if you're nervous or unsure, we're here to help live in Telegram or Discord, as well as other chat programs. See our website for links.
Look for more updates shortly as our long-anticipated Reddcoin Payment Gateway and Merchant Services API come online with point-of-sale support, as we announce the cross-crypto-project Aussie firefighter fundraiser program, as well as a comprehensive update to our development roadmap and more.
Work has restarted on ReddID and multiple initiatives are underway to begin educating and sharing information about ReddID, what it is, and how to use it, as we approach a releasable ReddID product. We enthusiastically encourage anyone interested in working to bring these efforts to life, whether writers, UX/UI experts, big data analysts, graphic artists, coders, front-end, back-end, AI, DevOps, the Reddcoin Core dev team is growing, and there's more opportunity and work than ever!
Bring your talents to a community and dev team that truly appreciates it, and share the Reddcoin Love!
And now, lots of commits. As v3.1 is not yet quite ready for public release, these commits have not been pushed publicly, but in the interests of sharing progress transparently, and including our ReddHead community in the process, see below for mind-numbing technical detail of work accomplished.
e5c143404 - - 2014-08-07 - Ross Nicoll - Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope. *99a7dba2e - - 2014-08-15 - Cory Fields - tests: fix test-runner for osx. Closes ##4708 *8c667f1be - - 2014-08-15 - Cory Fields - build: add funcs.mk to the list of meta-depends *bcc1b2b2f - - 2014-08-15 - Cory Fields - depends: fix shasum on osx < 10.9 *54dac77d1 - - 2014-08-18 - Cory Fields - build: add option for reducing exports (v2) *6fb9611c0 - - 2014-08-16 - randy-waterhouse - build : fix CPPFLAGS for libbitcoin_cli *9958cc923 - - 2014-08-16 - randy-waterhouse - build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix. *342aa98ea - - 2014-08-07 - Cory Fields - build: fix automake warnings about the use of INCLUDES *46db8ad51 - - 2020-02-18 - John Nash - build: add build.h to the correct target *a24de1e4c - - 2014-11-26 - Pavel Janík - Use complete path to include bitcoin-config.h. *fd8f506e5 - - 2014-08-04 - Wladimir J. van der Laan - qt: Demote ReportInvalidCertificate message to qDebug *f12aaf3b1 - - 2020-02-17 - John Nash - build: QT5 compiled with fPIC require fPIC to be enabled, fPIE is not enough *7a991b37e - - 2014-08-12 - Wladimir J. van der Laan - build: check for sys/prctl.h in the proper way *2cfa63a48 - - 2014-08-11 - Wladimir J. van der Laan - build: Add mention of --disable-wallet to bdb48 error messages *9aa580f04 - - 2014-07-23 - Cory Fields - depends: add shared dependency builder *8853d4645 - - 2014-08-08 - Philip Kaufmann - [Qt] move SubstituteFonts() above ToolTipToRichTextFilter *0c98e21db - - 2014-08-02 - Ross Nicoll - URLs containing a / after the address no longer cause parsing errors. *7baa77731 - - 2014-08-07 - ntrgn - Fixes ignored qt 4.8 codecs path on windows when configuring with --with-qt-libdir *2a3df4617 - - 2014-08-06 - Cory Fields - qt: fix unicode character display on osx when building with 10.7 sdk *71a36303d - - 2014-08-04 - Cory Fields - build: fix race in 'make deploy' for windows *077295498 - - 2014-08-04 - Cory Fields - build: Fix 'make deploy' when binaries haven't been built yet *ffdcc4d7d - - 2014-08-04 - Cory Fields - build: hook up qt translations for static osx packaging *25a7e9c90 - - 2014-08-04 - Cory Fields - build: add --with-qt-translationdir to configure for use with static qt *11cfcef37 - - 2014-08-04 - Cory Fields - build: teach macdeploy the -translations-dir argument, for use with static qt *4c4ae35b1 - - 2014-07-23 - Cory Fields - build: Find the proper xcb/pcre dependencies *942e77dd2 - - 2014-08-06 - Cory Fields - build: silence mingw fpic warning spew *e73e2b834 - - 2014-06-27 - Huang Le - Use async name resolving to improve net thread responsiveness *c88e76e8e - - 2014-07-23 - Cory Fields - build: don't let libtool insert rpath into binaries *18e14e11c - - 2014-08-05 - ntrgn - build: Fix windows configure when using --with-qt-libdir *bb92d65c4 - - 2014-07-31 - Cory Fields - test: don't let the port number exceed the legal range *62b95290a - - 2014-06-18 - Cory Fields - test: redirect comparison tool output to stdout *cefe447e9 - - 2014-07-22 - Cory Fields - gitian: remove unneeded option after last commit *9347402ca - - 2014-07-21 - Cory Fields - build: fix broken boost chrono check on some platforms *c9ed039cf - - 2014-06-03 - Cory Fields - build: fix whitespace in pkg-config variable *3bcc5ad37 - - 2014-06-03 - Cory Fields - build: allow linux and osx to build against static qt5 *01a44ba90 - - 2014-07-17 - Cory Fields - build: silence false errors during make clean *d1fbf7ba2 - - 2014-07-08 - Cory Fields - build: fix win32 static linking after libtool merge *005ae2fa4 - - 2014-07-08 - Cory Fields - build: re-add AM_LDFLAGS where it's overridden *37043076d - - 2014-07-02 - Wladimir J. van der Laan - Fix the Qt5 build after d95ba75 *f3b4bbf40 - - 2014-07-01 - Wladimir J. van der Laan - qt: Change serious messages from qDebug to qWarning *f4706f753 - - 2014-07-01 - Wladimir J. van der Laan - qt: Log messages with type>QtDebugMsg as non-debug *98e85fa1f - - 2014-06-06 - Pieter Wuille - libsecp256k1 integration *5f1f2e226 - - 2020-02-17 - John Nash - Merge branch 'switch_verification_code' into Build *1f30416c9 - - 2014-02-07 - Pieter Wuille - Also switch the (unused) verification code to low-s instead of even-s. *1c093d55e - - 2014-06-06 - Cory Fields - secp256k1: Add build-side changes for libsecp256k1 *7f3114484 - - 2014-06-06 - Cory Fields - secp256k1: add libtool as a dependency *2531f9299 - - 2020-02-17 - John Nash - Move network-time related functions to timedata.cpp/h *d003e4c57 - - 2020-02-16 - John Nash - build: fix build weirdness after 54372482. *7035f5034 - - 2020-02-16 - John Nash - Add ::OUTPUT_SIZE *2a864c4d8 - - 2014-06-09 - Cory Fields - crypto: create a separate lib for crypto functions *03a4e4c70 - - 2014-06-09 - Cory Fields - crypto: explicitly check for byte read/write functions *a78462a2a - - 2014-06-09 - Cory Fields - build: move bitcoin-config.h to its own directory *a885721c4 - - 2014-05-31 - Pieter Wuille - Extend and move all crypto tests to crypto_tests.cpp *5f308f528 - - 2014-05-03 - Pieter Wuille - Move {Read,Write}{LE,BE}{32,64} to common.h and use builtins if possible *0161cc426 - - 2014-05-01 - Pieter Wuille - Add built-in RIPEMD-160 implementation *deefc27c0 - - 2014-04-28 - Pieter Wuille - Move crypto implementations to src/crypto/ *d6a12182b - - 2014-04-28 - Pieter Wuille - Add built-in SHA-1 implementation. *c3c4f9f2e - - 2014-04-27 - Pieter Wuille - Switch miner.cpp to use sha2 instead of OpenSSL. *b6ed6def9 - - 2014-04-28 - Pieter Wuille - Remove getwork() RPC call *0a09c1c60 - - 2014-04-26 - Pieter Wuille - Switch script.cpp and hash.cpp to use sha2.cpp instead of OpenSSL. *8ed091692 - - 2014-04-20 - Pieter Wuille - Add a built-in SHA256/SHA512 implementation. *0c4c99b3f - - 2014-06-21 - Philip Kaufmann - small cleanup in src/compat .h and .cpp *ab1369745 - - 2014-06-13 - Cory Fields - sanity: hook up sanity checks *f598c67e0 - - 2014-06-13 - Cory Fields - sanity: add libc/stdlib sanity checks *b241b3e13 - - 2014-06-13 - Cory Fields - sanity: autoconf check for sys/select.h *cad980a4f - - 2019-07-03 - John Nash - build: Add a top-level forwarding target for src/ objects *f4533ee1c - - 2019-07-03 - John Nash - build: qt: split locale resources. Fixes non-deterministic distcheck *4a0e46e76 - - 2019-06-29 - John Nash - build: fix version dependency *2f61699d9 - - 2019-06-29 - John Nash - build: quit abusing AMCPPFLAGS *99b60ba49 - - 2019-06-29 - John Nash - build: avoid the use of top and abs_ dir paths *c8f673d5d - - 2019-06-29 - John Nash - build: Tidy up file generation output *5318bce57 - - 2019-06-29 - John Nash - build: nuke Makefile.include from orbit *672a25349 - - 2019-06-29 - John Nash - build: add stub makefiles for easier subdir builds *562b7c5a6 - - 2020-02-08 - John Nash - build: delete old Makefile.am's *066120079 - - 2020-02-08 - John Nash - build: Switch to non-recursive make
Whew! No wonder it's taken the dev team a while! :)
TL;DR: Trying to fix MacOS Catalina font display led to requiring all kinds of work to migrate and evolve the Reddcoin Core software with Apple, Bitcoin and QT components. Lots of work done, v3.1 public release soon. Also other exciting things and ReddID back under active dev effort.
submitted by TechAdept to reddCoin [link] [comments]

Contrats d'exécution consensuels de VDS et processus du téléchargement à la chaîne

Résumé des contrats d’exécution consensuels
Le concept de base du contrat d’exécution consensuels
Contrats d’exécution consensuels, connu sous le nom de contrat intelligent dans l'industrie de la blockchain, mais l'équipe de VDS estime que ce terme est trop marketing, car nous n'avons pas trouvé à quel point la technologie de programmation contractuelle est intelligente jusqu'à présent, il s'agit simplement d'un système décentralisé dans le réseau distribué, la procédure prédéfinie de comportement consensuel formée par l'édition de code. Dans l'esprit de rechercher la vérité à partir des faits, nous pensons qu'il est plus approprié de renommer le contrat intelligent en tant que contrat d'exécution de consensus. Lorsque les humains combineront la technologie blockchain avec la technologie d'intelligence artificielle de AI à l'avenir, les obstacles à la compréhension des noms sont éliminés.
Le contrat d'exécution consensuel peut être appliqué à de nombreuses industries, telles que la finance, l'éducation, les systèmes administratifs, l'Internet des objets, le divertissement en ligne, etc. Grâce à la technologie de la blockchain, dans un réseau distribué spécifique, un script d'exécution qui est formé par l'édition de pré-code sans aucune intervention de tiers et le comportement de consensus des deux parties ou de plusieurs parties impliquées dans le protocole. Il garantit l’exécution sûre, stable et équitable des droits et intérêts de tous les participants au contrat.
Le contrat d'exécution consensuel a joué un rôle dans l'accélération de l'atterrissage de diverses applications pour le développement de l'industrie de la blockchain et a incité davantage de développeurs à y participer activement, révolutionnant l'expérience réelle des produits de la technologie de la blockchain. Tout découle des contributions exceptionnelles de l'équipe Ethereum, ouvrant une nouvelle porte à l'ensemble de l'industrie.
Structure de base et jonction
L’intégration de EVM
La machine virtuelle Ethereum (EVM) utilise un code machine 256 bits et est une machine virtuelle basée sur la pile utilisée pour exécuter les contrats d'exécution consensuels d'Ethereum. Étant donné que l'EVM est conçu pour le système Ethereum, le modèle de compte Ethereum (Account Model) est utilisé pour la transmission de valeurs. La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La raison de cette conception est, d'une part, c'est en raison de la nécessité de réaliser la fonction d'échange de résonance de VDS et la fonction d'échange inter-chaîne unidirectionnelle de bitcoin à chaîne VDS, qui peuvent réaliser la génération de deux adresses différentes de bitcoin et VDS avec une clé privée. D'autre part, l'équipe VDS estime que la structure sous-jacente des transactions Bitcoin est plus stable et fiable grâce à 10 ans de pratique sociale. Par conséquent, VDS utilise une couche d'abstraction de compte (Account Abstraction Layer) pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par EVM. De plus, VDS a ajouté une interface basée sur le modèle de compte, afin qu'EVM puisse lire directement les informations sur la chaîne VDS. Il convient de noter que la couche d'abstraction de compte peut masquer les détails de déploiement de certaines fonctions spécifiques et établir une division des préoccupations pour améliorer l'interopérabilité et l'indépendance de la plate-forme.
Dans le système Bitcoin, ce n'est qu'après la vérification du script de déverrouillage (Script Sig) et du script de verrouillage (Script Pub Key) que la sortie de transaction correspondante peut être dépensée.
Par exemple, le script de verrouillage verrouille généralement une sortie de transaction sur une adresse bitcoin (la valeur de hachage de la clé publique). Ce n'est que lorsque les conditions de configuration du script de déverrouillage et du script de verrouillage correspondent, que l'exécution du script combiné affiche le résultat sous la forme True (la valeur de retour de système est 1), de sorte que la sortie de transaction correspondante sera dépensée.
Dans le système distribué de VDS, nous soulignons l'opportunité de l'exécution du contrat d'exécution consensuel. Par conséquent, nous avons ajouté les opérateurs OP_CREATE et OP_CALL au script de verrouillage. Lorsque le système de VDS détecte cet opérateur, les nœuds de l'ensemble du réseau exécuteront la transaction. De cette façon, le rôle joué par le script Bitcoin est plus de transférer les données pertinentes vers EVM, pas seulement en tant que langage de codage. Tout comme Ethereum exécute un contrat d'exécution de consensus, le contrat déclenché par les opérateurs OP_CREATE et OP_CALL, EVM changera son état dans sa propre base de données d'état.
Compte tenu de la facilité d'utilisation du contrat d'exécution du consensus de la chaîne VDS, il est nécessaire de vérifier les données qui déclenchent le contrat et la valeur de hachage de la clé publique de la source de données.
Afin d'éviter que la proportion d'UTXO sur la chaîne de VDS ne soit trop importante, la sortie de transaction de OP_CREATE et OP_CALL est t conçue pour être dépensée. La sortie de OP_CALL peut envoyer des fonds pour d'autres contrats ou adresses de hachage de clé publique.
Tout d’abord, pour le contrat d'exécution consensuel créé sur la chaîne VDS, le système généreraune valeur de hachage de transaction pour l'appel de contrat.Le contrat nouvellement libéré a un solde initial de 0 (les contrats avec un solde initial ne sont pas 0 ne sont pas pris en charge). Afin de répondre aux besoins du contrat d'envoi de fonds, VDS utilise l'opérateur OP_CALL pour créer une sortie de transaction. Le script de sortie du contrat d'envoi de fonds est similaire à :
1: the version of the VM
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
Ce script n'est pas compliqué et OP_CALL effectue la plupart du travail requis. VDS définit le coût spécifique de la transaction (sans tenir compte de la situation de out-of-gas) comme Output Value, qui est Gas Limit. Le mécanisme spécifique du Gas sera discuté dans les chapitres suivants. Lorsque le script de sortie ci-dessus est ajouté à la blockchain, la sortie établit une relation correspondante avec le compte du contrat et se reflète dans le solde du contrat. Le solde peut être compris comme la somme des coûts contractuels disponibles.
La sortie d'adresse de hachage de clé publique standard est utilisée pour le processus de base des transactions de contrat, et le processus de transaction entre les contrats est également généralement cohérent. En outre, vous pouvez effectuer des transactions par P2SH et des transactions non standard (non-standard transactions). Lorsque le contrat actuel doit être échangé avec un autre contrat ou une adresse de hachage de clé publique, la sortie disponible dans le compte du contrat sera consommée. Cette partie de la sortie consommée doit être présente pour la vérification des transactions dans le réseau de VDS, que nous appelons la transaction attendue du contrat (Expected Contract Transactions). Étant donné que la transaction attendue du contrat est générée lorsque le mineur vérifie et exécute la transaction, plutôt que d'être générée par l'utilisateur de la transaction, elle ne sera pas diffusée sur l'ensemble du réseau.
Le principe de fonctionnement principal de la transaction attendue du contrat est réalisé par le code OP_SPEND. OP_CREATE et OP_CALL ont deux modes de fonctionnement. Lorsque l'opérateur est utilisé comme script de sortie, EVM l'exécute, lorsque l'opérateur est utilisé comme script d'entrée, EVM ne sera pas exécuté (sinon il provoquera une exécution répétée). Dans ce cas, OP_CREATE et OP_CALL peuvent être utilisés comme Opération sans commandement. OP_CREATE et OP_CALL reçoivent la valeur de hachage de transaction transmise par OP_SPEND et renvoient 1 ou 0 (c'est-à-dire il peut être dépensé ou pas). Il montre l'importance de OP_SPEND dans la transaction attendue de l'intégralité du contrat. Plus précisément, lorsque OP_SPEND transmet la valeur de hachage de transaction à OP_CREATE et OP_CALL, OP_CREATE et OP_CALL comparent si la valeur de hachage existe dans la liste des transactions attendues du contrat. S'il existe, renvoyez 1 pour dépenser, sinon retournez 0, ce n'est pas pour dépenser. Cette logique fournit indirectement un moyen complet et sûr de garantir que les fonds du contrat ne peuvent être utilisés que par le contrat, ce qui est cohérent avec le résultat des transactions UTXO ordinaires.
Lorsque le contrat EVM envoie des fonds à l'adresse de hachage de clé publique ou à un autre contrat, une nouvelle transaction sera établie. À l'aide de l'algorithme de Consensus-critical coin picking, la sortie de transaction la plus appropriée peut être sélectionnée dans le pool de sortie disponible du contrat. La sortie de transaction sélectionnée sera utilisée comme script d'entrée pour exécuter un seul OP_SPEND, et la sortie est l'adresse cible des fonds, et les fonds restants seront renvoyés au contrat, tout en modifiant la sortie disponible pour la consommation. Ensuite, la valeur de hachage de cette transaction sera ajoutée à la liste des transactions attendues du contrat. Lorsque la transaction est exécutée, la transaction sera immédiatement ajoutée au bloc. Une fois que les mineurs de la chaîne ont vérifié et exécuté la transaction, la liste des transactions attendues du contrat est à nouveau parcourue. Une fois la vérification correcte, la valeur de hachage est supprimée de la table. De cette façon, l'utilisation de OP_SPEND peut effectivement empêcher l'utilisation de valeurs de hachage codées en dur pour modifier le coût de la sortie.
La couche d'abstraction des comptes VDS élimine la nécessité pour l'EVM d'accorder trop d'attention à coin-picking. Il lui suffit de connaître le solde du contrat et peut échanger des fonds avec d'autres contrats ou même des adresses de hachage de clé publique. De cette façon, seule une légère modification du contrat d'exécution du consensus Ethereum peut répondre aux exigences de fonctionnement du contrat VDS.
En d'autres termes, tant que le contrat d'exécution consensuel peut être exécuté sur la chaîne Ethereum, il peut s'exécuter sur la chaîne VDS.
Achèvement de AAL
La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La plate-forme générale de contrat d'exécution de consensus utilise le modèle de compte. Étant donné que le contrat en tant qu'entité nécessite un logo de réseau, ce logoest l'adresse du contrat, de sorte que le fonctionnement et la gestion du contrat d'exécution consensuel peuvent être effectués par cette adresse. La couche d'abstraction de compte est ajoutée à la conception du modèle (Account Abstraction Layer, AAL) de chaîne de VDS, qui est utilisée pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par le contrat.
Pour les développeurs qui exécutent des contrats par consensus, le modèle de compte de la machine virtuelle est relativement simple. Il prend en charge l'interrogation des soldes des contrats et peut également envoyer des fonds pour d'autres contrats. Bien que ces opérations semblent très simples et basiques, toutes les transactions de la chaîne VDS utilisent le langage de script Bitcoin, et il est plus compliqué que prévu d'être implémenté dans la couche d'abstraction de compte de la chaîne VDS basée sur le modèle Bitcoin UTXO. AAL a donc élargi sa base en ajoutant trois nouveaux opérateurs :
OP_CREATE est utilisé pour effectuer la création de contrats intelligents, transmettre le code d'octet transmis via la transaction à la base de données de stockage de contrats de la machine virtuelle et générer un compte de contrat.
OP_CALL est utilisé pour transférer les données pertinentes et les informations d'adresse nécessaires pour appeler le contrat et exécuter le contenu du code dans le contrat. (Cet opérateur peut également envoyer des fonds pour des contrats d'exécution consensuels).
OP_SPEND utilise la valeur de hachage de ID de contrat actuel comme transaction d'entrée HASH ou transaction HASH envoyée à l'UTXO du contrat, puis utilise OP_SPEND comme instruction de dépense pour créer un script de transaction.
Utilisation des Contrats et processus du téléchargement à la chaîne
Rédiger les contrats
Il est actuellement possible d'utiliser le langage Solidity pour rédiger des contrats d'exécution de consensus.
Utilisez Solidity Remix ou un autre Solidity IDE pour l'écriture et la compilation de code.
solidity remix(https://remix.ethereum.org/
Il est recommandé d'utiliser le mode homestead pour compiler.
Il est recommandé d'utiliser la version solidité 0.4.24 (si d'autres versions sont utilisées, cela peut provoquer des erreurs ou des échecs).
La syntaxe Solidity peut être référencée(https://solidity.readthedocs.io/en)
Compiler et déployer les contrats
Fonctionnement du contrat intelligent de vdsd
Examiner les variables de fonctionnement de l'environnement
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
> Les tests sous contrat sont effectués dans l'environnement de test. Il est recommandé de tester après avoir atteint une hauteur de 440 blocs.
440 blocs hautement achevés l'opération de retour de fonds après les événements anormaux du contrat (refund) et (revert).
La commande de contrat de déploiement est :
```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
Cette fonction est utilisée pour l'exécution du constructeur du contrat avec les paramètres entrants pour obtenir le ByteCode qui est finalement utilisé pour le déploiement.
(Cette méthode consiste à associer le bytecode à ABI et à le stocker localement pour l'enregistrement. Il peut appeler des méthodes internes localement et renvoyer le bytecode approprié)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
La valeur de retour est : txid, éxpéditeur, hachage de l'expéditeur160, adresse du contrat
Consulter si la commande a été exécutée avec succès :
```vds-cli gettransactionreceipt txid```
La valeur de retour de txid pour les transactions non contractuelles est vide
La valeur de retour est : Les informations pertinentes de txid sur la BlockHash Hachage du bloc
- blockNumber Hauteur de bloc
- transactionHash Hachage de transaction
- transactionIndex La position de l'échange dans le bloc
- from Hachage de l’adresse de l’expéditeur 160
- to Le destinataire est l'adresse du contrat, le lieu de création de la transaction contractuelle est 00000000000000000000000000000
- cumulativeGasUsed Gas accumulé
- gasUsed Gaz réellement utilisé
- contractAddress Adresse du contrat
- excepted Y a-t-il des erreurs
- exceptedMessage Message d'erreur
-
Il convient de noter que le champ excepted n'est pas None, ce qui indique que l'exécution du contrat a échoué. Bien que la transaction puisse être vérifiée sur la chaîne, cela ne signifie pas que le contrat a été exécuté avec succès, c'est-à-dire que les frais de traitement pour l'exécution de ce contrat ne sont pas remboursables. Les frais de traitement ne seront remboursés que si la méthode revert est entrée dans le contrat, et les frais de méthode ne seront pas remboursés pour la méthode assert.
Appel des contrats
```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
Cette fonction est utilisée pour ajouter le contrat ABI à la base de données locale.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
Cette fonction est utilisée pour obtenir les informations du contrat ajouté.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
Cette fonction renverra le résultat de l'exécution lors de l'appel de la méthode constante ordinaire, comme l'appel de la méthode d'opération de données de contrat retournera la chaîne de format hexadécimal du script d'opération.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
Cette fonction est utilisée pour envoyer le script d'opération de contrat au contrat spécifié et le faire enregistrer sur la blockchain.
Consultation des résultats d’exécution des contrats
```vds-cli gettransaction txid```
Cette commande est utilisée pour afficher les heures de confirmation de la transaction de portefeuille actuelle.
```vds-cli gettransactionreceipt txid```
Cette commande est utilisée pour vérifier les résultats d'exécution de la création de contrat et des transactions d'appel, s'il y a des exceptions levées et des consommations réelles de GAS.
`${datadir}/vmExecLogs.json` enregistrera les appels de contrat sur la blockchain. Ce fichier servira d'interface externe pour les événements de contrat.
Interface d'appel des contrats
l Interface de création de contrat createcontract
l Interface de déploiement de contrat deploycontract
l Interface d'ajout ABI addcontract
l Interface d’appel des contrats avec l’opération des fons sendtocontract
l Interface de lecture des informations sur les contrats callcontractfunc
l Interface d'acquisition d'informations sur l'exécution des transactions contractuelles gettransactionreceipt
L’expliquation des coûts d’expoitation des contrats
Les coûts de fonctionnement de la création d'un contrat sont toutes des méthodes estimées, et un succès d'exécution à 100% ne peut pas être garanti, car gas limit a une limite supérieure de 50000000, et les contrats dépassant cette limite entraîneront un échec. La chaîne de VDS utilise une méthode de rendre la monnaie, ce qui signifie que même si beaucoup de gaz est envoyé, le mineur n'utilisera pas tout le gas et restituera le gas restant. Alors ne vous inquiétez pas de dépenser trop de gas.
Le coût de création d'un contrat est approximativement de la taille du Byte Code * 300 comme gas limit, le gas price minimum est de 0.0000004, gas price * gas limit est le coût de création d'un contrat.
En ce qui concerne l'exécution de la méthode dans un contrat, le gas requis est estimé. En raison de la congestion du réseau, l'estimation ne garantit pas que 100% peuvent être téléchargés avec succès dans la chaîne. Par conséquent, je crains de tromper et de demander au développeur de vérifier les résultats.
submitted by YvanMay to u/YvanMay [link] [comments]

Bitcoin’s Security and Hash Rate Explained

Bitcoin’s Security and Hash Rate Explained
As the Bitcoin hash rate reaches new all-time highs, there’s never been a better time to discuss blockchain security and its relation to the hashing power and the Proof of Work (PoW) that feed the network. The Bitcoin system is based on a form of decentralized trust, heavily relying on cryptography. This makes its blockchain highly secure and able to be used for financial transactions and other operations requiring a trustless ledger.
Far from popular belief, cryptography dates back to thousands of years ago. The same root of the word encryption — crypt — comes from the Greek word ‘kryptos’, meaning hidden or secret. Indeed, humans have always wanted to keep some information private. The Assyrians, the Chinese, the Romans, and the Greeks, they all tried over the centuries to conceal some information like trade deals or manufacturing secrets by using symbols or ciphers carved in stone or leather. In 1900 BC, Egyptians used hieroglyphics and experts often refer to them as the first example of cryptography.
Back to our days, Bitcoin uses cryptographic technologies such as:
  1. Cryptographic hash functions (i.e. SHA-256 and RIPEMD-160)
  2. Public Key Cryptography (i.e. ECDSA — the Elliptic Curve Digital Signature Algorithm)
While Public Key Cryptography, bitcoin addresses, and digital signatures are used to provide ownership of bitcoins, the SHA-256 hash function is used to verify data and block integrity and to establish the chronological order of the blockchain. A cryptographic hash function is a mathematical function that verifies the integrity of data by transforming it into a unique unidentifiable code.
Here is a graphic example to make things more clear:

– Extract from the MOOC (Massive Open Online Course) in Digital Currencies at the University of Nicosia.
Furthermore, hash functions are used as part of the PoW algorithm, which is a prominent part of the Bitcoin mining algorithm and this is what is of more interest to understand the security of the network. Mining creates new bitcoins in each block, almost like a central bank printing new money and creates trust by ensuring that transactions are confirmed only when enough computational power is devoted to the block that contains them. More blocks mean more computation, which means more trust.
With PoW, miners compete against each other to complete transactions on the network and get rewarded. Basically they need to solve a complicated mathematical puzzle and a possibility to easily prove the solution. The more hashing power, the higher the chance to resolve the puzzle and therefore perform the proof of work. In more simple words, bitcoins exist thanks to a peer to peer network that helps validate transactions in the ledger and provides enough trust to avoid that a third party is involved in the process. It also exists because miners give it life by resolving that computational puzzle, through the mining reward incentive they are receiving.
For more info, contact Block.co directly or email at [email protected].
Tel +357 70007828
Get the latest from Block.co, like and follow us on social media:
✔️Facebook
✔️LinkedIn
✔️Twitter
✔️YouTube
✔️Medium
✔️Instagram
✔️Telegram
✔️Reddit
✔️GitHub
submitted by BlockDotCo to u/BlockDotCo [link] [comments]

understanding unique wallet address

understanding unique wallet address
I've been reading Mastering Bitcoin book. And the following estimation is mentioned:


https://preview.redd.it/s52qllwl48j11.png?width=1226&format=png&auto=webp&s=7bec2db8bf3977dbb26f90d3f70e2cefa58c3d3e
is this simply a permutation of 256 bits ?
how does alphanumeric SHA factor in? (is it just HEX representation of base 2?)
Also i am curious how we go from 2^256 to 10^77.. is there a way to explain this using a much smaller number?
submitted by sonicraf to Bitcoin [link] [comments]

Is Crypto Currency truly at risk due to Quantum Computers, and what can you do about it?

Is Crypto Currency truly at risk due to Quantum Computers, and what can you do about it?

There is no denying that the Quantum revolution is coming. Security protocols for the internet, banking, telecommunications, etc... are all at risk, and your Bitcoins (and alt-cryptos) are next!
This article is not really about quantum computers[i], but, rather, how they will affect the future of cryptocurrency, and what steps a smart investor will take. Since this is a complicated subject, my intention is to provide just enough relevant information without being too “techy.”

The Quantum Evolution

In 1982, Nobel winning physicist, Richard Feynman, hypothesized how quantum computers[ii] would be used in modern life.
Just one year later, Apple released the “Apple Lisa”[iii] – a home computer with a 7.89MHz processor and a whopping 5MB hard drive, and, if you enjoy nostalgia, it used 5.25in floppy disks.
Today, we walk around with portable devices that are thousands of times more powerful, and, yet, our modern day computers still work in a simple manner, with simple math, and simple operators[iv]. They now just do it so fast and efficient that we forget what’s happening behind the scenes.
No doubt, the human race is accelerating at a remarkable speed, and we’ve become obsessed with quantifying everything - from the everyday details of life to the entire universe[v]. Not only do we know how to precisely measure elementary particles, we also know how to control their actions!
Yet, even with all this advancement, modern computers cannot “crack” cryptocurrencies without the use of a great deal more computing power, and since it’s more than the planet can currently supply, it could take millions, if not billions, of years.
However, what current computers can’t do, quantum computers can!
So, how can something that was conceptualized in the 1980’s, and, as of yet, has no practical application, compromise cryptocurrencies and take over Bitcoin?
To best answer this question, let’s begin by looking at a bitcoin address.

What exactly is a Bitcoin address?

Well, in layman terms, a Bitcoin address is used to send and receive Bitcoins, and looking a bit closer (excuse the pun), it has two parts:[vi]
A public key that is openly shared with the world to accept payments. A public key that is derived from the private key. The private key is made up of 256 bits of information in a (hopefully) random order. This 256 bit code is 64 characters long (in the range of 0-9/a-f) and further compressed into a 52 character code (using RIPEMD-160).
NOTE: Although many people talk about Bitcoin encryption, Bitcoin does not use Encryption. Instead, Bitcoin uses a hashing algorithm (for more info, please see endnote below[vii]).
Now, back to understanding the private key:
The Bitcoin address “1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm” translates to a private key of “5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf” which further translates to a 256 bit private key of “0000000000000000000000000000000000000000000000000000000000000001” (this should go without saying, but do not use this address/private key because it was compromised long ago.) Although there are a few more calculations that go behind the scenes, these are the most relevant details.
Now, to access a Bitcoin address, you first need the private key, and from this private key, the public key is derived. With current computers, it’s classically impractical to attempt to find a private key based on a public key. Simply put, you need the private key to know the public key.
However, it has already been theorized (and technically proven) that due to private key compression, multiple private keys can be used to access the same public key (aka address). This means that your Bitcoin address has multiple private keys associated with it, and, if someone accidentally discovers or “cracks” any one of those private keys, they have access to all the funds in that specific address.
There is even a pool of a few dedicated people hunting for these potential overlaps[viii], and they are, in fact, getting very efficient at it. The creator of the pool also has a website listing every possible Bitcoin private key/address in existence[ix], and, as of this writing, the pool averages 204 trillion keys per day!
But wait! Before you get scared and start panic selling, the probability of finding a Bitcoin address containing funds (or even being used) is highly unlikely – nevertheless, still possible!
However, the more Bitcoin users, the more likely a “collision” (finding overlapping private/public key pairs)! You see, the security of a Bitcoin address is simply based on large numbers! How large? Well, according to my math, 1.157920892373x1077 potential private keys exist (that number represents over 9,500 digits in length! For some perspective, this entire article contains just over 14,000 characters. Therefore, the total number of Bitcoin addresses is so great that the probability of finding an active address with funds is infinitesimal.

So, how do Quantum Computers present a threat?

At this point, you might be thinking, “How can a quantum computer defeat this overwhelming number of possibilities?” Well, to put it simple; Superposition and Entanglement[x].
Superposition allows a quantum bit (qbit) to be in multiple states at the same time. Entanglement allows an observer to know the measurement of a particle in any location in the universe. If you have ever heard Einstein’s quote, “Spooky Action at a Distance,” he was talking about Entanglement!
To give you an idea of how this works, imagine how efficient you would be if you could make your coffee, drive your car, and walk your dog all at the same time, while also knowing the temperature of your coffee before drinking, the current maintenance requirements for your car, and even what your dog is thinking! In a nutshell, quantum computers have the ability to process and analyze countless bits of information simultaneously – and so fast, and in such a different way, that no human mind can comprehend!
At this stage, it is estimated that the Bitcoin address hash algorithm will be defeated by quantum computers before 2028 (and quite possibly much sooner)! The NSA has even stated that the SHA256 hash algorithm (the same hash algorithm that Bitcoin uses) is no longer considered secure, and, as a result, the NSA has now moved to new hashing techniques, and that was in 2016! Prior to that, in 2014, the NSA also invested a large amount of money in a research program called “Penetrating Hard Targets project”[xi] which was used for further Quantum Computer study and how to break “strong encryption and hashing algorithms.” Does NSA know something they’re not saying or are they just preemptively preparing?
Nonetheless, before long, we will be in a post-quantum cryptography world where quantum computers can crack crypto addresses and take all the funds in any wallet.

What are Bitcoin core developers doing about this threat?

Well, as of now, absolutely nothing. Quantum computers are not considered a threat by Bitcoin developers nor by most of the crypto-community. I’m sure when the time comes, Bitcoin core developers will implement a new cryptographic algorithm that all future addresses/transactions will utilize. However, will this happen before post-quantum cryptography[xii]?
Moreover, even after new cryptographic implementation, what about all the old addresses? Well, if your address has been actively used on the network (sending funds), it will be in imminent danger of a quantum attack. Therefore, everyone who is holding funds in an old address will need to send their funds to a new address (using a quantum safe crypto-format). If you think network congestion is a problem now, just wait…
Additionally, there is the potential that the transition to a new hashing algorithm will require a hard fork (a soft fork may also suffice), and this could result in a serious problem because there should not be multiple copies of the same blockchain/ledger. If one fork gets attacked, the address on the other fork is also compromised. As a side-note, the blockchain Nebulas[xiii] will have the ability to modify the base blockchain software without any forks. This includes adding new and more secure hashing algorithms over time! Nebulas is due to be released in 2018.

Who would want to attack Bitcoin?

Bitcoin and cryptocurrency represent a threat to the controlling financial system of our modern economy. Entire countries have outright banned cryptocurrency[xiv] and even arrested people[xv], and while discrediting it, some countries are copying cryptocurrency to use (and control) in their economy[xvi]!
Furthermore, Visa[xvii], Mastercard[xviii], Discover[xix], and most banks act like they want nothing to do with cryptocurrency, all the while seeing the potential of blockchain technology and developing their own[xx]. Just like any disruptive technology, Bitcoin and cryptocurrencies have their fair share of enemies!
As of now, quantum computers are being developed by some of the largest companies in the world, as well as private government agencies.
No doubt, we will see a post-quantum cryptography world sooner than most realize. By that point, who knows how long “3 letter agencies” will have been using quantum technology - and what they’ll be capable of!

What can we do to protect ourselves today?

Of course, the best option is to start looking at how Bitcoin can implement new cryptographic features immediately, but it will take time, and we have seen how slow the process can be just for scaling[xxi].
The other thing we can do is use a Bitcoin address only once for outgoing transactions. When quantum computers attack Bitcoin (and other crypto currencies), their first target will be addresses that have outgoing transactions on the blockchain that contain funds.
This is due to the fact that when computers first attempt to crack a Bitcoin address, the starting point is when a transaction becomes public. In other words, when the transaction is first signed – a signed transaction is a digital signature derived from the private key, and it validates the transaction on the network. Compared to classical computers, quantum computers can exponentially extrapolate this information.
Initially, Bitcoin Core Software might provide some level of protection because it only uses an address once, and then sends the remaining balance (if any) to another address in your keypool. However, third party Bitcoin wallets can and do use an address multiple times for outgoing transactions. For instance, this could be a big problem for users that accept donations (if they don’t update their donation address every time they remove funds). The biggest downside to Bitcoin Core Software is the amount of hard-drive space required, as well as diligently retaining an up-to-date copy of the entire blockchain ledger.
Nonetheless, as quantum computers evolve, they will inevitably render SHA256 vulnerable, and although this will be one of the first hash algorithms cracked by quantum computers, it won’t be the last!

Are any cryptocurrencies planning for the post-quantum cryptography world?

Yes, indeed, there are! Here is a short list of ones you may want to know more about:

Full disclosure:

Although I am in no way associated with any project listed above, I do hold coins in all as well as Bitcoin, Litecoin and many others.
The thoughts above are based on my personal research, but I make no claims to being a quantum scientist or cryptographer. So, don’t take my word for anything. Instead, do your own research and draw your own conclusions. I’ve included many references below, but there are many more to explore.
In conclusion, the intention of this article is not to create fear or panic, nor any other negative effects. It is simply to educate. If you see an error in any of my statements, please, politely, let me know, and I will do my best to update the error.
Thanks for reading!

References

[i] https://www.youtube.com/watch?v=JhHMJCUmq28 – A great video explaining quantum computers.
[ii] https://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol4/spb3/ - A brief history of quantum computing.
[iii] https://en.wikipedia.org/wiki/Apple_Lisa - More than you would ever want to know about the Apple Lisa.
[iv] https://www.youtube.com/watch?v=tpIctyqH29Q&list=PL8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo - Want to learn more about computer science? Here is a great crash course for it!
[v] https://www.collinsdictionary.com/dictionary/english/quantify - What does quantify mean?
[vi] https://en.bitcoin.it/wiki/Private_key - More info about Bitcoin private keys.
[vii] https://www.securityinnovationeurope.com/blog/page/whats-the-difference-between-hashing-and-encrypting - A good example of the deference between Hash and Encryption
[viii] https://lbc.cryptoguru.org/stats - The Large Bitcoin Collider.
[ix] http://directory.io/ - A list of every possible Bitcoin private key. This website is a clever way of converting the 64 character uncompressed key to the private key 128 at a time. Since it is impossible to save all this data in a database and search, it is not considered a threat! It’s equated with looking for a single needle on the entire planet.
[x] https://uwaterloo.ca/institute-for-quantum-computing/quantum-computing-101#Superposition-and-entanglement – Brief overview of Superposition and Entanglement.
[xi] https://www.washingtonpost.com/world/national-security/nsa-seeks-to-build-quantum-computer-that-could-crack-most-types-of-encryption/2014/01/02/8fff297e-7195-11e3-8def-a33011492df2_story.html?utm_term=.e05a9dfb6333 – A review of the Penetrating Hard Targets project.
[xii] https://en.wikipedia.org/wiki/Post-quantum_cryptography - Explains post-quantum cryptography.
[xiii] https://www.nebulas.io/ - The nebulas project has some amazing technology planned in their roadmap. They are currently in testnet stage with initial launch expected taking place in a few weeks. If you don’t know about Nebulas, you should check them out. [xiv] https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country_or_territory - Country’s stance on crypto currencies.
[xv] https://www.cnbc.com/2017/08/30/venezuela-is-one-of-the-worlds-most-dangerous-places-to-mine-bitcoin.html - Don’t be a miner in Venezuela!
[xvi] http://www.newsweek.com/russia-bitcoin-avoid-us-sanctions-cryptocurrency-768742 - Russia’s plan for their own crypto currency.
[xvii] http://www.telegraph.co.uk/technology/2018/01/05/visa-locks-bitcoin-payment-cards-crackdown-card-issue - Recent attack from visa against crypto currency.
[xviii] https://www.ccn.com/non-government-digital-currency-junk-says-mastercard-ceo-rejecting-bitcoin/ - Mastercards position about Bitcoin.
[xix] http://www.livebitcoinnews.com/discover-joins-visa-mastercard-barring-bitcoin-support/ - Discovers position about Bitcoin.
[xx] http://fortune.com/2017/10/20/mastercard-blockchain-bitcoin/ - Mastercard is making their own blockchain.
[xxi] https://bitcoincore.org/en/2015/12/21/capacity-increase/ - News about Bitcoin capacity. Not a lot of news…
[xxii] https://learn.iota.org/faq/what-makes-iota-quantum-secure - IOTA and quantum encryption.
[xxiii] https://eprint.iacr.org/2011/191.pdf - The whitepaper of Winternitz One-Time Signature Scheme
[xxiv] https://cardanoroadmap.com/ - The Cardano project roadmap.
[xxv] https://eprint.iacr.org/2017/490 - More about the BLISS hash system.
[xxvi] https://www.ethereum.org/ - Home of the Ethereum project.
[xxvii] https://en.wikipedia.org/wiki/SHA-3#Security_against_quantum_attacks – SHA3 hash algorithm vs quantum computers.
[xxviii] https://en.wikipedia.org/wiki/Lamport_signature - Lamport signature information.
[xxix] https://theqrl.org/ - Home of the Quantum Resistant Ledger project.
submitted by satoshibytes to CryptoCurrency [link] [comments]

Proof of Failure - "I'll get you next time Salty Roger" :-)

"actus non facit reum nisi mens sit rea"
Just under 7 days ago I posted the following SHA256 hash to both the BSV blockchain and BAB blockchain.
I actually posted at 2019-06-16 20:00:00 but it took some minutes (as you'll see I predicted) to appear in the next block of the aforementioned blockchains, thus remaining a permanent immutable record.
memo.sv post Block Time: 2019-06-16 20:38:22 Block Number: 587160
memo.cash post Block Time: 2019-06-16 20:29:44 Block Number: 587318
This is verifiable proof that I held the plaintext to make this hash on that date. The hash as you can see is which is a SHA256:-
52f42a5a4c073a2a14ed76e5a1d356c4586e6f2dea2a91d9a3dcf5f57799442e
Just after posting to the blockchain this hash, I sent private messages to 3 members of this subreddit with the following text, and thus this is the reason why I am now forced to reveal the hash, as I expect them to take my words seriously.
It doesn't matter in the grand scheme of things (as all I did is cryptographically proven) that I did this, however I wanted to so I would be forced to reveal the plaintext within 7 days. I won't name them, but if they want to confirm that they did indeed receive this message then I'll leave that up to them.
Hi guys. Look I am doing something kinda funny here, but for now needs to be secret. Here is a SHA256 hash, write it down!
"52f42a5a4c073a2a14ed76e5a1d356c4586e6f2dea2a91d9a3dcf5f57799442e"
If I don't reveal what plaintext is the source of this hash within the next 7 days then it means I am a fraud, and I am not to be trusted and I request I am permabanned from the subreddit, and all communications with me should cease.
This hash has been published on both the BSV & BAB blockchains as a memo message, as proof it wasn't created after the time it appears in the blockchains, and proof of immutability of content.
You can see it here (BSV):- https://memo.sv/profile/1gr5whAEV4ffA6df71JTdQ7gSNQWTkgnm Or here (BAB):- https://memo.cash/profile/1gr5whAEV4ffA6df71JTdQ7gSNQWTkgnm
And timestamp will be a few seconds or minutes after timestamp below, as and when message gets confirmed in next block on each respective chain. PoW!
If I happen to be banned from reddit in the meantime don't worry as hash reveal will take place on these memo channels within 7 days.
If this works you're all gonna LOL real hard cause it will cause one big massive social media shitstorm! And we all know the only way to destroy a PoSM shitcoin like BAB is with social media!
Cheers fellas! jim-btc 2019-06-16T20:00:00Z End of message.
I actually sent it to them as an image
This is all those 3 members have seen, and all 3 have confirmed, one with "I'll be watching" another with a "LOL" type response and another with a rather concerned "what's this?" type response. I gave them no further information - so now all reading this post know exactly the same about this all as they do - which is basically nothing, other than this hash 52f42a5a4c073a2a14ed76e5a1d356c4586e6f2dea2a91d9a3dcf5f57799442e must be something interesting.
So what was the plaintext behind this hash? What does it have to do with Salty Roger?
Well I'm gonna take some inspiration from Dr. Craig S. Wright here to add some tension... I still have a few hours to reveal the plain-text, which is in fact a computer program. We shall all see.
UPDATE
OK here it is: https://gofile.io/?c=FsGtJD
Go check that SHA256 hash.
Here's the code:
#!/usbin/env python # bab-destroy.py # Should work in Python2.7 & Python 3.x # Author: jim-btc # If you change any character in this code (including newlines so careful # Windows users - it will fail to reproduce the excercise! # This is BAB Destroy. Some code designed to make Salty Roger Ver, head of # Bitcoin Cash (BAB) look very stupid and get owned by cryptohashes once again. # # The BABies (that's users of said coin) seem to spout the mantra "Code is Law" # so I thought what better way to own them all than by using some code to do # it! # Purpose of this program is to generate a fake (unspendable) Bitcoin address # and to hash various messages. Hash for this program (hence the entire process # in the pwnage of Salty Roger will be published on both the Bitcoin Cash (BAB) # and Bitcoin (BSV) blockchains as "proof-of-LOL" so what I am doing here can # easily be verified as non-illegal and non-fraudulent *after the event* by # simply running this code and verifying all messages/hashes produced - to # replay the sequence of events as it were. # # A non-spendable address is used to demonstrate even if Roger was dumb enough # to send BTC that it is the equivalent of burning money - i.e. nobody can # benefit. Also for any legal eagles reading allow me introduce some Latin: # "actus non facit reum nisi mens sit rea". Interesting case study to be made # perhaps regarding blockchains as immutable evidence. # The idea is the following happens:- # # 1) Hash of this program code is published on BAB & BSV blockchains to proove # timestamp that this effort was started, using memo.cash / memo.sv # # 2) A few community memebers from Bitcoin (BSV) subreddit are sent a hashed # message stating that there is a hash on BAB/BSV blockchain and if I don't # reveal how to make it within 7 days then I am a fraud, a scammer and should # be removed from the community - this is to ensure nobody can claim the # argument "jim-btc was just testing to see if Roger would pay" and to # ensure revealing of this code regardless of the outcome. # # 3) Roger recieves a message from me basically stating "Pay me 1BTC and I will # stop attacking your coin and community and work for you attacking BSV". # # 4) Roger publishes this message on /btc (or /npc as it's better called) # and tries to state that jim-btc is a scammer, and possibly that this is # a scam/community atack by the entire community of BSV. The idea is that # Roger basically publisizes this for maximum effect so when the truth is # revealed his own publicity owns him. An alternative (but very unlikely) is # that Roger sends 1BTC to the address - where I then publish this entire # message chain to prove (once again) that Roger is an idiot and has no # problem employing sockpuppets for nefarious purposes and has just burned 1BTC # for his very silly efforts! Remember if he sends any funds there - I cannot # spend it as you see that the public address has no corresponding private key. # (it's a fake address). # # 5) Bonus LOLpoints will be rewarded if this news makes it to Roger's Twitter # account and/or his news.bitcoin.com website as some sort of proof that # "criminal blackmailers are attempting to destroy BAB" or the now famous # classic quote they use "It's an attack" as they keep needing to invent a # common external enemy like Orwell's 1984 as some way for cohesion in their # destroyed and rotten "community". It is expected that as Salty Roger loves to # play victim he shall play victim to maximum effect. Let's hope so! # # 6) Program code is revealed. Orignal hash on BAB/BSV blockchains is shown as # matching the hash of the program code. Roger looks dumb, all BABies are # awakened as to just how easy it is to attack a PoSM (Proof of Social Media) # shitcoin such as Bitcoin Cash (BAB). The crypto world laughs, lawyers debate # the legality of this all - everyone is confused but most agree Roger has once # again proved he knows nothing about crypto and is easily spoofed. # # People read this program code and these comments and find out just how bad # things are with BABcoin. They sell the idea of "decentralized development" # when in reality Amaury Sachet (ABC node developer) bans Andrew Stone, LEAD # developer of Bitcoin Unlimited from any meetings. It also encourages BABies # to look at the ideas floating around in the dev community - such as spending # funding money on developer get-togethers when clearly the fundraising they # are doing is supposed to be paying for developers to develop. People are # encouraged to look into the transparency of all fundraising and realise that # this is not a sustainable model for a anti-business coin such as BAB. # # Once again I'd ask people to seriously debate the difference and the # narrative:- # # "Satosh added checkpoints to Bitcoins source code - checkpoints are OK" # -- the BAB narrative # # The reality:- # These checkpoints were added days/weeks/months after the blocks were mined # for pretty obvious reasons. # Amaury Sachet (shitlord dictator of ABC) added them within ~10 minutes of # blocks being mined and colluded with exchanges to use this special software # within minutes. That is not fair competition, this is not PoW. That is a PoSM # shitcoin and shall be destroyed - only way to do it is with social media! # # This program is dedicated to unwriter and Craig S. Wright (Satoshi Nakamoto). # # Read unwriters phenomenal message to all devs:- # # https://medium.com/@_unwritethe-resolution-of-the-bitcoin # -cash-experiment-52b86d8cd187 # # OK - let's get started... # # These are the only 3 functions we need to import. from binascii import hexlify from hashlib import sha256 from os import path BASE_58_ALPHABET = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz' # First let's make a public key based on some text, unless we manage to break # cryptography we will have no way of knowing the private key for this message # thus any coins sent here are effectivley burned (unspendable). # This message will give us fake address 1MCpARZExPsW5EmBMEYj2NoyUxaoWyZt8N BITCOIN_PUBKEY_MESSAGE = b'Roger Ver is an idiot, jim-btc owns him!' MESSAGE_TO_ROGER = '''Hey Roger. You see I am attacking BCH continuously. If you want me to stop (and switch teams and work for you guys attacking BSV) then I will accept the job. I can be paid a salary of 1 BTC to this address to get started:- {} Don\'t try and share this message and slander me cause I will just deny it. I am a lot cleverer than you guys - admit it! Not interested in further communications, except confirmation, and I shall not respond. Payment to the aforementioned address is the acceptance of hiring me - not negotiable. End of message.''' MEMO_SV = 'https://memo.sv/profile/1gr5whAEV4ffA6df71JTdQ7gSNQWTkgnm' MEMO_BAB = 'https://memo.cash/profile/1gr5whAEV4ffA6df71JTdQ7gSNQWTkgnm' MESSAGE_TO_FOLKS = '''Hi guys. Look I am doing something kinda funny here, but for now needs to be secret. Here is a SHA256 hash, write it down! "{}" If I don't reveal what plaintext is the source of this hash within the next 7 days then it means I am a fraud, and I am not to be trusted and I request I am permabanned from the subreddit, and all communications with me should cease. This hash has been published on both the BSV & BAB blockchains as a memo message, as proof it wasn't created after the time it appears in the blockchains, and proof of immutability of content. You can see it here (BSV):- {} Or here (BAB):- {} And timestamp will be a few seconds or minutes after timestamp below, as and when message gets confirmed in next block on each respective chain. PoW! If I happen to be banned from reddit in the meantime don\'t worry as hash reveal will take place on these memo channels within 7 days. If this works you\'re all gonna LOL real hard cause it will cause one big massive social media shitstorm! And we all know the only way to destroy a PoSM shitcoin like BAB is with social media! Cheers fellas! jim-btc 2019-06-16T20:00:00Z End of message.''' SEPERATOR = '*' * 80 WARNING_ADDR = '''WARNING: Hey if you are running this code to prove the hashes, DO NOT SEND ANY BSV/BTC/BAB to the address! I cannot spend it as I don\'t have the private key and it\'s impossible to find it - you will just be burning your crypto!''' def make_bitcoin_address(pubkey_hash): with_network_byte = b'\x00' + pubkey_hash full_checksum = sha256(sha256(with_network_byte).digest()).hexdigest() checksum = full_checksum[:4 * 2] address_hex = hexlify(with_network_byte).decode() + checksum b58_string = '' # Get the number of leading zeros leading_zeros = len(address_hex) - len(address_hex.lstrip('0')) # Convert hex to decimal address_int = int(address_hex, 16) # Append digits to the start of string while address_int > 0: digit = address_int % 58 digit_char = BASE_58_ALPHABET[digit] b58_string = digit_char + b58_string address_int //= 58 # Add '1' for each 2 leading zeros ones = leading_zeros // 2 for one in range(ones): b58_string = '1' + b58_string return b58_string def main(): # We'll use first 160 bits of sha256 of message - doesn't really matter! # as long as we have 160 bits like RIPEMD-160 pubkey_hash = sha256(BITCOIN_PUBKEY_MESSAGE).digest()[:160 // 8] # If you wanna test the function then follow this blog post # https://www.freecodecamp.org/news/how-to-create-a-bitcoin-wallet-address # -from-a-private-key-eca3ddd9c05f/ # and hardcode it as:- # pubkey_hash = b'E23`\n\x968K\xb8\[email protected]\t\x84\x11z\xc8M~\x8b' # and you will get result '17JsmEygbbEUEpvt4PFtYaTeSqfb9ki1F1' as per blog fake_bitcoin_address = make_bitcoin_address(pubkey_hash) source_code = path.abspath(path.realpath(__file__)) hash_of_this_source_code = sha256() # We'll hash this source code. Hashing this is proof of the entire # operation! and allows anybody to see what was done, when, and why. with open(source_code, 'rb') as _: hash_of_this_source_code.update(_.read()) source_hash = hash_of_this_source_code.hexdigest() # We now input the hashes etc... into the messages, print them on screen # for easy copy pasta! message_to_folks_with_hash = MESSAGE_TO_FOLKS.format(source_hash, MEMO_SV, MEMO_BAB) message_to_roger = MESSAGE_TO_ROGER.format(fake_bitcoin_address) print(SEPERATOR) print(message_to_folks_with_hash) print(SEPERATOR) print(message_to_roger) print(SEPERATOR) print(WARNING_ADDR) if __name__ == "__main__": main() 
This is what output looks like if you run it (you'll see it hashes itself but you can do sha256sum on the program file if you want)
******************************************************************************** Hi guys. Look I am doing something kinda funny here, but for now needs to be secret. Here is a SHA256 hash, write it down! "52f42a5a4c073a2a14ed76e5a1d356c4586e6f2dea2a91d9a3dcf5f57799442e" If I don't reveal what plaintext is the source of this hash within the next 7 days then it means I am a fraud, and I am not to be trusted and I request I am permabanned from the subreddit, and all communications with me should cease. This hash has been published on both the BSV & BAB blockchains as a memo message, as proof it wasn't created after the time it appears in the blockchains, and proof of immutability of content. You can see it here (BSV):- https://memo.sv/profile/1gr5whAEV4ffA6df71JTdQ7gSNQWTkgnm Or here (BAB):- https://memo.cash/profile/1gr5whAEV4ffA6df71JTdQ7gSNQWTkgnm And timestamp will be a few seconds or minutes after timestamp below, as and when message gets confirmed in next block on each respective chain. PoW! If I happen to be banned from reddit in the meantime don't worry as hash reveal will take place on these memo channels within 7 days. If this works you're all gonna LOL real hard cause it will cause one big massive social media shitstorm! And we all know the only way to destroy a PoSM shitcoin like BAB is with social media! Cheers fellas! jim-btc 2019-06-16T20:00:00Z End of message. ******************************************************************************** Hey Roger. You see I am attacking BCH continuously. If you want me to stop (and switch teams and work for you guys attacking BSV) then I will accept the job. I can be paid a salary of 1 BTC to this address to get started:- 1MCpARZExPsW5EmBMEYj2NoyUxaoWyZt8N Don't try and share this message and slander me cause I will just deny it. I am a lot cleverer than you guys - admit it! Not interested in further communications, except confirmation, and I shall not respond. Payment to the aforementioned address is the acceptance of hiring me - not negotiable. End of message. ******************************************************************************** WARNING: Hey if you are running this code to prove the hashes, DO NOT SEND ANY BSV/BTC/BAB to the address! I cannot spend it as I don't have the private key and it's impossible to find it - you will just be burning your crypto! 
Any technical questions / comments feel free to ask below.
submitted by jim-btc to bitcoincashSV [link] [comments]

TIL: brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space

TIL: brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space submitted by obi-nine to Bitcoin [link] [comments]

What's the logic behind there being a greater number of potential private keys (10^77) than hashed addresses (10^48)?

Does this also mean that there are 1029 different private keys that will be able to spend the coins at every individual address?
submitted by PumpkinFeet to Bitcoin [link] [comments]

Ren will present on Bitcoin Wednesday’s 6-Year Anniversary on 3 July 2019

Bitcoin Wednesday’s 6-Year Anniversary on 3 July 2019 presents cryptographer Ren Zhang, who will compare Proof of Work (PoW) to Proof of Stake (PoS). Proof of Work is a mathematical algorithm that produces results that are difficult to calculate but easy to verify, the governing principle that secures Bitcoin. Although the PoW concept was first proposed in the early 90s, Satoshi Nakamoto’s novel use of it, described in the Bitcoin white paper, sparked the cryptocurrency revolution.

In his talk for Bitcoin Wednesday Ren will explain what Proof of Work brings us that was previously impossible and how it compares to alternatives like Proof of Stake. He writes:

More than $146 billion in crypto-assets (75% of them worldwide) are secured by Proof of Work. As of June 2019, $1 million worth of Bitcoin is created every day to compensate miners who use physical resources to secure the system. These numers are not small, and it is likely that they will grow even larger if cryptocurrencies continue to thrive. In order to avoid PoW’s high level of energy consumption, many new cryptocurrencies turn to other consensus mechanisms. How do they match up to Proof of Work? Have they achieved their goals? What do they sacrifice, if anything?

Ren is a cryptography researcher at COSIC Research Group at KU Leuven in Belgium, where he focuses on blockchain consensus protocols and privacy- and security-related problems in peer-to-peer networks. He is currently working on a variant of Nakamoto Consensus with higher throughput known as NC-Max. He is a cryptographer for Nervos, a new Proof-of-Work blockchain, and a research assistant to Bart Preneel, the designer of RIPEMD 160, the hash function used to compute from your Bitcoin public key to your Bitcoin address. Ren’s research group at KU Leuven happens to be the birthplace of AES, the advanced encryption standard used in almost all electronic devices.

In 2017, after Ren discovered design flaws in the Bitcoin Unlimited scaling proposal, he was invited to work with Pieter Wuillie and Gregory Maxwell at Blockstream. His paper, “Lay Down the Common Metrics: Evaluating Proof-of-Work Consensus Protocol’s Security” which he co-authored with Bart Preneel, was presented at the 2019 IEEE SP symposium in Oakland.

https://www.bitcoinwednesday.com/speakers/ren-zhang-cryptographer-ku-leuven-nervos/
submitted by Aimeedeer to NervosNetwork [link] [comments]

I made my own Blockchain in Java (Part 2) now with Source Code!

Hello all! Same guy that posted about a Java Bitcoin Address Generator. I've completed my blockchain mockup and I couldn't be happier with it. Although it doesn't have persistent state and doesn't use new addresses as Change addresses (since the wallets are not HD, just single-keypair wallets), I learned a lot from doing this.
It really does help to understand the complexity of cryptocurrencies when you try to make it from scratch by yourself. There's a ton of security behind bitcoin, and some of it may seem absurd (SHA-256 hashing into RIPEMD-160 into 2x SHA-256 like Damn... all for a checksum).
If you want to mess around with the program, I've uploaded it to Github (Link here). It's a functioning wallet-type program that has Accounts you can switch between where each account has its own KeyPair that you can then send and receive funds to. There is a block reward for mining new blocks that is distributed from the "coinbase" wallet.
NOTE: This is intended to be for educational purposes and should in no way be considered a real cryptocurrency/blockchain. It only runs for the time you have it open and loses all information when closed. The addresses it generates ARE valid bitcoin addresses that you can use, but do so at your own risk and know what you're doing. There is no seed for the addresses that are generated.
submitted by Septem_151 to Bitcoin [link] [comments]

/u/Septem_151 on Cybercash, as imagined in 1998

TL;DR: A Transaction Input is what reveals your public key, not the Transaction Output, and an address represents the hash of a Public Key.
UTXOs that are P2PKH (Pay to Pub Key Hash) go to the hash of a public key. More specifically, the following script, known as the scriptPubKey, is pushed onto a stack: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
These operations define how the coins are allowed to be spent. OP_DUP = Duplicate the top item of the stack, OP_HASH160 = Popping the top of the stack and pushing the RIPEMD-160 hash of the SHA-256 hash of the popped data back onto the stack, = Pushing the recipient’s decoded Address onto the stack, OP_EQUALVERIFY = checking if the top two values on the stack are equal and popping them if true, and OP_CHECKSIG = checks if the signature is verified by the public key on the stack (more on this later). For more information, check the bitcoin wiki’s section on bitcoin script.
A legacy bitcoin address (beginning with a 1) is just a public key hash that is encoded in Base58 with a version byte (0x00) prepended, and a checksum appended to the end. To convert an address to a PubKeyHash is as simple as decoding from Base58.
However, when a UTXO is Spent, the spender must prove ownership by providing some additional values to satisfy the UTXO’s scriptPubKey. This combination of values is known as the scriptSig, and for P2PKH consists of two parts: Signature>
When a Transaction is evaluated and verified, the input’s scriptSig and the scriptPubKey of the output it’s spending are placed onto a stack so the whole thing becomes: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
First, the signature is pushed to the stack. Then the public key associated with the bitcoin address. OP_DUP duplicates the public key, OP_HASH160 pops the public key off the stack and pushes the hash of the public key onto the stack. Then the PubKeyHash whom the coins belongs to is pushed to the stack. Then OP_EQUALVERIFY checks to see if the public key does indeed hash to the specified PubKeyHash. If true, the two values are popped off the stack. Then OP_CHECKSIG takes the last two elements from the stack (the signature and the unhashed public key) and checks if the signature is valid. If true, the input is valid and “unlocks” the UTXO for spending.
This is a big part of why you should not reuse addresses: only when you SPEND a UTXO do you reveal your Public Key to the world. Until spent, your public key is secured behind other barriers (SHA-256 and RIPEMD-160). If Elliptic Curve cryptography is to be broken by quantum computers, it will also need to break the hashing algorithms above as well to at least invalidate P2PKH outputs. Back in the very early days, some Outputs were made using P2PK (Pay to Pub Key) which does not use this intermediary hashing technique and is considered far less secure, thus it is rarely used today if at all.
Septem_151
submitted by highhighhopes101 to TalkativePeople [link] [comments]

Rough numbers for brute-forcing a wallet

The bitstamp hack got me curious. Presumably it's infeasible, but just wondering if someone had tons of hardware from mining could it be put to use to brute force an address with a large amount of bitcoins?
I presume the answer is that it's nowhere near, just that it would be interesting if there happened to be a number of bitcoins that it would be worth chasing after with raw computing power instead of chasing mining fees.
submitted by justwritecomments to Bitcoin [link] [comments]

Could you use the same public address for both Bitcoin and Dogecoin (or other altcoins)?

Could you use one address for more than one crypto currency? If you have a donation address, one could send either bitcoin or dogecoin to it, for example. Just make sure you don't send your doge to a bitcoin address or vice versa.
submitted by steffenfrost to Bitcoin [link] [comments]

12-30 21:33 - 'That's not true. The core has more features than electrum- it just requires use of the CLI. Honestly, you shouldn't be using multi-sig in the first place if you can't figure out how to generate an address using the CLI...' by /u/Nycmdthroaway removed from /r/Bitcoin within 43-53min

'''
That's not true. The core has more features than electrum- it just requires use of the CLI. Honestly, you shouldn't be using multi-sig in the first place if you can't figure out how to generate an address using the CLI.
Open up the debug window CLI tab, type `help' and you'll see how much you can do and the information you can ascertain with the core node that you can't with electrum.
Electrum relies on the core node for all of its functionality, save their proprietary mnemonic seed backup algorithm, which is much less secure than BIP33 (which can be generated with the core; electrum literally provides you with the dictionary to carry out an attack on its addresses, and it doesn't use an EC in its cryptographic process, meaning the encryption entropy is low and the nonces are predictable).
I could order some RIPEMD-160 ASIC chips for $2/piece and have a Chinese fabricator design a PCB using some cheap 22nm SHA-256 chips and the RIPEMD chips, replace cgminer or bfgminer's computational sections with the ultra optimized vanitygen algos for brute forcing priv keys, switch out stratum for JTR-style threaded rainbow tables based on a few hundred thousand rounds of mnemonic generation using electrum's suite- along with some open source code analysis, and in a month I could create a machine that could generate and test hundreds of thousands to millions of mnemonics per second.
The only reason this hasn't been an active practice is because destroying bitcoins keypair-cryptography (or at least appearing to have done so) would send the price under a dollar in 24hours. An update would be patched within a few days and it should be a lot of hard work for nothing. But I wouldn't be surprised if this is occurring actively on a small scale, with old addresses presumed to be "lost." Even if an active address was hit, as long as it wasn't overdone, people would shrug it off as a physical compromise of their own network/machine/software, not an epidemic- but considering the frequency of exchanges getting "hacked" and the actual ease by which the attack could be carried out, I think there's an equal possibility that the security is already completely compromised.
Theoretically all mnemonic backups are inherently insecure (as is any password using dictionary words, no matter how long) but at least using ECDHE and a deterministic seed, you're actually getting a password with a strength equal to that of the sum of its characters as ASCI to BASE/56 encoded bits. Without that, you may as well have a 12 character passphrase (with the possible characters equal to the number of words in the abridged electrum dictionary.) So it's {POSSIBLE WORDS}12 for electrum vs. something closer to {(POSSIBLE WORDS60)(POSSIBLE HD-SEEDS)}256 for a BIP33 mnemonic using SecP256k ECDHE algo (assuming average number of letters in a word are 5 and HD seeds are pseudo-random.) But mnemonic seeds are still insecure even with BIP33. Use the core wallet and you get a key with true randomness using entropy from blockchain derived sources, 2 rounds of SHA-256 and a final RIPEMD-160 round with a 256-Bit secret generated in conjunction with with an extremely secure ECDHE curve=trillions upon trillions of possibilities. That not only makes a single key harder to break, it means there is a much less likely chance of someone randomly guessing secrets and testing them to see if they come out to a funded address in the whole scheme of things.
It's like if I tried to break into every Dell server. If many people were using weak passwords, and I could try a password on all of them at the same time- I'd surely crack a bunch, and make Dell look bad as a company, even though the servers were inherently fine. Keeping the network strong means making sure you do your part to save face, after all bitcoin is owned and CONTROLLED by the userbase.
As a side note, RIPEMD was only used in the public scheme along with SHA256 (despite being significantly weaker) because at the time SHA256 was the only widely implemented and highly secure algorithm- meaning it could be as widely adopted and widely mined as possible. So SHA-256 was the logical choice for the main block algorithm. There wasn't another option for the wallet address' scheme that would be secure tunneling enough and still computationally feasible and easy to integrate. So SHA-256 was most secure, but without the round of RIPEMD-160 as the deterministic round, wallets could be brute forced at the same time as mining, with the same hardware.
For the most secure, fool-proof, uncrackable wallet, here's what I do/used to do: Use the Core node to bake Segwit P2SH addresses. I don't use HD wallets period, but HD is secure enough as long as you're using a truly random secret. Remember that the secret in a BIP33 HD wallet is the master privkey, additionally, each address has it's own xpriv, which, considering the combinations possible, saving the individual xprivs makes the most sense anyway. If you plan on spending the coins soon, just secure the wallet .dat file with a strong 16+ character (A-Z,a-z,()$&@#$/?¿%÷,0-9) passphrase (this is just the wallet file pw it has nothing to do with your addresses) then just throw the wallet on a flash drive or better yet an SD card or 2 and call it a day.
For addresses you plan to put on ice for a while, concat your coins into a handful of accounts, don't store more than $1,000/address. Then using the `dumpprivkey' Core CLI command (I think that's the command, it's something like that, type help and you'll see it if I'm wrong), a text encrypting program (for good measure) and a barcode/QR code generator (all offline!), get the private keys for each address, encrypt the text with an easy to remember password (you'll be taking the keys offline, and storing physically, so no need to worry too much about that pass, it's better to just keep them physically safe), and then generate QR codes for each. Paste them all into a word doc with the corresponding (lightly) encrypted numbers you generated the QRs with. Print out a couple copies and then delete the addresses from the wallet.
Put those paper wallets somewhere safe. You could also split the key down the middle and store the 2 parts of the paper wallets in different places instead of encrypting the plaintext xprivs. So you'd need to scan both paper keys and paste the solutions together to access the coins.
That's all a bit extreme... in reality, unless you're super paranoid and storing millions, you'll be fine by keeping your coins in the core node with decent firewall and a good .dat passphrase.
BUT ELECTRUM IS NO GOOD!
'''
Context Link
Go1dfish undelete link
unreddit undelete link
Author: Nycmdthroaway
submitted by removalbot to removalbot [link] [comments]

Ripemd160 - YouTube Bitcoin Hacking! Overview of the program For searching for private keys Hashcat running in Termux (part 1 - testing crack RIPEMD-160 hash) An inconsistency in Nakamoto's paranoia FSE 2018 - Cryptanalysis of 48-step RIPEMD-160

RIPEMD was used because it produces the shortest hashes whose uniqueness is still sufficiently assured. This allows Bitcoin addresses to be shorter. SHA256 is used as well because Bitcoin's use of a hash of a public key might create unique weaknesses due to unexpected interactions between RIPEMD and ECDSA (the public key signature algorithm). Bitcoin uses both SHA-256 and RIPEMD-160 hashes. Most often a double-round SHA-256 is used, but for address generating, RIPEMD-160 is used because it generates a shorter hash value. RIPEMD-160 has a 160-bit or 20-byte hash value while SHA-256 has a 256-bit or 32-byte. Algorithm Name: RIPEMD-160 Description: Whirlpool is a standardized, public domain hashing algorithm that produces 512 bit digests. Full list of hashing, encryption, and other conversions RIPEMD-160. Bitcoin uses SHA-256 and RIPEMD-160 cryptographic hashes. There are many aspects of Bitcoin that use hashes and the vast majority of them use a double SHA-256 encryption. However, in a few situations that require hashes (such as e-mail addresses), a singular SHA-256 is used in combination with a singular RIPEMD-160 hash.. These hashes, when calculated on a GPU, make it feasible to RIPEMD-160 is a cryptographic hash function based upon the Merkle–Damgård construction. It is used in the Bitcoin standard. It is a a strengthened version of the RIPEMD algorithm which produces a 128 bit hash digest while the RIPEMD-160 algorithm produces a 160-bit output.

[index] [18805] [13088] [24476] [4454] [5171] [27259] [30037] [21480] [27405] [6360]

Ripemd160 - YouTube

Sign in to like videos, comment, and subscribe. Sign in. Watch Queue Queue The program does not require an Internet connection, since the generation of bitcoin addresses with private keys occurs, SHA 256, RIPEMD-160 , base58 are already built into the program Loading... The program does not require an Internet connection, since the generation of bitcoin addresses with private keys occurs, SHA 256, RIPEMD-160 , base58 are already built into the program Category ... Elliptic curves, SHA256, and RIPEMD160, oh my. Dr. Darren Tapp presents the fundamental mathematics needed for Bitcoin to work as intended, prepared so that people of many levels can get something ... Hashcat running in Termux (part 1 - testing crack RIPEMD-160 hash) kuburan 0day. Loading... Unsubscribe from kuburan 0day? ... Bitcoin Daytrader 18,124 views. 16:56. The Fastest Hash Decrypter ...

Flag Counter