hash - Is it possible to break SHA-512? - Cryptography ...

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]

Groestlcoin 6th Anniversary Release


Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.

Other Linux



Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.





ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.


Live Version (Not Recommended)





ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).






ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).




Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.


Remastered Improvements



ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.



Linux :
 pip3 install -r requirements.txt python3 bip39\_gui.py 


ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Trading Crypto with BitHash API

Trading Crypto with BitHash API
BitHash Exchange offers cryptocurrency trading through a set of APIs.

How to start trading with Crypto Trading API

  1. Sign Up or Login to your BitHash account.
  2. Go to API key management page. You will see allyour API keys there.
  3. If you don’t have any keys, click the Create New API Key button.
  4. Use the Key Public value as the key parameter.
  5. Use your API Secret yo sign request to the endpoint.

BitHash API

Security Notes

Private endpoints use HMAC SHA512 signatures.
Use your API Secret to generate a signed query string. Signed query string should not contain a sign parameter itself.
For endpoints without any parameters you should sign query:
API_KEY — your public key found on the keys management page
TIMESTAMP — current timestamp in milliseconds
You can find full BitHash Trading API (v4) guide here:

About BitHash

BitHash Cryptocurrency Exchange was established in 2016 in Singapore with more than 100 pairs available for trading cryptocurrencyBitcoin (BTC), Ethereum (ETH), Litecoin (LTC), Bitcoin Cash (BCH), Ethereum Classic (ETC), Dash (DASH), EOS (EOS), Monero (XMR), Ripple (XRP), Zcash (ZEC).
BitHash Exchange is operated by PHOENIX TRADING SOLUTIONS LTD (“BitHash”), a company incorporated under the International Business Companies Act of 2016 of the Republic of Seychelles with company number 214028.
submitted by BitHashExchange to bithash [link] [comments]

New game launch - “BLAST” !

We will soon release our new game Blast! To make this game provably fair, we announce our methods here.
A chain of 1 million SHA512 hashes was generated (starting with a server secret.)
The final hash is:
Bitsler will go through the hashes (in reverse order) and use each hash to determine the crash result. So the hash of our first game's hash is the same as our published final hash.
To ensure we didn't pick a hash chain that has some advantage for us, we will use a future bitcoin block hash as "client seed" to generate the final crash results. We will use the block hash of bitcoin block 608891 (around 4:30 AM GMT on Fri 20 Dec 2019.)
The code to generate each crash result is:
$hash = hash_hmac('sha512', $gameHash, $blockHash); $number = hexdec(substr($hash, 0, 13)); $multiplier = 98 / (1 - ($number / (pow(2,52)))); echo max(100, floor($multiplier)) / 100; 
This blog post will be shared on our social media channels and archived by several archive websites. Therefor we cannot edit the final hash (and therefor hash chain) nor the future bitcoin block number anymore. This makes our new game Blast completely provably fair.

Link list

submitted by BitslerCasino to u/BitslerCasino [link] [comments]

Bitcoin Cash is now fully supported by BitCloak mixer.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm happy to announce that BitCloak mixer now also supports Bitcoin Cash. You can select Bitcoin Cash from the menu, or add /bch to the base url. It comes with all the usual mixer features, pgp-proof and api included. To prevent mistakes the bch version only accepts the new CashAddr format. Other updates: - - new domain added: https://bitcloak.ru/en - - api is now open to everybody, no more api keys needed. - - new section and api feature to check your mix status. Will continue to improve and update the service, BitCloak -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJa7cukXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDIwNUMxQTQ3QUQwNTA1MkFCQjQ1MTFF RkVGQjNGODg2RDM2MjQyAAoJEO/vs/iG02JCSq4QAMRNy4EhqDlwUkdiWCxubIkI SmPRWjm8z4schBqJahuLNoURJs/uU3fMZAznTu6Kj+3B0Cpm7n5A5EYmgjHBQqgi zu9iZAfZ1oJFewFgeusMf16IeVwiNH7lfK11r7KwxE68YEYTG/hRLntPoLseKf5e 31h2hvE5jr6+doEOHhlibPW1b8DI3IYy7Nm5Q4SwI8IanT8KIYQRJer+XAnv78K6 OuwAmaF/6nyV9Og4rfXs5KffTt7b6qJn6VnGlcbnTvSpW1l3q48EhWd8PAUB+I Y+7oBe6YnNtuVoQj6x8OU46xatn77EGlRDTuO1/hNLf82cc3uZiWg/YBV7afof9V k+MlWDfvjzcf0MirhWY4CGYsSP3lhcCL0rtI0nNc22lKbuWaZWd10hZehRUrVCMO 0vCqs/P5mbrPeIOVNEtOKBPKTsQYmfy9APnh3ld3j5E+B0J79fADmlF4hs4IX12d Pi3eQk0i7n8gcPwIrH83PxG1iPhNyDxUzoXdehu/S6+TaRQDFP1NvZSzCPMHnD2S 7q2TCWANrN7ZhXXbIbuMiij+Eq4UHylZNRO/MGzh+TPPyD/qJ9ZyvjOokAfnHQOY DiCwKZkK1BZOTGxUrWhKgF9Nes8i0A2NjeHWIhpx8LIz7XU4820p5y26VlaSO1s2 Lu8wk703x8Xzr8p5gNEK =SCz/ -----END PGP SIGNATURE----- 
submitted by BitCloak to btc [link] [comments]

Karatcoin App Features

Karatcoin App Features
Karatcoin is a digital currency venture looking to convey gold declarations to the Ethereum blockchain. The stage will digitize your gold possessions, at that point enable you to hold them in your Karatcoin wallet on your cell phone. You can unreservedly exchange Karatcoin tokens (KTC) and gold endorsements through the application.
Karatcoin will create a decentralized gold market application by enabling established gold traders and providers to tokenize the same metal under one crypto-asset token, generating a highly liquid and stable market.
Communicate Straight to the Blockchain within the Web.
Manage your gold products Check Blockchain Transactions Vote to elect the gold mines Top 50 Cryptocurrencies available 85 Currencies supported Live trading Fast Execution 10 technical indicators Detailed Market analysis Updated News SHA512 Security encryption Multi-platform available
😍 Join the revolution in crypto gold -> https://karatcoin.dreammy.io/register
Visit our website: https://karatcoin.co
White Paper: https://s3-eu-west-1.amazonaws.com/karatcoin.co/files/docs/KC_WP.pdf
#bitcoin #cryptocurrency #Ethereum #GOLD #ICO #EOS #cryptofever #CryptoNews

submitted by DBlackMoon to CryptoICONews [link] [comments]

The blocksize debate, the personal attacks against reputable members of the community, and the Craig Wright revelations are all part of a well orchestrated campaign against Bitcoin. Proof inside?

Uber TL;DR: Craig Wright, anonymously via a report relating to the PGP key from December, attempted to smear and discredit members of the Bitcoin development community, accused Bitcoin Core of hijacking Bitcoin by imposing a blocksize limit, attacked small-block supporters, and heavily promoted big blocks. I hypothesize that the on-going blocksize campaign and Craig are highly connected. Scroll down for a non-Uber TL;DR, or just read the whole thing (yes, its long :)).
First, some background. After the December leaks, a paper pertaining to disprove Greg Maxwell's (nullc) allegations of backdating the PGP key has been released by an unknown (at the time) author, titled "Appeal to authority: A failure of trust".
Abstract: In December 2015, a Motherboard article suggested that cryptographic keys ... were created using technology that was not available on the dates they were supposedly made ... in this paper we present evidence that disproves this claim ... In addition, a warning is rung regarding the onset of centralised authority in the control of bitcoin that has been achieved through Blocksize restrictions. These restrictions have led to centralisation of Bitcoin via the dogma of the core development team ...
In the recent Economist article, they mentioned the following:
As for the backdated keys revealed in the December outing, Mr Wright presents a report by First Response, a computer-forensics firm, which states that these keys could have been generated with an older version of the software in question.
While they do not explicitly state that this is the same paper linked above, what are the odds that two different papers were written to support Craig's claims? In all likelihood, Economist refers to the same "Appeal to authority: A failure of trust" paper, mentioning that it was written by a computer forensics firm named First Response.
Now, to the interesting part. Within the paper (supposedly written by an independent third party firm), we have the following text:
Generally, an appeal to authority is fallacious when we cite those who have no special expertise. This is of greater concern when we have an individual believed or purporting to be an expert who abuses trust. Even experts have agendas and the only means to ensure that trust is valid is to hold those experts to a greater level of scrutiny.
That very same text (the bold portion) is also mentioned in that same Economist article, but this time attributed to Craig Wright himself:
In an article in the press kit accompanying the publication of his blog post, he takes aim at Gregory Maxwell, one of the leading bitcoin developers, who first claimed that the cryptographic keys in Mr Wright’s leaked documents were backdated. “Even experts have agendas,” he writes, “and the only means to ensure that trust is valid is to hold experts to a greater level of scrutiny.”
This could mean one of two things: either that Craig wrote that report (and presented it as-if it was written by an independent third party forensics company), or that The Economist mis-attributed the text to Craig instead of to the First Response report. However, they already refer to this report earlier in the very same article (the second quote on this post) and attribute it to First Response. It is very unlikely that they later in the same article they would mis-attribute this report to Craig. In addition, what does a forensics company has to do with Bitcoin politics? Why would they even mention that subject? And how would they even have the knowledge to do so?
My conclusion is: this report was written by none other than Craig Wright himself, who later used similar phrasing for self-attributed texts in his press kit. He then managed to get First Response to sign-off on that report (or simply just lied about them being involved - would be interesting to try and check that).
Now, to the disturbing part. The author of this paper goes out of his way to attack and discredit Gregory Maxwell, over and over, throughout the entire article. He also repeatedly attacks the Bitcoin Core development community, the Bitcoin governance model, and those advocating for smaller blocks. I would say that 70%-80% of that paper is focused on politics, personal attacks against the Bitcoin technical community and heavy promotion for big blocks (later, in the Economist article, he's also advocating for 340GB blocks), in various phrasing that repeat over and over, with only 20%-30% of it actually being related to the technical questions surrounding the PGP key.
Here are some selected quotes (there are many more!):
We may either conclude that Gregory Maxwell understood what he was asserting and has intentionally misled the community in stating that the PGP keys referenced had been backdated, or that a Bitcoin core developer did not understand the workings of PGP sufficiently.
In addition, a warning is rung regarding the onset of centralised authority in the control of bitcoin that has been achieved through Blocksize restrictions.
There is an inherent warning in the foregoing discussion with regard to the growing power of individuals who may not fully grasp the full potential of the Blockchain but who nevertheless have a disproportionate level of influence.
In limiting the size of the Block, the issue of control and the use of the protocol is centralised to a limited number of developers.
The bitcoin core protocol was never designed to be a single implementation maintain by a small cabal acting to restrain the heretics. In restricting the Blocksize, the end is the creation of a centralised management body.
Several core developers, including Gregory Maxwell have assumed a mantle of control. This is centralisation. It is not companies that we need to ensure do not violate our trust, but individuals.
Gregory Maxwell has been an avid supporter in limiting Blocksize. The arguments as to the technical validity of this change are political and act against the core principles of Bitcoin. The retention of limits on Block size consolidates power into the hands of a few individuals.
The position that has been assumed by those seeking centralisation of Bitcoin for many years is to create an artificial scarcity within Bitcoin associated with the limits on the Blocksize.
Those with power need to be held to a higher standard.
We can clearly assert that the evidence Maxwell has presented to justify his assertions to Motherboard that the PGP keys is false. His motives in this remain a mystery.
This report also uses the strawman logical fallacy, attributing Greg with claims that he never made while avoiding quoting his exact words (instead, optin to quote the press's paraphrase of Greg's words). While Greg said that the algorithms weren't in wide use at the alleged time of the key creation, they repeatedly mis-quote him as claiming that it was impossible to generate such a key at the time. Based on this strawman, they build mountains and hillsides, claiming that they can prove their claim in absolute logical terms ("This is a binary outcome and there cannot be any other result. Either creating the keys was possible, or the evidence reported by Motherboard was unfounded").
That was what Greg actually wrote:
Incidentally; there is now more evidence that it's faked. The PGP key being used was clearly backdated: its metadata contains cipher-suites which were not widely used until later software.
This is what the report claims:
In the logical analysis of evidence, we cannot have contradictions. Where such a contradiction exists, we need to check our premises. In this process that we are exploring together, either we can recreate a similar key along the lines of the one Maxwell has stated could not have existed (WAS NEVER SAID! N.I.) and must have been backdated, or we cannot. If we can create a key using the GnuPG software from 2007 and add the attributes of the disputed keys to a newly created key pair, then Maxwell is wrong. If we cannot complete this process, then he was correct and the keys could have been backdated. This is a binary outcome and there cannot be any other result. Either creating the keys was possible, or the evidence reported by Motherboard was unfounded.
We see here the default hash list of “2.8.3” as Maxwell asserts is the only available choice. (WAS NEVER SAID! N.I.)
The importance of this statement is that Maxwell has firmly asserted that the algorithms, “8,2,9,10,11” have only been added from a later period in 2009 ... We have engaged in this exercise in order to demonstrate that the former statement made by Maxwell is incorrect.
This exercise proves that those algorithms that had been stated to not exist at the time within GnuPG 1.4.7 had indeed been implemented. Maxwell’s assertion is false.
That report is, of course, total and utter nonsense. The algorithms did exists in PGP (no one claimed otherwise), but there was no ciphersuite that combined them together. It was indeed possible to manually select that ciphersuite, the command to do so would look like that:
setpref SHA256 SHA1 SHA384 SHA512 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
There's no way that anyone would choose these exact algorithms under the exact same order before it was added as the default to PGP. Its important to note that the ciphersuite was chosen by the open source community after much discussions and knowledge acquired over time regarding the algorithms, which showed this combination to be the most secure. Foreseeing that this suite is going to be the state of the art, a few years before the PGP community figured it out, is extremely unlikely.
  • After Greg exposed Craig's bluff regarding the PGP key from December, Craig writes a report that allegedly proves his key wasn't backdated. It is published on late December '15 - Early January '16 (anyone has an exact date?).
  • That entire article is based on a strawman, and doesn't really prove anything. It shows that it could be technically possible to create such a key at the alleged time, but completely disregards the fact that the likelihood of that happening is practically zero.
  • He released this report anonymously, not attributing it to anyone.
  • He uses this opportunity to discredit Greg, repeatedly attacking his personal integrity and technical competence. He also attacks Bitcoin Core with claims of an hostile takeover by a "small cabal" that wants to control Bitcoin by restricting the blocksize. He smears the "small blocks camp", while heavily advocating for larger blocks. He does that using personal attacks and severe words pointed at highly respected members of the community. About 70%-80% of the report isn't related to the PGP key at all, but rather to politics and attacks.
  • In his press kit for the revelation, he attaches this report, this time attributed to a forensics company called First Response. In addition to the report, he attaches more attacks against Greg, which he does attribute to himself. The phrasing of his self-attributed attacks strikes an extraordinary resemblance to the attacks in the report.
Having read this report, I now believe that what we're seeing is another stage of a well orchestrated attack on Bitcoin, whose goal is to discredit reputable members of the Bitcoin community, create factions within the community and to sow distrust among community members.
This attack hasn't started now. The opening shot was the block size campaign, which was designed to spread toxicity and dissent, promote personal attacks against thought leaders and technical experts, and split the community into two opposing camps. The goal is to dissemble the human and social fabric of Bitcoin, to subvert our trust in the cypher-punk "leaders" of the bitcoin space and to create chaos and confusion, in order to prepare the ground for the second stage - an hostile takeover of the Bitcoin protocol development via a person claiming to be Satoshi Nakamoto, which will support this new development team and lead people after him.
I don't usually tend to be overly conspirative, but this report is highly disturbing. It has the very clear agenda of attacking Bitcoin Core and the consensus mechanism, while heavily promoting big blocks. We have appealing evidence that it was written by Craig, which also continues his attack as part of his press release. All of that leads me to believe that the blocksize campaign, the non-stop attacks against the Bitcoin development community and thought leaders, and the Craig revelation as "being Satoshi" are all tightly connected as part of an orchestrated attack.
And all of that follows repeating evidence of ongoing sock-puppets and rating manipulation within our online communities, Sybil attacks on the P2P network to create a false image of Classic support, and DDoS attacks. (interesting to note that voting manipulation was put into use with greater vigor during the Craig revelations, according to theymos - "there's substantial vote manipulation in /Bitcoin right now").
I truly believe that this is the real thing. We're witnessing an orchestrated full-scale attack on Bitcoin, by a well-organized entity with significant financial means. Buckle up!
submitted by shesek1 to Bitcoin [link] [comments]

Celebrating 20,000 subscribers | Lambo giveaway

The winning number was x0596x

Since no one guessed that number exactly, the closest number won, making phillipsjk's guess of x0608x the winning guess!

How can this be confirmed?

Using a hashing tool (e.g. Gtkhash in Debian), enter the text "596" with an HMAC of "canwestoptalkingaboutlambosnow?" and you will find the SHA512 hash matches the one in the witnessed post.

What next?

I will contact phillipsjk to arrange delivery of their lambo, and hopefully they will take some photos of it when it arrives.

Thanks everyone for participating in this, hope you had fun!

20k subscribers

As of writing this, /Monero is only 975 0 subscribers short of the big 2-0. That's a great sign for overall interest in this truly unique and important innovation to cryptocurrencies, much more important than an occasional spike in spot price.

The Giveaway

A long running inside joke for Monero users is that the Monero will enable Bitcoin latecomers another chance to get a Lamborghini. It seemed fitting a theme for a giveaway as any, so that's what I'm going to do: give one away here on the subreddit.
Since I'm not rich, we'll have to settle for a Hotwheels Lamborghini (USD $6 value!)

The drawing

Since I don't want things to be too complicated but still fair, I'll just ask that participants choose a number between 0001 and 2000. That's 2,000, not 20,000!!! 20,000 would take far too long and there may not be any winner at all!

Acceptable guess range is 0001 ~ 2000

Next, check the page for an existing number by first making sure all comments in the page are showing, then searching (CTRL + F) for the string x####x, where #### is your number.

Here are some valid number formats:


Here are some invalid number formats:

x2001x (0001 ~ 2000!)
If for example you choose the number 412 and post it as x412x, this would not be a proper guess. You should haved posted x0412x instead. That would suck to lose on a technicality right? Couldn't agree more! Get it right!

Secret number

I have already generated my secret random number from random.org (oooh, fancy!) to use as the hash string, and created a secret password for the HMAC, hashing it with SHA512. The resulting hash is:
Once we hit the 20,000 subscriber mark, the thread will close and I'll release the HMAC used for the secret hash as well as my generated number so that anyone can independently verify the hash and find the winner in the thread.

Do I have to provide you with my personal mailing address?

I am involved in Monero solely for its privacy protections. I respect people's right to privacy dearly. I would not want to ever know anyone's shipping information, and I believe it won't be necessary if ordering as a gift that someone can claim on their own. We will figure it out.

What if no one guesses the number?

Then the closest number to the right one will win. If two people are equally close (like 100 and 102 if the number was 101), then the user with the oldest timestamped guess will win.

What if two or more people win?

That's not possible, as if one participant happens to erroneously choose the same number as another participant, the participant with the oldest timestamp will have won by default.

How will anyone see this thread if it's not stickied?

Threads that are upvoted are kept near the front page. You can help keep it there if you like.

I saw you edit this post. Are you cheating?

To avoid confusion, I will edit this post regularly to update for announcements and clarifications as I see fit, but to make sure the hash stays intact I have also posted it here in this thread and will not edit that comment for later verification. I encourage others to respond to that comment with the same hash as well for added redundancy.

Wait, what if I edit my message then?

Editing your message for any reason makes your entry null and void. If you do it by accident, quickly post the same numbers agian in a new message and delete the old one after you're done. If you were too late and someone sniped your number, choose another. If you weren't aware someone sniped your number, posts with the same winning number are decided by their timestamp: the oldest one wins.

What if I make multiple posts to the thread, how would you know I wasn't cheating and covering my tracks later?

I wouldn't. Don't do it. Do not post multiple times in this thread unless it's in response to yours or someone elses' comments.
This bears repeating,

Do not edit your posts after making them. It will disqualify the post!

Do not post multiple times in this thread unless responding to your own or someone elses' comment.

If you want to make a comment, respond to your own post to make it. There it will function as a mini-thread for conversation.
Good luck everyone, and thanks for making this place friendly and enjoyable.
submitted by sn0wm0nster to Monero [link] [comments]

El algoritmo PoW (Prueba de trabajo)X25X: Llevando a una mejor evolucion la cadena de bloques

El algoritmo PoW (Prueba de trabajo)X25X: Llevando a una mejor evolucion la cadena de bloques

Gráfico de comparación de algoritmo
Puntos a tratar:
1) El problema
2) La propuesta original del algoritmo X22i
3) La solución - X25X: la evolución de la minería de prueba de trabajo
3.1 FPGA y resistencia mineros ASIC
3.2 GPU Desarrollo de software de minería
3.3 Resistencia cuántica
3.4 Cadena de algoritmos

Gráfico de comparación de algoritmo
Explicación del cuadro:
  • no de algoritmos de cadena
  • Ram usada por cada nombramiento
  • FPGA/ASIC Compatibilidad
  • Compatibilidad de Resistencia cuántica
  • Desarrollo en curso

1) El problema

La centralización sigue siendo una gran preocupación para muchos dentro de la comunidad de criptomonedas, así como para un número creciente de público en general. Bitcoin se fundó con la intención de crear libertad financiera para todos, lejos de los factores de control inherentes a la cultura de los bancos e instituciones financieras a nivel mundial. Como resultado, el concepto de descentralización se ha convertido en un tema preocupante que continúa creciendo en importancia, por muchas que son las razones que se discutirán en este artículo.
Específicamente, si consideramos el tema de la centralización en relación con la minería de criptomonedas, evitar la creación de dispositivos ASIC y FPGA es de suma importancia para promover la equidad y mantener un enfoque igualitario a largo plazo . En teoría, esto es posible a través de equipos de minería de CPU y GPU modestos y fáciles de obtener.
Sin embargo, muchos desarrolladores de criptomonedas hasta el momento no han tenido éxito en la implementación de medidas de igualdad sostenibles dentro de sus respectivos proyectos. Predominantemente, las monedas con grandes volúmenes de operaciones son explotadas por dispositivos de eficiencia mejorada, con GPU y CPU mineros que solo pueden obtener ganancias durante unos pocos meses o incluso semanas.
Los FPGA y los ASIC requieren máquinas caras y no pueden utilizarse para tareas adicionales, a diferencia de las GPU y las CPU. Además, la programación de FPGA es extremadamente compleja y requiere muchos recursos. Como resultado, estos mecanismos tecnológicos dan como resultado directamente la centralización de la minería, lo que reduce significativamente las recompensas que antes gozaban muchos. SINOVATE (SIN) ha renovado y continúa fortaleciendo la minería de Prueba de Trabajo (PoW) , reforzando y mejorando la visión original de Bitcoin de “Un CPU Un Voto”.

2) La propuesta original de X22i

El propósito del X22i Whitepaper original fue diseñar un algoritmo PoW (Prueba de trabajo) altamente eficiente , que proporcione una multitud de ventajas que aprovechen para los mineros de GPU sobre las granjas mineras comerciales:
  1. Hacer que la opcion de ASIC y FPGA sea mucho más difícil y costoso
  2. Permitir que los mineros optimizados de GPU se desarrollen rápidamente
  3. Permitir a los mineros de GPU puedan obtener la máxima eficiencia.
  4. Añadir resistencia cuántica
  5. Usar componentes comprobados, estándares de la industria , como sha-2 y sha-3 para permitir una seguridad óptima

3) La solución — X25X: la evolución de la minería de prueba de trabajo

X22i tuvo éxito en la implementación de todo lo anterior, pero para que los mineros siguieran recibiendo recompensas a largo plazo, era necesario evolucionar y adaptarse a las crecientes demandas de potencia de computación y eficiencia requeridas por los sistemas de hardware modernos. Esto se ha llevado a cabo a través del nuevo algoritmo X25X personalizado de SINOVATE .
Además, se requirió un cambio algorítmico para hacer que la producción de chips ASIC y el diseño FPGA sean mucho menos rentables, debido al corto período de tiempo permitido para el uso del producto. Además, X25X permite un menor consumo de energía para las GPU, ya que esta mejora depende del acceso aleatorio a la RAM que integra los ciclos de espera en el proceso de minería.

3.1 FPGA y resistencia de mineros ASIC

X25X persigue el objetivo de la resistencia de mineros ASIC y FPGA, mediante la implementación de múltiples funciones adicionales sobre cadenas de algoritmo PoW estándar como X11. Las características incluyen aumentar los requisitos de memoria en 24 veces , con X22i en 4 veces . Esto no es un problema para las CPU y las GPU, pero es mucho más difícil de mantener para los dispositivos FPGA y ASIC. La razón de esto es que requieren un uso de memoria RAM básica , que no ofrece ventajas sobre las CPU y las GPU , o que estos dispositivos deben aplicar más RAM interna, lo que aumenta el espacio de chip necesario.
Además, X25X tiene una nueva etapa de reproducción aleatoria , que trabaja en el búfer de 1536 bytes (para cada uno), con acceso aleatorio. Esto es para evitar que las optimizaciones múltiples anulen el propósito del búfer más grande, y también para evitar las actividades maliciosas de los mineros privados que buscan obtener ventajas injustas sobre los trabajadores honestos (por ejemplo, combinar múltiples algoritmos en uno solo, ya que la salida de cada etapa es necesaria para llegar al resultado final). Además, esto promueve indirectamente la escritura de código limpio para algoritmos, de modo que el código de fuente abierta sea más valioso tanto en términos de calidad como de tasa de hash. Esto es importante para la continuidad y viabilidad a largo plazo de la minería de prueba de trabajo (PoW).
Otra ventaja sobre los algoritmos PoW tradicionales es una cadena de algoritmos mucho más larga: 25 algoritmos requieren un espacio de chip mucho mayor para implementar toda la cadena, lo que es extremadamente costoso para los dispositivos FPGA y ASIC.
El plan más amplio para X25X es aumentar el tamaño de la cadena con más etapas de hashing, que se lanzarán periódicamente. Este enfoque obliga a los diseñadores de chips a revisar constantemente sus diseños, lo que aumenta aún más los costos y reduce el tiempo requerido para utilizar los chips con fines mineros. Además, hacer que la cadena sea cada vez más larga aborda las preocupaciones que rodean los futuros chips FPGA con mayor capacidad. Cualquier ganancia de eficiencia, así como la capacidad de estos dispositivos de encajar toda la cadena X25X en un solo chip se anularán .

3.2 GPU Desarrollo de software de minería

Como X25X es una cadena de funciones hash conocidas, codificar un minero GPU para este algoritmo implica principalmente codificar código fuente. Como se mencionó anteriormente, X22i vino equipado con muchas implementaciones, tanto privadas como de código abierto, con las etapas faltantes para llegar a la cadena X25X completa, todo disponible como código abierto. La nueva etapa de shuffle, que también se puede implementar en el código de GPU, se abrirá en breve.
Muchas fuentes excesivamente optimizadas no funcionarán o necesitarán ser fuertemente modificadas , ya que no proporcionan una salida completa para todos los algoritmos dentro de la cadena. Esto ayuda a aumentar el mecanismo de consenso descentralizado proporcionado por la cadena de bloques SINOVATE, ya que claramente la tasa de hash entre los mineros privados y de código abierto disminuirá.

3.3 Resistencia cuántica

Una preocupación creciente dentro del mundo de las criptomonedas también relacionada con la centralización, que potencialmente presenta una amenaza aún mayor que los dispositivos ASIC y FPGA, es la posibilidad de “romper” los algoritmos de hashing, que se utilizan dentro de las monedas de criptomoneda existentes a través de una computadora cuántica. El acceso a este hardware podría permitir enormes ventajas de eficiencia sobre la mayoría minera, manifestando la posibilidad de que se realice un ataque extremo del 51% en la red. Esto daría como resultado que una parte significativa de la cadena se revirtiera y aumentaría la posibilidad de doble gasto, con una sola entidad bien posicionada para asumir el control total de la Cadena de Bloques .
Para abordar este problema, X22i introdujo un elemento post-cuántico en la cadena llamado SWIFFTX, con criptografía basada en celosía. Este componente también se ha implementado en X25X:
“Sus principales características atractivas, entre otras (que no incluyen un ataque cuántico conocido en el momento de escribir este documento) son probablemente análisis de seguridad asintóticos rigurosos y eficiencia asintótica” ( https://eprint.iacr.org/2012/343.pdf )

3.4 Cadena de algoritmos

A continuación se muestra la lista completa de algoritmos de hash estándar integrados por la Cadena X25X, que incluyen la etapa de reproducción aleatoria única, los tamaños de entrada y salida correspondientes, así como el eventual relleno cero. SWIFFTX implementa un tamaño de entrada mucho mayor, que se extiende a través de las salidas de los 4 algoritmos anteriores. La fase aleatoria acepta todas las salidas de algoritmos anteriores como entrada:
  1. Blake (in: 80b, out: 64b)
  2. BMW (in: 64b, out: 64b)
  3. Groestl (in: 64b, out: 64b)
  4. Skein (in: 64b, out: 64b)
  5. JH (in: 64b, out: 64b)
  6. Keccak (in: 64b, out: 64b)
  7. Luffa (in: 64b, out: 64b)
  8. Cubehash (in: 64b, out: 64b)
  9. Shavite (in: 64b, out: 64b)
  10. SIMD (in: 64b, out: 64b)
  11. Echo (in: 64b, out: 64b)
  12. Hamsi (in: 64b, out: 64b)
  13. Fugue (in: 64b, out: 64b)
  14. Shabal (in: 64b, out: 64b)
  15. Whirlpool (in: 64b, out: 64b)
  16. SHA512 (in: 64b, out: 64b)
  17. SWIFFTX (in: 256b, out: 64b)
  18. Haval (in: 64b, out: 32b + 32b relleno cero)
  19. Tiger (in: 64b, out: 32b, + 32b Relleno cero solo para la etapa aleatoria)
  20. Lyra2 (in: 32b, out: 32b + 32b relleno cero)
  21. Streebog (in: 64b, out: 64b)
  22. SHA256 (in: 64b, out: 32b + 32b relleno cero)
  23. Panama (in: 64b, out: 32b + 32b relleno cero)
  24. Lane (in: 64b, out: 64b)
  25. X25X Shuffle (in: 1536b, out: 1536b)
  26. Blake2s (in: 1536b, out: 32b)

Los bloques de salida se barajan a través de X25X simple pero el código original. El resultado (también 1536 bytes de ancho) se pasa a Blake2s. Podemos ver la secuencia de manera grafica de lo antes explicado.


Únase a nosotros y permanezca atento a las próximas actualizaciones a través de nuestro sitio web y las plataformas de redes sociales:
Website Discord . Telegram . Bitcointalk . Twitter . Facebook .Linkedin.Team.YouTube. Reddit.
Telegram Rus — Telegram Chinese — Telegram AfricaTelegram Espanol — Telegram French — Telegram Indonesia — Telegram Italian — Telegram Turkish — Telegram Vietnamese
Author: Pallas Amit Kaushal
Traducido: Embajador comunidad hispana Musicayfarandula
submitted by sinovatehispano to u/sinovatehispano [link] [comments]

Bitcoin Cash is now fully supported by BitCloak mixer.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm happy to announce that BitCloak mixer now also supports Bitcoin Cash. You can select Bitcoin Cash from the menu, or add /bch to the base url. It comes with all the usual mixer features, pgp-proof and api included. To prevent mistakes the bch version only accepts the new CashAddr format. Other updates: - - new domain added: https://bitcloak.ru/en - - api is now open to everybody, no more api keys needed. - - new section and api feature to check your mix status. Will continue to improve and update the service, BitCloak -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJa7cukXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDIwNUMxQTQ3QUQwNTA1MkFCQjQ1MTFF RkVGQjNGODg2RDM2MjQyAAoJEO/vs/iG02JCSq4QAMRNy4EhqDlwUkdiWCxubIkI SmPRWjm8z4schBqJahuLNoURJs/uU3fMZAznTu6Kj+3B0Cpm7n5A5EYmgjHBQqgi zu9iZAfZ1oJFewFgeusMf16IeVwiNH7lfK11r7KwxE68YEYTG/hRLntPoLseKf5e 31h2hvE5jr6+doEOHhlibPW1b8DI3IYy7Nm5Q4SwI8IanT8KIYQRJer+XAnv78K6 OuwAmaF/6nyV9Og4rfXs5KffTt7b6qJn6VnGlcbnTvSpW1l3q48EhWd8PAUB+I Y+7oBe6YnNtuVoQj6x8OU46xatn77EGlRDTuO1/hNLf82cc3uZiWg/YBV7afof9V k+MlWDfvjzcf0MirhWY4CGYsSP3lhcCL0rtI0nNc22lKbuWaZWd10hZehRUrVCMO 0vCqs/P5mbrPeIOVNEtOKBPKTsQYmfy9APnh3ld3j5E+B0J79fADmlF4hs4IX12d Pi3eQk0i7n8gcPwIrH83PxG1iPhNyDxUzoXdehu/S6+TaRQDFP1NvZSzCPMHnD2S 7q2TCWANrN7ZhXXbIbuMiij+Eq4UHylZNRO/MGzh+TPPyD/qJ9ZyvjOokAfnHQOY DiCwKZkK1BZOTGxUrWhKgF9Nes8i0A2NjeHWIhpx8LIz7XU4820p5y26VlaSO1s2 Lu8wk703x8Xzr8p5gNEK =SCz/ -----END PGP SIGNATURE----- 
submitted by BitCloak to Bitcoincash [link] [comments]

AT&T has effectively banned Bitcoin nodes via utilizing private subnets. | hurricanewarn1 at aol.com | Sep 02 2015

hurricanewarn1 at aol.com on Sep 02 2015:
I was about to buy a VPS for Bitcoin, but I really do need Bitcoin Core for business reasons so I didn't give up. I once again thoroughly went through my computer and made sure there was nothing blocking 8333, a couple useful tools are CurrPorts and TCPView. I went through the router to make sure there was no block of port 8333. I researched everything thoroughly and was sure these were the right settings, but Bitcoin was still getting throttled every second and stuck in sys_sent, and python kept saying the target was rejecting the connection.
I finally stumbled upon subnet settings, and saw that I had a private subnet, one of the few IPs that are private on earth ( https://www.arin.net/knowledge/address_filters.html ). Uverse put all their customers on a private subnet by default. This made my computer not only hidden but unroutable for any computer on the Bitcoin network. That alone is enough to totally stop Bitcoin connections on any port, but they made it even crazier by generating a dynamic IP that changes all the time, so public IP was meaningless for my computer.
I switched over to a public subnet, and right there was a checkbox to allow incoming connections. My static IP showed for a minute then became dynamic/hidden again without me even touching anything. The final roadblock was AT&T; charges $15-30/month for a public static IP, which is obviously insane and actually one could argue that violates their own terms of service. So the router was still ignoring my public IP settings simply because I wasn't paying for a public IP, and intentionally changing the settings back. I asked for a free public IP and there was no response for awhile.
I found this article on cryptocoinnews while working out: https://www.cryptocoinsnews.com/isps-intentionally-blocking-bitcoin/ It's based on the first email I sent, and was displayed prominently on their front page. I posted a tweet publicly about it which referenced AT&T; ( https://twitter.com/turtlehurricane/status/638930065980551168 ) and believe it or not I had a static public IP and port 8333 was open about 1 minute later. I don't know if it was a coincidence cause I already messaged them to please do that an hour before, or if that article and tweet spurred them to action. The timing was so ridiculous I think it's the latter. Without twitter I probably wouldn't have succeeded, the technicians on twitter actually answered all my questions 24/7 unlike phone technicians which were clueless and trying to sell me a subscription for connection services help. And shout out to cryptocoinnews for making this public.
So to clarify, it appears AT&T; has not blocked port 8333 itself, but rather effectively blocked all ports via the private subnet, which makes the computer hidden and unroutable for incoming peers. Although this severely limits functionality and cripples the ability to run a full node and many other programs it is understandable, since it just about 100% prevents hackers from getting in, since they can't even see your computer. What isn't understandable is that AT&T; technicians did not inform me about this until I changed the settings myself, despite the fact it is a very obvious cause of ports being blocked. It's probably just ignorance since AT&T; has so many complex network settings it's hard to keep track of, although I have a suspicion that someone in their command chain is withholding information in an attempt to make them buy a $15/month connection service, and once they buy that another $15-30/month is needed to get the static IP.
As far as I know there is no easy to find info on the internet about private subnets crippling the ability to use Bitcoin. I believe this needs to be explicitly said in instructions for running a full node, maybe it wasn't a problem in 2009 but now it is a major issue. On default settings Bitcoin is 100% blocked, and most people do not have the time or motivation to fix this. I talked to at least 10 AT&T; technicians and worked on it 2-3 days straight, did not receive the right answer until I found it myself, although they certainly gave me some useful clues about how the network works.
I am very happy that AT&T; fixed it, since other ISPs like Comcast appeared even worse. I openly talked with them about Bitcoin and they showed no prejudice, might've actually made them more willing to help me cause otherwise they would think I'm a hacker.
tl;dr The good news is anyone with AT&T; can be a full node by getting a public static IP, the bad news is almost no one will figure this out unless we as a community make it well known. I guarantee node numbers will improve if this information is spread to everyone. Database size and computing expenditures is simply not the reason people don't run full nodes, it's because their ISP has made it just about impossible without shelling out nearly 100% more money per month. If you don't pay the fee AT&T; would never tell you about the private subnet, at least based on my experience.
-----Original Message-----
From: odinn <odinn.cyberguerrilla at riseup.net>
To: hurricanewarn1 <hurricanewarn1 at aol.com>; bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Tue, Sep 1, 2015 3:16 am
Subject: Re: [bitcoin-dev] AT&T; has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box
Hash: SHA512
Another note on this subject
to add to the stuff people have already
If you have the AT&T;
landline but don't use AT&T;'s standard internet /
tv (what they call Uverse)
offering - that is, if you prefer to use
some local internet provider - you are
probably better off (in terms
of avoiding not only this sort of
blockage/censorship but as well,
potentially getting a better privacy policy
that isn't going to be
like AT&T;'s long-term data retention). You can check
directly with
the various local small ISPs to see what their policies
specifically on ports and whatnot.
Ideally your ISP should let
port forward to SOMEPORTNUMBER for tcp and udp
(above may or may not
be helpful for some if you are using
decentralized markets)
have port 8333
(above is for bitcoin of course)
Supposing you have FTTN because you
are paying a local ISP for
internet service, and that local ISP has contracted
with AT&T; to be
able to provide service in an area where old-style DSL has been
out, thus your local ISP is essentially providing you AT&T; FTTN.
is Fiber to the Node, FTTN-BP is FTTN Bonded Pair). Even if a
local ISP has
its own privacy policy posted which is different from
AT&T;, everything is
subject to AT&T; data retention because the FTTN.
So get yourself a VPN (or set
up your own) for your connection. Tor
will run through the VPN.
observations - TWC stores your IP and other stuffs for 6
months or longer.
Same for Comcast. Verizon retains your stuffs for
18 month minimum, probably
longer though. Qwest/Century, 1 year.
Cox, 6 months. AT&T; retains for longer
than a year. This is just
what they are telling you, the reality is it's
probably longer due to
stuff like
G via bitcoin-dev:
I have been struggling to get port 8333 open all year, I
gave up
and was using blockchain for months despite a strong desire to
on Bitcoin Core, but now the issue has reached critical mass since
I'm using the python Bitcoin server module. I have literally spent
my entire
day trying to open 8333, I thoroughly made sure it was
open on the router and
computer and it's still closed. Strangely
enough I got it open for 30 seconds
once today but something closed
it immediately.
After hours of phone
calls and messaging AT&T; finally told me the
truth of what was going on, and
only because I noticed it myself
and demanded an answer. The internet is
being routed through a
DVcable box, and they confirmed the DVR also has a
firewall. To
make this even more absurd they refused to turn the firewall
because it is their equipment. So effectively they can firewall any
port they want even if the customer asks them not to, in the
unlikely event
the customer figures it out.
Perhaps this is the driving force behind the
inexplicable and
massive decline in Bitcoin nodes. Bitcoin is being censored
by the
ISPs themselves, and they won't even tell you that. I had to get in
touch with headquarters and threaten to rip it out of the wall to
get a
proper answer.
bitcoin-dev mailing
list bitcoin-dev at lists.linuxfoundation.org
http://abis.io ~
"a protocol concept to enable decentralization
expansion of a giving economy, and a new social
----...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe010862.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

ANN: Arionum (ARO)

We would like to proudly announce Arionum, a new cryptocurrency built from scratch!
Arionum was designed with the future in mind, in a market where the growth beats all expectations. Arionum aims to offer a secure electronic payments system that is able to scale without a degraded performance or a degraded user experience. It offers a fixed 0.25% fee on all transactions and it has a dynamic transaction limit per block, allowing it to keep up with a growing number of transactions at all times.
One of the main advantages of Arionum is that it was fully written from scratch in PHP, one of the most popular programming languages in the world. While php is not as fast as c++. for example, the high number of developers that can easily understand and develop PHP and the Arionum compensates for this. The main inspiration has been Satoshi Nakamoto's bitcoin white paper, but all the code has been thought and written by the developers to keep it's originality.
Arionum has been thought as a democratic and egalitarian coin, having no pre-mined coins, long mining period, no developer fees and an algorithm that advantages the average user with available CPU resources rather than mining farms.
Original Announcement: https://bitcointalk.org/index.php?topic=2710248.0
Name: Arionum
Symbol: ARO
Block time: ~ 4 minutes
Mining reward: Starts at 1000 and decreases by 10 each 10800 blocks
Mining time: 8 years and 4 months
Premine: NO Premine
Transaction fee: Always 0.25%
Block Hash: sha512
Mining algorithm: Argon2i + SHA512
Total coin supply: 545.399.000
Signature Algorithm: ECDSA's secp256k1 curve
DB Backend: MySQL / MariaDB
Whitepaper: https://www.arionum.com/wp.pdf
Download links
Official links
Official website: https://www.arionum.com
Block explorer: https://arionum.info
Forum: https://forum.arionum.com
FAQ: https://forum.arionum.com/viewtopic.php?f=13&t=11
Social networking
Twitter: https://twitter.com/ArionumCrypto
Discord: https://arionum.info/discord/
Official Pool: http://aropool.com
submitted by AroDev to Arionum [link] [comments]

xvultx4llltx7w2d.onion is 18 months online today

TLDR; The site that has been running nice and quietly on TOR for 18 months. We thought today is a good day to make the url public outside of our group of amigos.
PGP: 3DB6 FF02 6EBA 6AFF 63AF 2B6E DCE5 3FA2 EC58 63D8 Bitcoin: 18FNZPvYeWUNLmnS6bQyJSVXYPJ87cssMM TOR: http://xvultx4llltx7w2d.onion

Vultronix encrypted social network.

Abstract: Since time began, social interaction has always been private to those within the same vicinity. Today, however, much data is sent encrypted to a third party, gets decrypted on arrival and then stored among mountains of un-encrypted data, stored for financial gain creating giant honeypots. These giant honeypots of un-encrypted data are just too irresistible to those who have the power to request access.
We propose a solution to these centralized honeypots by enforcing client side encryption in such a way that the server has no access to the encrypted content, we believe this can be achieved via a mix of key hashing, PGP, AES and Onion routing. We acknowledge the current JavaScript anonymity problem and see a future where secure hardware will encrypt/decrypt the data for the user. We propose the below as a simple POC for inspiration of future development, open for all to copy, enhance and most importantly, to scrutinize.
1. What is the example? A truly client side TOR based encrypted centralized social network. Allowing users to interact anonymously online without the ability of the host to spy on the user. Trust with the host is established via signed open source Javascript. Everything is delivered directly from the host via TOR without any use of CDNs.
2. Centralized over decentralized? The greatest problem available to implementing encryption to the masses is user experience. We developed Vultronix to allow the user to interact with others securely via a familiar feeling platform. More experienced users can download the code and setup their own .onion domain, further removing the risk of a centralized authority.
3. Registration The user is required to fill in 3 fields. For familiarity we've named them the following - Email address, Password and Words list. The user is not required to enter their actual email but is encouraged to generate a string with a lot of entropy; it is acknowledged that the less experienced user will probably make up an email address, both the password and words field should be as random as possible. The entropy of these 3 fields is on what the user's encryption depends.
Note: as the system is not decentralized, the logins are only available to brute force attack by the host or if/when the database is compromised and dumped online. To achieve the best security a password tool should be used with 3 very random strings. A more user friendly solution is to make up a very random but easy to remember email address via a random mnemonic seed generator similar to BIP39, a difficult password the user can remember and a short word list.
Given a user selects the following log in details which, let's assume, were created by a BIP39 generator. + email: [email protected] + password: liquid sketch husband + Word list: shove proof dismiss gauge
The above contains 12 completely random words.
The browser will concatenate these to [email protected] sketch husbandshove proof dismiss gauge This value would then be hashed, creating the following hash. 90bc6ba57145e2116ea10d136ec49061e9a15c5694b171ba1e5753ab02e141e4
This hash is hashed forward 5001 times, on the 2000th hash the sha-256 becomes a sha-512 hash in the following fashion. SHA512(2000th hash + 2000th hash) and is stored momentarily as the "loginHash" variable. The loop continues on with all further loops taking a different path that can't be reached by hashing forward the login hash. The 3000th hash is saved as the "passphrase" variable The 4000th hash is saved as the "encryptionKey" variable and the 5001st hash ends up being Hashed again for good measure. loginHash = SHA512(loginHash + 5001st hash);
At the same time during registration the user's browser will generate a 4096 PGP key pair. The PGP password is the "passphrase" variable. Both the passphrase and the encryptionKey never reach the server. The PGP pub/priv keys are both AES encrypted with the encryptionKey as the password and sent to the server.
Note: The PGP public key is never sent to the server unencrypted as we don't want someone with access to the Database to be able to analyze who is friends with who.
Also generated at sign up is a UUID, this is AES encrypted as well.
Sent to the server on sign up is the following. + encrypted: PGP public key - AES encrypted string. + encrypted: PGP private key - AES encrypted string. + encrypted: UUID - AES encrypted string + loginHash: SHA-512 hash.
Upon signing in, the user fills out his profile. This data (including any images uploaded) is encrypted client side by the user, the user encrypts a copy to himself using his own PGP public key, which is currently decrypted in his browser session, then encrypts this again with his AES encryption key.
4. Login A user will login with the same credentials used at sign up, the loginHash will reach the server and the server will find a match and send back the user's encrypted credentials. The user's client will decrypt these with his "passphrase" and "encryptionKey", neither of which have ever been sent to the server.
Note: If a MITM intercepts a user loginHash over the wire, the MITM will be able to retrieve the encrypted data from the server, but will never be able to decrypt it, and won't have any further access to the user's data.
Once the user decrypts his credentials data, he'll have access to his UUID, the client will then request from the server an encrypted friends list object, the client will decrypt this and populate client side his friends list. This will contain the public PGP key of each of his friends along with a friendship key unique to each friendship as well as a generated shared password unique to each friendship. The client will also send requests to the server to look for feed updates, inbox messages, new friend requests and accepted friend requests etc.
5. Friend requests To keep friendships private, a user must send another user a friend request token. Since everything in the Database is encrypted , it isn't possible for a user to simply look up a friend. Via the friend request page the user will fill out a short message and press a button. The user is presented with a SHA-256 hash that will expire after 2 weeks. The user simply needs to pass this hash onto his friend via other means of contact, the friend then enters the hash into the friend request page, the friend will then see a thumbnail of the user (or whatever logo the user has chosen for his profile picture) followed by the short message the receiving friend should recognise, e.g. "Hey Alice it's Bob, please accept my friend request", Alice accepts the friend request and they're now friends, Alice won't have access to Bob's profile page until Bob next logs in.
Behind the scenes, the following happens: Bob's message is concatenated to a generated UUID This string is hashed many times like the loginHash An object is created containing Bob's following encrypted data: + PGP Pub Key + friendshipUUID unique to this friendship + sendersFriendshipUUID + acceptersFriendshipUUID + Bob's Name + Bob's thumbnail (all images are converted to base64 strings in the browser then encrypted/decrypted client side) + Request message etc.
This encrypted data is sent to the server, the friendship token is equivalent to the final login hash that a user generates on login. Bob doesn't, however, send Alice this final hashed token, he sends her an earlier version of a hash. Alice will enter this hash, her browser will roll it forward creating the decryption key and eventually the friendship token that resides on the server, her client will send this to the server, the server will respond with the encrypted data. Only she can decrypt the data as only she has the earlier hash of the friend request token.
She decrypts Bob's friendship data, adds it to her FriendsList data, encrypts the latest copy and sends it through to the server for safe keeping. Alice's client will now create an encrypted accepted friendrequest object submitting it to the server. Alice will then use Bob's PGP key and their new friendship password they share to double encrypt her profile to Bob.
When Bob logs in next (or if currently online via web sockets) he will receive the accepted friendrequest token. Bob's client will then do what Alice's did and update his friends list etc and send a copy of his profile through to Alice. Bob and Alice will now see each other's new status updates, album updates etc.
Note: A new friend can never see old status updates, this should be considered a feature.
6. Chat and instant messages Users can see when other users are online and chat via web sockets, they can also send offline messages via their inbox. These messages are double encrypted. If Bob sends Alice a message, the following happens: Bob's client will encrypt the message using Alice's PGP public key and a copy using his own PGP public key, he'll then encrypt both using their shared friendship password and place 2 entries into the database. If Alice is online the server will push up her messages instantly via web sockets, if not, she'll see the message the next time she logs in, she'll notice this as the inbox icon will be red to signify unread messages.
Note: If a user has Vultronix open in another tab, he'll hear a sound when a new message is received as well as a keyboard sound when his friend is typing.
7. Group invites Groups allow shared users to associate online in private without having any access to who other members of the group are, users can also send private encrypted messages to other users of a group in full privacy. Anyone can create a group. On group creation the group's admin client will generate a random password, the admin can give the group a logo and message etc. The admin can then create a group invite token and the recipient of the token can sign up to the group in the same way that a user would accept/decline a friendship request. Once a user is a member of a group, he too can invite friends. All of these people will share an AES encryption key which they'll get via decryption of the encrypted invite request. Each user will be able to download a shared membership list of the group, which will not be able to identify any users. This list will contain user PGP keys that are used when a member sends another member of the group a private 1 - 1 message.
TLDR; Everyone in the group can start threads, comment in threads, invite new friends etc, no one outside of the group will even know of the group's existence, the group's description, name, members list etc. All of it is encrypted and private. No member will know that other members have privately messaged each other. No member will be able to find another member's profile. However, if they wish to be friends, they can private message a friendship request token. Members can have their own groups and private message friend request tokens through to members to join other private groups.
8. Status updates When a user creates a new status message, the user's friends will see the message appear in their feed either in real time if they're online, or the next time they login. When a user fills in the status box, the user can optionally add a photo or youtube video link (caution: external services could be used to track you) and then press save. After the user saves the status the following happens:
The status is encrypted and saved to the server. To reduce client computation time as well as server storage, only one copy of the status is saved to the server. The client will encrypt and upload a new encrypted message for each of his friends, this message will simply hold a AES decryption key and a status ID, the friend's client will then request this status and decrypt it. All of the user's friends can comment on the status, only the user will be able to click through to their profiles. It's impossible for user's friends to be able to interact with each other outside of their shared friend's status comment box.
9. Shops Private encrypted shops would be easily implemented via the following: The shop owner would setup shops in a similar way to setting up a group, inviting customers to his private shop with tokens. He could send these tokens to his friends in his friends list or new people he meets in a private members group via private message. This would allow the shop owner to sell to only people he trusts, e.g. his grandmother or aunt etc. The shop owner would have complete privacy. The shop owner would keep control of all his bitcoin private keys. He would enter a list of bitcoin addresses, then add items to his shop. Upon adding an item, the client would submit an encrypted copy of the item to the server for each customer of his store. Customers would browse his store and see an item, the item would have a bitcoin address to pay to. The customer would enter a message, be it his email address for a digital order or a postal address for a physical order. He would then pay to the bitcoin address and hit submit. The shop owner would see a page with orders and see the email address and manually check the bitcoin address has funds.
This would allow sellers and buyers online to have great protection, providing they're buying/selling from people they trust. If the server is hacked and database stolen, no one will have access to any bitcoin as no private keys would ever be on the server and everything is encrypted, so no one would know what shops even exist, unless they have a personal invite to that store.
This kind of private store could be very useful for people living under oppressive regimes. If, for example, someone wants to learn about Capitalism and would like to buy Capitalist literature but they live in a censored Communist state, they could access via TOR and order anonymously without ever having to worry about the site being hacked and their government going through the data and heavily punishing them, possibly with death. They would be at risk though of the literature being confiscated in the mail so they'd be better off to order a digital copy and have it emailed or, perhaps, the seller could simply copy and paste the text into a private message to the seller.
The possibilities would be endless for the above, we have not implemented this though as we're not sure of the legality. If someone decided to sell something illegal and law enforcement wanted information on the buyeseller, we would never be able to retrieve it from the database. If, however, they managed to become a member of a store, they could perhaps tell us a UUID that might represent the store and we could delete the shop at their request, but not much else. For this reason we're not going down this path, it is however fascinating to think of.
We'd predict that OpenBazaar would one day offer the ability of hidden stores, not just the ability to route via TOR. For any OB users we've added a OpenBazaar field to the member profile info page.
The goal of this project is to show that client side end to end encryption is possible for intermediate users and not that difficult to implement. We hope this inspires people to build something similar and better or, perhaps, fork the code and fix some bugs etc.
We appreciate your time, if you enjoyed this or atleast appreciate our effort, our bitcoin address is below. Bitcoin: 18FNZPvYeWUNLmnS6bQyJSVXYPJ87cssMM
PS: The code will be uploaded to a public Github profile this week.
http://xvultx4llltx7w2d.onion Latest version: Content hash: 1aa450c4a4bef1ddee92d6572f81aa14baad959402563064f0ff81e6f42b69d9 lib.js hash: 8704461878818f5f00f18c61789e03c1b90bfc07bc21a15301ce876e7f71829c
submitted by Vultronix to onions [link] [comments]

⚠ Roadmap for a new /r/PGP ⚠

This sub has not lived up to its potential. Here's a proposal for how to maximize the usefulness of /PGP. We have a brilliant opportunity to be leaders of crypto on reddit. The world is waking up to the need for more than transport layer encryption (HTTPS/SSL), craving complete software layer encryption as well for all chats, emails, documents, and general communications. Respect for personal responsibility and privacy is on the rise thanks in part to whistleblowers and technological phenomenons such as Bitcoin and Tor. People the world over are eager to do their parts to mitigate against surveillance overstepping. It's going to take a bit of practice with technology and good safety habits, but these skills will prove to be vital to survival within a decade just as much as driving or cooking are now. Let's stop pretending PGP/GPG is a complicated optional solution, and instead push for safer online experiences for everyone with unified security standards for everyone, starting with here at our home on reddit. We are past the point where authority figures should ever have a right to tell us that we don't need security. With mobile apps and secure browser plugins built for PGP/GPG web interaction, there is no longer any excuse to post online without it. Let's be the sub that brings reddit up as the strongest crypto community on the internet. For those who appreciate good OPSEC, PGP/GPG is crucial to our livelihood. For the rest, you may be just curious or excited to learn something new and powerful. That's excellent! But as with all things security, while there is no such thing as perfection, daily practice is essential. Such practice should be as mandatory as rudimentary arithmetic. Let this sub evolve into a virtual practice haven of encryption and key signing. /PGP would like to evolve into a subreddit where... ..public key fingerprints in flair are required in order to post a thread ..requiring PGP/GPG key signing for all posts from users with flair (having the flair in the first place would denote a functional command of PGP/GPG) ..encrypted PGP/GPG threads are allowed with appropriate titles ..other subs follow our example, especially marketplace and reputation based subs who have a problem with fraud and hacked accounts ..irregular live threads are hosted to answer questions from all users no matter how simple or complex by the best in our community ..occasional AMAs from PGP/GPG/cryptography field veterans are hosted ..PGP/GPG/cryptographic news aggregates, so long as it is related to key pairs and signing ..we can all learn from each other and make this technology as common as a door lock To accomplish all this, it's going to take the help of each and every one one of you. If you'd like to support, here's what you can do! * Apply to be a moderator in the moderator application thread * Vote for a theme in the theme thread * Install and regularly use your favorite PGP/GPG solution in this sub and start spreading it across all of reddit * Remind users who don't sign or encrypt their messages what the mission of this sub is * Help other users in this sub as much as you can * Ask questions whenever you don't know something. Discussion is helpful for everyone and no topic is too small * Recommend new designs, policies and missions while challenging existing ones to regularly keep everyone honest and educated * Use encryption everyday What do you think about this proposal? Your feedback is important and will shape the direction of this sub. PGP/GPG signed messages will be answered first. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW1DH6AAoJEJbPAWN5VC4Vb6cP/3b9vNYk+czC1GNwQoK+mv+x A4DNwwjvbqR63MHkSTxFpU31WJx6kDuls3ZfwD/qA57/ZJlGmDzmrAwvsCkisej1 FUrqH/NJK0WVPuKeYeF4bkBiFDSjdy+gjibzL2EBxhYwh4Gf2Pv2DqdEuja7NLjC M0HsvuLwu9DEgRPXT6Y8Sy7tA6mb/kRrjtrrtmlNWoVWx936Y14W58/sgoMGHpAr CqTi2zXmFjsf35pMR8hTa57ksVBsiZGH6QwT3GOv5NM80NglY4HAA+d9gwC0cRUY XFT8MsxfBotRSIVRvWwMw3p1Fi4iEPOeUlI0utiSEgtzgwm3A5QSDxc24/guFnWm ZrPsfaVRxOZbAM0aN1bueXOeC5TwCnPcE3dMnrxzl5aqHIahukmqPQmoPRBNqHRC lV+Arx72IpSN37vi9PGWXLGzq/iNa9nAQal1gMXT0pJ2kXe1IOkKZe6qlgCVj387 Tr8OFcgp/CPBN/+ivi6H07kS2trwHMi6FII1QXtrY0xK9ppUnIYuxZ8S9s7CLGch OEnSzOgQvY6S6nTw30W4T7Qkh0VYDNvJa+ejR4FC6F42aKKZZbiWnBybwOGBAFvV tpYkD6gvG6OXIxpmJHFPxs1rcI8cGmVq2YNquHNQy0AZqfbg2QJxbE37NbeI+IdY kn42EmxpyS8Elpzul9yI =+5Jj -----END PGP SIGNATURE----- 
submitted by 1MerKLe8G4XtwHDnNV8k to pgp [link] [comments]

Incentives to run full nodes | odinn | Oct 04 2015

odinn on Oct 04 2015:
Hash: SHA512
Some background on this....
A very long while ago I posted to the bitcoin-development mailing list
some ABIS concepts having to do with microdonations:
And an interesting post (which led me to explore BCN) via nullc:
(posted 1 & 1/3 year ago).
Anyway, some long while ago this discussion came up about "Incentives
to run full nodes," and the last post in the thread was here:
Since that time, some new developments have come to light which the
participants in that thread may find interesting;
Please see in part,
This presents a working implementation in BCN; the concept as
implemented there is arguably viable in BTC as well.
Please explore, play with, discuss, etc.
Potentially relevant...
"Incentivizing the running of full nodes"
(However, the issue to which I referred here is now closed)
View whole thread:
On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org
> wrote: From the
point of view of a
wallet, it's not very secure to use Hearn-style SPV mode, and
volunteers running full nodes doesn't help things. Sybil
attacking the IP address space is pretty easy in comparison to
aquiring hashing power sufficient to create false
confirmations, so any attacker able to do the former will
likely be running the full node you're connecting too anyway.
Ultimately, Hearn-style SPV is a close approximation to just
trusting anyone with a non-trivial amount of hashing power.
(and getting that is surprisingly easy, e.g. w/ SPV mining)
Can you explain how the spv node fails against an attacker with a
non-trivial amount of hash power where a full node doesn't? To
attack an spv wallet that is waiting for 6 or 10 confirmations,
you would not only need to Sybil them but also summon a massive
amount of hashing power to create a chain of headers (while
forgoing the opportunity to mine valid blocks with that hash
But could someone with that much hash power not Sybil a full
node and give them a chain for valid blocks (but on an orphan
fork)? The failure model doesn't seem specific to spv to me.
_______________________________________________ bitcoin-dev
mailing list bitcoin-dev at lists.linuxfoundation.org
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011359.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Defending against empty or near empty blocks from malicious miner takeover? | CANNON | Mar 24 2017

CANNON on Mar 24 2017:
Hash: SHA512
When the original white paper was written the idea was that nodes
would be miners at same time. That the distribution of mining power
being mostly on par with the distribution of nodes if I understand
correctly. The problem we face now I fear, is the mining power
becoming centralized. Even if every bitcoin node invested a $1000
into mining power and mined at a loss, it still would not even
make a dent in hash distribution. Currently there are around 6000
known nodes. If each node invested $1000 for say 10 ths of hashing
power. At current hashrate of around 3,674,473,142 GH/s this would
only make up %16 of hash power. This is out of balance as while
nodes are distributed mining power is becoming very centralized
due to the creation of monopolization of ASICs. The problem we
are facing is a small group of a couple people whom control a
large amount and growing of hash power. At time of this writing
it has quickly risen to 39% and at current rate will soon become
50% of hashing power that is controlled by a small group of a few
people. Their intentions are too hijack the bitcoin network to a
cryptocurrency that suits their dangerous agenda. Dangerous because
their plan would centralize power of consensus as I understand it,
to themselves the miners. Dangerous also because the code base of
the attempting subverters is buggy, insecure, and reckless from a
technological standpoint. Even though they only have very minute
amount of nodes compared to legitimate bitcion nodes, the danger
is that they are very quickly taking over in mining power. While
it is true that nodes will not accept invalid blocks that would be
attempted to be pushed by the conspirators, they are threatening to
attack the valid (or in their words, "minority chain") by dedicating
some mining power soley to attacking the valid chain by mining empty
blocks and orphaning the valid chain. So even though the majority
of nodes would be enforcing what blocks are valid and as a result
block the non-compliant longer chain, the conspiring miner can simply
(as they are currently threatening to) make the valid chain unuseable
by mining empty blocks.
If a malicious miner with half or majority control passes invalid
blocks, the worst case scenario is a hardfork coin split in which
the non-compliant chain becomes an alt. However the problem is that
this malicious miner is very recently threatening to not just simply
fork, but to kill the valid chain to force economic activity to the
adversary controlled chain. If we can simply defend against attacks
to the valid chain, we can prevent the valid chain from dying.
While empty or near empty blocks would generally be protected by
the incentive of miners to make money. The threat is there if the
malicious miner with majority control is willing to lose out on
these transaction fees and block reward if their intention is to
suppress it to force the majority onto their chain.
Proposal for potential solution Update nodes to ignore empty blocks,
so this way mined empty blocks cannot be used to DOS attack the
blockchain. But what about defense from say, blocks that are
not empty but intentionally only have a couple transactions
in it? Possible to have nodes not only ignore empty blocks,
but also blocks that are abnormally small compared to number of
valid transactions in mempool?
For example would be something like this:
If block = (empty OR <%75 of mempool) THEN discard
This threshold just an example.
What would be any potentials risks
and attacks resulting from both having such new rulesets and not
doing anything?
Lets assume that the first problem of blocking empty or near empty
blocks has been mitigated with the above proposed solution. How
likely and possible would it be for a malicious miner with lots of
mining power to orphan the chain after so many blocks even with
non empty blocks? Is there a need to mitigate this?
If so is it possible?
Time is running short I fear. There needs to be discussion on various
attacks and how they can be guarded against along with various
other contingency plans.
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
If this matters to you, use PGP.
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013772.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Introducing IHB.io and yet another decentralized open source way that block chain technology will change the world.

tl;dr: check our our new website (ihb.io). privacy overreach is getting out of control and we are attacking this problem by disrupting a multi billion dollar industry.
Dear Bitcoin Community
I hope all is well and this message finds you in good spirits. This is probably not how you should rebrand, but at the end of the day when we started this company one year ago we set out to do something different and we are sticking to our plans.
Phase 1 is over and we are almost ready to move on to Phase 2, but that requires a little input (and hopefully help) from the community. After all, if we don’t have your trust and buy in, we may as well shut down.
For the past 12 months we have attracted 67,000 regular readers who came to our old site ihavebitcoins.com to read our content and look at our market data.
Our analytics also told us:
*Many of us love using Tor. *Many of us love to clear their cache (daily). *Many of us are tech savvy and use high end devices as compared to the average person. *Many of us are from some of the most beautiful Tier 1 cities in the world. *Many of us use Opera and Linux systems more heavily than we have ever seen. 
A lot of people in the community had web behavior that trends towards being security and privacy conscious. Because of this we removed the google analytics cookie and we hope the tradeoff will be worth it.
We know what we did and yes it is so painful seeing our Alexa rank disappear and not get any feedback about site statistics.
We are going to be 100% cookie free. No more annoying popups for our European readers.
*Coindesk 8 *New York Times 25 *Wall Street Journal 57 *NewsBTC 4 *XAPO 6 *Hive Wallet 1 *Coinbase 5 *BTC China 1 *Bitstamp 1 *BTC-e 2 *The Guardian 15 *Drudgereport 29 *Bitcoin Magazine 3 *Coin Telegraph 2 *Crypto Coins News 1 *Bitcoin Foundation 2 *Wikileaks 0 *Business Insider 37 *Huffington Post 25 *BuzzFeed 23 
We like the above news sites and products and are in no way knocking them. There is no alternative so we understand why they are using cookies, but 57 cookies? What are you planning to do, rob a house? Do you really need to know what bank your readers use or when they are looking to purchase a new car?
But in regards to digital marketing, they are essential. Without them, websites would have no avenue of dealing with the largest ad network in the world, Google. Digital ad spending in 2013 was $119.8 billion worldwide. Google’s share of that, according to its 2013 annual financial reporting, was $50.57 billion.
Our Solution
IHB.io has a desire to make money, and we need it to keep doing what we are doing (it is not cheap), so we are working with the Mastercoin protocol to implement an open sourced ad based system that will tie a website’s proprietary server side IP data to web visits and requests pulled.
In a simple non cumbersome manner (still working on the UI for this) we want have you guys (if you choose) give us your public bitcoin address. That address key will then be associated to your specific IP address and if your address changes or if you access the site from another IP you will see a red light in the top right corner, which if you click on, you will be prompted to give us your key again so we can associate the new IP with your public bitcoin address.
We want to create a smart contract on the blockchain with advertisers who will then pay a separate address for the privilege of advertising to a demographic that we believe is affluent, educated, possesses an above average intellect that also happens to be in the coveted 18-34 demographic. Each contract can be unique to the advertiser's needs and the payouts are made if only the required outcomes for it are successful. After the payout is made to the address, the revenue will be split amongst participants. All of this will be public.
In return for your assistance helping to change the paradigm of digital marketing, we want to give our readers a share of the revenue earned. We believe we can convince select advertisers to adapt this system because the Bitcoin demographic is too valuable to ignore. It is no coincidence that all major publications regularly write about Bitcoin for SEO. In the journalism business those articles generate a lot of traffic. At the same time that mainstream media tells us Bitcoin is going nowhere in an article, they are making money from it and in many cases, us directly (judging from the well written comments left on some of these stupid articles).
The whitepaper is almost complete and we will publish it in the coming weeks. We are still figuring out the method for encrypting the IP data so we even we don’t have access to it and making sure it can't be gamed. But basically we want to move towards an opt-in system where users can still maintain 100% privacy.
The new ad network will be:
• Trustless and 100% open source • Secure distributed data sharing that is 100% private • A robust and scalable form of coordination amongst advertisers and websites.
Because of this we have decided to rebrand as IHB.io. It is much easier to recall and type than ihavebitcoins.com, and our plan is to never have a cookie on our site EVER so we can’t count on a lot of the tools that usually bring up your organic traffic.
In our lifetime humans have given up so much privacy that it scares us. We get really worried when we hear the director of the FBI attack Apple and Google’s encryption the way he does. When did we lose our right to private communications? If Paul Revere was tracked on his horse, I can guarantee you the English would have won the revolution. After all he was a terrorist.
We hope this will help Bitcoin as it provides yet another decentralized solution that the block chain can solve and also returns our right to privacy at the same time. It reduces the need for huge server farms and gets rid of the middle man taking a cut. We want to give that cut back to you.
In our opinion, good journalism is being tainted by technology and the need to get views and clicks. Editors must write the catchy headlines and do the stupid Top 10 this and Top 10 that articles to get clicks. That will never go away, but hopefully there will be a clear distinction in the incentives going forward. After all, we basically vote with every click, and we all know the Kardashians are winning on Yahoo.com.
We can’t ask you for an upvote, and we don’t want to collect any of your private data from the very beginning of this experiment, but we do need to get an idea of interest in our Open Source AD Network and we also need a whole bunch of beta testers for this model to be proven.
If you are interested in participating in this beta please leave us a message in anyway possible, Google+, Facebook, follow us on Twitter or comment on this Reddit post. We are very open to feedback from the community and if someone or organization wants to help us with this open source project we would love that as well. You can send us an email to [email protected]
Thank You. IHB
ps. if nothing else, we would appreciate feedback on our new site design. we are most interested in finding out about load times and optimization for your screen. if something is off or did not render properly, please leave a comment with the issue and what device, you were using.
“In the very first month of Indian Opinion, I realized that the sole aim of journalism should be service. The newspaper press is a great power, but just as an unchained torrent of water submerges whole countrysides and devastates crops, even so an uncontrolled pen serves but to destroy. If the control is from without, it proves more poisonous than want of control. It can be profitable only when exercised from within. If this line of reasoning is correct, how many of the journals in the world would stand the test? But who would stop those that are useless? And who should be the judge? The useful and the useless must, like good and evil generally, go on together, and man must make his choice.” Gandhi -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJUUX+YAAoJEPkg5niIBlAYG/QH/RpxFCNHfluXjDytgpovyaxH 6nJpVSXQGArdqdHJJIoeRcltHKLX0F4P5Z5qpezUZjW4GbyCz4KBi4iQC6WFmO Eq+Woed5+OQwOE2mXocwO7EzT/+h0MJG7rW4uTIEJulozj56tXszEX7NX8G6w5Ym NLr7F9OcIL5UPo5QWoWXJS30NGi0PDU9EngwsTm/prnBOc/QD18WzhjTSyTbEk6K kNimfgdvb4c4NtFLfr1/vaNt+wxxCaQPYqTxrnbZntBMfFMJXUvGe1sjx86NVHmf VgSyuNty3hx6TcqtpLLYxvalTA8B6nHbD/cHshxklhE/SUdruKBD9lPbdZBlDKQ= =N0gX -----END PGP SIGNATURE-----
IHB Public Key
submitted by theBitcoin_CEO to Bitcoin [link] [comments]

SHA-512 calculator Hashflare Bitcoin Mining  Just Bought 10 T/H's of SHA 256 Cloud Mining Týden 3 - hash sha512 What is a Bitcoin hash and SHA-256 - YouTube Bigeathash:Encrypt and Decrypt hash

SHA-512 is the same as SHA-256, however, it is 50% faster and uses a 64-bit platform, rather than a 32-bit platform.It uses more memory and more power. SHA-256 is a member of the SHA-2 cryptographic hash functions designed by the NSA. SHA stands for Secure Hash Algorithm. Cryptographic hash functions are mathematical operations run on digital data; by comparing the computed "hash" (the output from execution of the algorithm) to a known and expected hash value, a person can determine the data's integrity. Bitcoin wird mit Quantencomputern fertig. Um eine wirkliche Gefahr für Bitcoin zu werden, müsste ein Quantencomputer die zweite, weitaus wichtigere Kryptographie knacken: Die für das Mining verwendete SHA-256 Hash-Funktion. Das Fundament von Hash-Funktionen ist die Unumkehrbarkeit, sie sind also um ein vielfaches komplexer als andere ... All things bitcoin and altcoin, featuring cryptocurrency mining profit calculators, news, live charts along with exchange, miner, wallet and card reviews. News und Foren zu Computer, IT, Wissenschaft, Medien und Politik. Preisvergleich von Hardware und Software sowie Downloads bei Heise Medien.

[index] [50184] [37421] [49771] [28644] [9901] [25562] [8089] [24354] [43392] [36948]

SHA-512 calculator

For BU CS546. Example of how SHA-512 is computed for given strings. This video is unavailable. Watch Queue Queue. Watch Queue Queue "HOW to Decrypt PASSWORDS(encrypted in functions like MD5,SHA256,SHA512..etc) in Kali-Linux" Using HASHCAT TOOLS. md5 hash link: http://www.md5.cz/ sha512 ha... Dnes se budeme bavit o hashování a také dalších věcech které jsem přidal na web . Mimochodem u změny hesla , tak pokud si zakládáte účet tak ho máte automaticky na novém hashi (hash ... How to quickly verify MD5, SHA1 and SHA2 (SHA256, SHA384, SHA512) Checksums in Windows 8 and Windows 10 using Command Prompt Monetize your Clicks and Downloa...