Wallets — Bitcoin

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

Introduction

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?

Windows
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.
OSX
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.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

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

Source

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.

Features

Download

iOS
Android

Source

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.

Features

Download

Main Release (Main Net)
Testnet Release

Source

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.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

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).

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

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).

Features

Download

Source

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.

Features

Remastered Improvements

Download

Source

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.

Features

Download

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

Source

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.

Features

Download

Windows
Linux / OSX (Instructions)

Source

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.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

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.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

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

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Are there two chain codes in BIP32?

Got a bit confused when reading the section on Mastering Bitcoin about child key derivations in HD wallets
This image and this other image shows the HMAC-SHA512 taking the same inputs but giving different outputs.
In both images the parent public key, the chain code and index number are fed into the HMAC-SHA512 but in the first image it outputs a child private key and in the second one a child public key.
This seems like a contradiction, can someone clear this up? Are there two different chain codes?
submitted by johnturtle to BitcoinBeginners [link] [comments]

Hashcat benchmark on GeForce NOW

OpenCL Platform #1: NVIDIA Corporation

* Device #1: Tesla P40, 6144/24576 MB allocatable, 30MCU

Benchmark relevant options:

* --optimized-kernel-enable

Hashmode: 0 - MD5

Speed.#1.........: 32855.6 MH/s (59.28ms) @ Accel:128 Loops:512 Thr:1024 Vec:4

Hashmode: 100 - SHA1

Speed.#1.........: 11339.3 MH/s (86.21ms) @ Accel:256 Loops:256 Thr:512 Vec:2

Hashmode: 1400 - SHA2-256

Speed.#1.........: 3956.8 MH/s (61.48ms) @ Accel:128 Loops:64 Thr:1024 Vec:1

Hashmode: 1700 - SHA2-512

Speed.#1.........: 1283.4 MH/s (59.73ms) @ Accel:128 Loops:32 Thr:640 Vec:1

Hashmode: 2500 - WPA-EAPOL-PBKDF2 (Iterations: 4096)

Speed.#1.........: 527.4 kH/s (56.26ms) @ Accel:128 Loops:32 Thr:1024 Vec:1

Hashmode: 1000 - NTLM

Speed.#1.........: 56126.1 MH/s (69.61ms) @ Accel:128 Loops:1024 Thr:1024 Vec:2

Hashmode: 3000 - LM

Speed.#1.........: 25822.0 MH/s (76.24ms) @ Accel:256 Loops:1024 Thr:256 Vec:1

Hashmode: 5500 - NetNTLMv1 / NetNTLMv1+ESS

Speed.#1.........: 27994.2 MH/s (69.78ms) @ Accel:128 Loops:512 Thr:1024 Vec:1

Hashmode: 5600 - NetNTLMv2

Speed.#1.........: 2342.5 MH/s (51.96ms) @ Accel:128 Loops:32 Thr:1024 Vec:1

Hashmode: 1500 - descrypt, DES (Unix), Traditional DES

Speed.#1.........: 1129.1 MH/s (54.79ms) @ Accel:8 Loops:1024 Thr:256 Vec:1

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)

Speed.#1.........: 9874.0 kH/s (74.72ms) @ Accel:1024 Loops:1000 Thr:32 Vec:1

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix) (Iterations: 32)

Speed.#1.........: 18809 H/s (48.98ms) @ Accel:16 Loops:8 Thr:8 Vec:1

Hashmode: 1800 - sha512crypt $6$, SHA512 (Unix) (Iterations: 5000)

Speed.#1.........: 166.6 kH/s (72.22ms) @ Accel:512 Loops:128 Thr:32 Vec:1

Hashmode: 7500 - Kerberos 5 AS-REQ Pre-Auth etype 23

Speed.#1.........: 373.7 MH/s (83.17ms) @ Accel:256 Loops:64 Thr:64 Vec:1

Hashmode: 13100 - Kerberos 5 TGS-REP etype 23

Speed.#1.........: 373.9 MH/s (83.08ms) @ Accel:256 Loops:64 Thr:64 Vec:1

Hashmode: 15300 - DPAPI masterkey file v1 (Iterations: 23999)

Speed.#1.........: 88325 H/s (56.71ms) @ Accel:128 Loops:32 Thr:1024 Vec:1

Hashmode: 15900 - DPAPI masterkey file v2 (Iterations: 7999)

Speed.#1.........: 49797 H/s (78.09ms) @ Accel:256 Loops:128 Thr:32 Vec:1

Hashmode: 7100 - macOS v10.8+ (PBKDF2-SHA512) (Iterations: 35000)

Speed.#1.........: 16271 H/s (54.05ms) @ Accel:64 Loops:32 Thr:512 Vec:1

Hashmode: 11600 - 7-Zip (Iterations: 524288)

Speed.#1.........: 11789 H/s (59.33ms) @ Accel:128 Loops:128 Thr:768 Vec:1

Hashmode: 12500 - RAR3-hp (Iterations: 262144)

Speed.#1.........: 39596 H/s (72.02ms) @ Accel:4 Loops:16384 Thr:384 Vec:1

Hashmode: 13000 - RAR5 (Iterations: 32767)

Speed.#1.........: 43880 H/s (73.65ms) @ Accel:128 Loops:32 Thr:896 Vec:1

Hashmode: 6211 - TrueCrypt PBKDF2-HMAC-RIPEMD160 + XTS 512 bit (Iterations: 2000)

Speed.#1.........: 367.6 kH/s (82.29ms) @ Accel:64 Loops:32 Thr:1024 Vec:1

Hashmode: 13400 - KeePass 1 (AES/Twofish) and KeePass 2 (AES) (Iterations: 6000)

Speed.#1.........: 164.5 kH/s (62.68ms) @ Accel:512 Loops:128 Thr:32 Vec:1

Hashmode: 6800 - LastPass + LastPass sniffed (Iterations: 500)

Speed.#1.........: 2843.7 kH/s (59.11ms) @ Accel:64 Loops:62 Thr:896 Vec:1

Hashmode: 11300 - Bitcoin/Litecoin wallet.dat (Iterations: 199999)

Speed.#1.........: 5949 H/s (51.52ms) @ Accel:64 Loops:32 Thr:1024 Vec:1

Started: Tue Sep 03 08:29:05 2019
Stopped: Tue Sep 03 08:38:50 2019
submitted by KennyRX to hacking [link] [comments]

AsicVault - Frequently Asked Questions

When was AsicVault established and how is it funded?
AsicVault was established 2016. It is funded by founders and corporate investors. Please see Crunchbase.

How can it be 1,000 times harder to crack compared to other BIP-39 hardware wallets?
BIP-39 hardware wallets are working on very low performance microcontrollers or secure elements. They are doing only 2,048 iterations of PBKDF2 SHA-512 that is even less than old NIST recommendation of 10,000 rounds from year 2016.
Performing higher number of PBKDF2 SHA-512 is standard practice for good security. iTunes does it, LastPass does it and Veracrypt as well. Even Ledger agrees that this very low number is the main problem of BIP-39.
AsicVault specially designed SHA-512 accelerator inside high performance secure chip is at least 340 times faster than common microcontrollers. The number of PBKDF2 SHA-512 rounds is set to be exactly 1,000 times higher than BIP-39, hence the cost to crack AsicVault is also 1,000 times bigger.
Please read in-depth teardown review and validation of AsicVault SHA-512 performance here.
You can perform independent analysis according to this PDF and our device performance is shown on this video.

Does it support BIP-39 passphrase?
Yes, AsicVault supports all standard BIP-39 seed words and additional passphrase (so-called 25th word). You can restore your HD wallet account created by other hardware wallets (Ledger, Trezor, Keepkey) without any additional steps. AsicVault always opens standard security BIP-39 account and high security BIP-39 accounts at the same time.

Why two processors?
Common design practice, also followed by Ledger, is to separate secure and non-secure code. Our advantage is that these two RISC-V processors are inside a single secure chip. This way the Security CPU has full access to the Application CPU RAM. This makes it possible to do proper secure boot.

Why RISC-V?
Open instruction set. Possibility to have open source CPU and extensions. We have already implemented several custom instructions.

Do I need a computer to initialize the device?
No. You can supply power from wall adapter or battery bank. AsicVault supports true air-gapped environment.
You can perform full device initialization, seed word generation and seed word backup without connection to the computer. You can also charge the device and check the status the same way.

Can I use USB extender cables?
Certified USB2.0 extender cables can be used. We don’t recommend extender cables while using USB3.1 features of the device. The device can detect (some) bad cables and show warning messages about them. It is not recommended to use cables/extenders longer than 2.5m. In any case, cables with lower AWG value are better, such as AWG20.

How hot does the device get?
During normal operation AsicVault device temperature reaches 35-37C. High speed USB3.0 operation adds additional 7C. AsicVault utilizes full Aluminum enclosure as an effective heatsink. Internal chips can tolerate up to +85C, so you never need to worry about them overheating. There are no Lithium batteries inside the device that are known for leaking and not tolerating high temperatures.

How long does the active anti-tamper system work?
Active anti-tamper protects your device at least 2 weeks, possibly up to 45 days, after you have fully charged the device. It takes just 15 minutes to charge the supercapacitors again. It is advisable to connect the device to a power source at least once per week. Different anti-tamper settings affect the anti-tamper aggressiveness, sensitivity and power consumption.
It is also good practice to enter your passphrase weekly so that you will not forget it.

How often can I charge it? Do the batteries age?
You can charge it as often as you like, several times per day. Supercapacitors can be charged 50,000 – 1,000,000 times during their lifetime compared to common Lithium batteries that only allow 500-1,000 times. Therefore even 10 times per day for 10 years should be fine. At least weekly charging is recommended for best anti-tamper protection.

How long are private keys safely stored inside device before the memory gets weak and they are lost?
Data retention time of Flash memory inside the main chip is 20 years. Additional encryption keys stored inside FRAM can last for 40 years at temperatures below 70C. These values are higher than the expected lifetime of the device. In any case you must make paper backup(s) of your seed words.

Can it store the whole Bitcoin blockchain inside the device?
No. The device is not designed to store large amounts of data. Internal 128-megabyte Flash is used to store applications. There are thousands of copies of the blockchain, storing yet another copy is not meaningful or necessary.

What is FIPS 140-2 highest Level 4?
FIPS 140-2 is Federal Information Processing Standard.
Level 4 requires that:
  1. physical security mechanisms provide a complete envelope of protection around the cryptographic module
  2. with the intent of detecting and responding to all unauthorized attempts at physical access
  3. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate deletion of all plaintext CSPs
  4. Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature
  5. A cryptographic module is required to include special environmental protection features designed to detect fluctuations and delete CSPs
We have used these guidelines while designing AsicVault. We meet and exceed the requirements in the following way:
  1. AsicVault has full Aluminium/Titanium enclosure that is not designed to be opened. Passive antitamper mesh protects the electronic circuits inside the device. Main secure chip also has chip level metal layer anti-tamper mesh.
  2. Active anti-tamper circuit monitors all intrusion attempts and performs immediate device zeroization upon detecting any such attempts.
  3. AsicVault has temperature, voltage and many other sensors that are continuously monitored by the anti-tamper circuit. Additionally, AsicVault has internal supercapacitor-based power reserve to run Elliptic Curve calculations and other cryptographic functions. Therefore, external voltage fluctuations can’t affect our device while performing these critical operations.
  4. Zeroization not only deletes the private keys, it also destroys internal hardware design making it impossible to perform any further analysis of the hardware.
AsicVault has not participated in formal Cryptographic Module Validation Program since we are not targeting US government users at this point.

Can AsicVault device run Linux?
It is not our priority to run Linux since it has too big overhead for hardware wallet. However, our RISC-V processors and Mark II hardware can run Linux for your custom projects.

Where can I purchase the device?
Please contact your local supplier about availability.
submitted by photonreality to AsicVaultOfficial [link] [comments]

Create unique bitcoin address per order without access to a private key?

I have a service for which I would like to use bitcoin payments. An item to be payed for is represented by a hash. I would like to generate the unique bitcoin address for the payment either on the client, or on a server with a "watch-only" wallet.
Is it possible to generate a bitcoin address from a public key+hash, such that later the the bitcoins are accessible with private key+hash?
To clarify, I think I should:
Is this possible? Is there already an address-generation scheme that allows this?
Note: I could use a single bitcoin address and put the order hash in OP_RETURN, but as I understand this is not currently supported by QR codes/bitcoin URIs.
submitted by tomtomtom7 to Bitcoin [link] [comments]

CtrXL - Exchange Balances live in Google Sheets

What is CtrXL?
A spreadsheet to track the value of your cryptocurrencies on exchanges, cold storage and/or other locations.
CtrXL can securely pull your Balances from your exchange using Read-Only APIs or by Manual entry in the sheet.
Values are calculated to both BTC and Fiat and can be automatically saved, based on a time interval.
The sheet comes with eye candy Dashboard elements that can be easily adjusted to your own preference.

Download (copy) the sheet
Documentation

Use Cases:
You have currencies on multiple Exchanges or multiple accounts on one exchange
You manage cryptocurrency for others and want a single pane of glass
You have cryptos in 'other' locations; like cold storage, offline / hardware wallets or elsewhere (example: Ledger Nano)
You are looking for a sheet that is simple to understand and can be extended and/or customized

Functionality:
Bibox Binance Bit2C Bitfinex Bitpanda BitMex Bitsane Bitstamp Bittrex CEX.IO Coinbase Coinbase Pro GDAX Cryptopia Deribit Gate.IO Gemini Gopax HitBTC Huobi Indodax Kraken Kucoin Liquid Luno OKEx Poloniex - Manual: Cold Storage


Bibox Binance Binance Jersey Bit2C Bitfinex BitMEX Bitpanda Bitsane Bitstamp Bittrex CEX IO Coinbase + Pro Cryptopia Deribit Gate.IO Gemini HitBTC Huobi Kraken Kucoin OKEx Poloniex - Manual: Cold Storage Gdax API APIS SHA authentication script gas Google Apps Script json balance balances excel sheet google sheet google sheets live cryptosheet cryptosheets crytpo sheet bitcoin ethereum sha256 sha512 private request public request javascript code exchange exchanges REST error json get put cointrexer moosy research spreadsheet spreadsheets code inject pull gate io cex io cexio template data prices import coinmarketcap cmc totals balance balances cryptos cryptocurrency currencies cryptotracking crytotracker Pull Bitcoin and Cryptocurrencies Price and Data in Google Sheets BTC ETH LTC Bitcoin Ethereum Litecoin google script template exchange balance balance api apis spreadsheet excel sheet sheets encryption panda bitpanda global exchange Bibox Binance Bit2C Bitfinex BitMEX Bitpanda Bitsane Bitstamp Bittrex CEX IO Coinbase + Pro Cryptopia Deribit Gate IO GateIO Gemini Gopax HitBTC Huobi Indodax Kraken Kucoin Liquid LUNO OKEx Poloniex and or Manual / Cold storage deribit sha256 sha512 ECDSA signature google script gas google apps script javascript JWT JSON Web Token private exchange balanace request
submitted by moosylog to Cointrexer [link] [comments]

Want to *really* help decentralization by getting more full nodes online? Code a simple bandwidth limit option (like in any decent torrent client) in Bitcoin Core so that people can actually run nodes without ruining their connection

This is a big reason why people stop running full nodes, at least home users. I've seen multiple complaints from folks saying that it eats all their bandwidth, making their internet connection nearly unusable. The result? They stop running a full node. And who can blame them?
There's been plenty of discussion on this issue for four years (!) on the Bitcoin GitHub: https://github.com/bitcoin/bitcoin/issues/273 - I think with all this recent talk about worries of decreasing full node count, this would be a relatively non-controversial means to make running a full node much more accessible, and therefore greatly increase the number of full nodes on the network.
As it is, the user can apply supplemental bandwidth shapers and QoS rules to deal with this, e.g. https://github.com/bitcoin/bitcoin/blob/mastecontrib/qos/tc.sh, but how many people are really going to do that - or even find out that they can?
Concerns on the GitHub issue that this will slow down the network are absurd, in my opinion - for one thing, there's no real incentive to "leech" by capping upload speed well under capacity, and for another, these people who want to regulate the speeds are just going to get frustrated and shut their nodes down completely, as many folks already have. Even if they're throttled, having a great many more nodes than we do now is going to increase the network's speed, not decrease it.
I wish that I had the coding skills to write a patch for this myself, but I do not, and so I just want to try to encourage those who can to make it a higher priority. I think that the impact of this issue has been drastically underestimated by a large number of people.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 For what it's worth (which ain't much), I'll kick in a 0.050 BTC bounty towards a working, tested pull request that implements proper bandwidth limiting in Bitcoin-Core, in a style similar to how most P2P programs do it today (either in the Preferences dialog or somewhere in the main interface). Perhaps someone with a little more in their wallet could add to that bounty. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVjGKXAAoJEJdH3pe6/Nu5mPsP/RS74L7odtEEfJWFIFwZvHLn MNBeB7yv0oegLwK27TPWb/+R+HPTEtW2/q+9xN8GzuyZnfsVoIjWb7mykQm1ILH4 TcGveXvcBYa1TeeZTBoiyrE5qDAN3I15wS+FF97+xANoYY+cmYG3MCd+ctfGT9qb m7/34ppPqTVWD/pAD/A+oIJvPpgsl1nxy78qPCeKHBaSGuCGUqwC2oMOWenwGk7w m+EwJxaWTa60i2+nsACJtUvEHAB+v3LM3dNrNlupxt+Ym47kTCSN99fDJZmvK6 ptI08tSVQz5KbDbqZ7prZdHATBsE0xrI9rMwZYMzv1Vda0vDSR4ggoJOa6JGutqa X33EmzkXk5s7p9DCpcb+4aIucTRknM/oBB/IorIL9bq+Mh6k2MIaguxb+9a446iL dsFRh55t6PAifunVkrFvQyRSqA7MZtQ3wzBP62H2b8oPLwJ4D/eF8WKAGPnUn6YP IOhhvJf9XXKrP42Tvo/cIcPhMnvAF+bMVV0AbTxWzTSHA4qwdfnPlL0AdBCQFhm0 ulCkI9VftzqwGfNl6VPurhOCK2ZGSvaEsc+Zbz2uUex/orf23ihw08ksJjUI9DVP nY82GgULW0wrusQmFmSCaHPsQi2EbUurEcvNiWRWd0ZrayT05zgjtSGregjrdwLR GbGVT+jJHBPBeH+ohbEW =aZqc -----END PGP SIGNATURE----- 
For signature verification, my GPG key with fingerprint 69E7 EB65 1CB6 19DE 9153 3A2B D16B 4CC5 857D 0298 is available at https://np.reddit.com/publickeyexchange/comments/2cmfob/sapiophiles_public_key/, on the major SKS keyservers and on KeyBase at https://keybase.io/sapiophile - my KeyBase proof for this reddit username can be found at https://np.reddit.com/KeybaseProofs/comments/2dfzvj/my_keybase_proof_redditsapiophile/
EDIT: Bounty is now up to 1.65 BTC + $48 in BTC (1.85 BTC total at this time), thanks to wserd, globramma2, CanaryInTheMine, hellobitcoinworld, imaginary_username, Huntred, Melting_Harps, SD7, zebrahat, jefdaj, and especially Place60! Who's next to help sweeten the pot?
submitted by sapiophile to Bitcoin [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.
https://preview.redd.it/51wc6lb90xv11.png?width=700&format=png&auto=webp&s=1d820b95f2ff5afeea697e9c1701fb86b5f3399b
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]

ANN: Arionum (ARO)

We would like to proudly announce Arionum, a new cryptocurrency built from scratch!
Introduction
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
Specifications
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
Roadmap
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/
Pools
Official Pool: http://aropool.com
submitted by AroDev to Arionum [link] [comments]

CONNECT-An open source P2P encrypted messaging & onchain bitcoin wallet APP

My name is Rob. Product Manager of Connect.im. Today,I have the honor to introduce a new product that developed by our team. Named Connect.IM What is CONNECT ?
Connect is an open source point-to-point encrypted instant messaging APP.
You can use CONNECT to send texts, voices, pictures, videos and even Bitcoin. In both one-on-one chat and group chat, all the messages including text, picture, voices, video, etc. are sent via the shared key encryption negotiated by both sides of the chat.
Any third party other than the both sides including the server can't decrypt the messages.
What make Connect secure?
As known as bitcoin, if there is no private key, then no one can steal your bitcoins. Similarly, user’s ID of Connect are generated based on BTC algorithm, if there is no private key, then no one can not steal the messages of the chat.
Connect uses advanced and open-source symmetric encryption algorithms to secure both parties' information and the communication between the client and the server, and anyone can authenticate.
The end-to-end encrypted communication between both sides of the session as well as the encrypted communication between client-side and server uses the key negotiation method to make double layer encryption, with the steps as below:
*1 Session initiator_A use the agreed ECC (elliptic curve cryptography) locally to generate a pair of key(Public_key_A,Private_key_A) and a 512-bit random number salt, and send the random number “saltA” and “Public_key_A” to receiver_B after AES256-GCM encrypted
*2 The receiver_B receives “PublicKey_A” and “saltA” after decrypt. then use the same ECC (elliptic curve cryptography) generate a pair of key(Public_Key_B,Private_Key_b) and a 512-bit random number salt, and send the random number “saltB” and “Public_key_B” to initiator_A after AES256-GCM encrypted.
*3 Initiator_A get “saltB” and “Public_key_B”. Then both initiator_A and receiver_B get ECDH_Key
ECDH_Key = ECDH(PrivateKey_A, PublicKey_B) = ECDH(PrivateKey_B, PublicKey_A)
*4 Then the PBKDF2key expansion algorithm to obtain the negotiated key "K" by ECDH_KEY and random number salts of both sides.
Shared_key = PBKDF2(HMAC-SHA512, ecdhKey, saltAsaltB, pow(2, n), 256) ,(n=12)
*5 The key agreement is completed, and both sides of the AB erase their session key pairs from their respective memory. (ECDH_Key,PublicKey_A,PublicKey_B)
*6 Sessions following, both sides of the AB encrypt and decrypt messages using 256bit Shared_key and AES-256-GCM algorithm.
*7 The negotiated key is updated when a new session is created each time.
*8 The code is not currently open, but will be in June.
The encrypted communication channel established by the above process ensures that communication contents are not leaked under the condition that the network flow is completely monitored. Even if the private key of server-side is mastered by the monitor, the monitor can't decrypt the actual communication contents () according to the private key of server and all network flows, and even can't know the person who is logged in or the side to whom the messages are sent. So this solution has the nature of forward secrecy because the session key pair will be erased by both sides from their respective memories after completion of negotiation.
Why do we need CONNECT?
Different from other instant messaging tools provided by other Internet giants, Connect offers a higher level of security and privacy protection.
It protects your chatting contents from being eavesdropped by any third party such as employers and government.
It protects your personal data such as telephone numbers and friends from being utilized by any third party such as marketing personnel and advertisers.
Considering "PRISM" scandal as well as multiple network fraud cases caused by information leakage, each of us should defending "freedom of speech" and "personal privacy”.
So Connect is suitable for everyone.
Why Connect APP contain bitcoin wallet?
First, user’s ID of Connect are generated based on BTC algorithm, and the user system is established based on decentralized BTC blockchain network.
So, Connect APP itself can be used as Bitcoin Wallet.
As a decentralized financial network which do not rely on any institution or government, Bitcoin is highly consistent with the product philosophy of "Connect". Connect doesn't wish users' data to be monitored by any institution.
It is greatly convenient for BTC users to use the interactive mode based on social network and chat session to realize BTC transfers.You don’t have to remember the bitcoin address of your friends.Instead that transferring the bitcoins is as simple as sending a message.
It is onchain or offchain bitcoin wallet? It is security?
Because the private key of user is stored in the device locally, and each BTC transaction should be made by the private key signature of the user, this is a onchain wallet.The server does not store the user's private key, ensuring that the user can fully control their own funds.
But in many cases, users are easy to lose their private key. We provide a compromise, users can bind their mobile phone, after verified, set a password for encrypted private key and backup on server, server does not store user’s password. Even if the phone is lost, user can use password decrypt and recovery the private key after new phone verified.
If the user has doubts, can also choose “Generate a local account”, keeping private key by oneself com fully.
Transfer bitcoin as simple as sending a message
Transfer bitcoin as simple as sending a message. You don’t have to ask your friend’s bitcoin address in other way. Send bitcoin or payment request in the chat window just like sending a message.
You can sent bitcoin link via other IM APP such as "Whatsapp" "Messabfer" "Wechat". your friend who got this link would got bitcoin ofter install Connect APP.
What is Lucky Packet?
Lucky packet is a kind of function sending BTC to your friends as a gift.
Your friends won't know the BTC quantity they have obtained untill after opening the red envelope. In the group chat, the BTC quantity in each lucky packet is randomly generated.
You can send lucky packet in chat or send a lucky packet link via other IM APP such as "Whatsapp" "Messenger" “Wechat".
Get bitcoin lucky packet free!
All new user in march- Dec 2017 and bind phone will get a random lucky packet (0.001-0.01)
All user write a review and rated on Apple App Store or Google Play, Post screenshot form “Connect-Setting-Help-Feedback”,will get one bitcoin lucky packet (0.001 BTC)
Send 50 bitcoin lucky packets and update link everyday on bitcointalk and Facebook
Click here get bitcoin lucky packets!!
Group Sponsor Program
We welcome the community developers, entrepreneurs and project operators to build your own group via Connect, and we are going to sponsor 1-2BTC to each group depends on the group activity level. Apply for the group BTC sponsor, please add me as a friend firstly and invite me join your group.
Connect me: 18187F2AvfMRe9SrWL52z3PRqGzoEa75EF
Connect to HashNest English Group
How to install?
Website: https://www.connect.im/
iOS: https://itunes.apple.com/app/connect-p2p-encrypted-instant/id1181365735
Android : https://play.google.com/store/apps/details?id=connect.im
submitted by CONNECT-im to Bitcoin [link] [comments]

Trying to build BU from source for Raspberry Pi 2

EDIT: I got it running finally. I'm not exactly sure what fixed it in the end, but thank you everyone for your help!
I've successfully built and ran Bitcoin XT and then Classic on my Raspberry Pi 2 in the past. I recently decided I wanted to switch to Bitcoin Unlimited but am having some problems.
I've primarily followed this guide on raspnode.com for Bitcoin XT, but substituting the BU github repository.
When I run "make" I get this:
[email protected]:~/bin/BitcoinUnlimited $ make Making all in src make[1]: Entering directory '/home/pi/bin/BitcoinUnlimited/src' make[2]: Entering directory '/home/pi/bin/BitcoinUnlimited/src' CXX crypto/libbitcoinconsensus_la-hmac_sha512.lo CXX crypto/libbitcoinconsensus_la-ripemd160.lo CXX crypto/libbitcoinconsensus_la-sha1.lo CXX crypto/libbitcoinconsensus_la-sha256.lo CXX crypto/libbitcoinconsensus_la-sha512.lo CXX primitives/libbitcoinconsensus_la-transaction.lo CXX script/libbitcoinconsensus_la-bitcoinconsensus.lo CXX script/libbitcoinconsensus_la-interpreter.lo CXX script/libbitcoinconsensus_la-script.lo CXXLD libbitcoinconsensus.la CXX libbitcoin_server_a-init.o CXX libbitcoin_server_a-merkleblock.o CXX libbitcoin_server_a-miner.o CXX libbitcoin_server_a-net.o CXX libbitcoin_server_a-noui.o CXX policy/libbitcoin_server_a-fees.o CXX policy/libbitcoin_server_a-policy.o CXX libbitcoin_server_a-pow.o CXX libbitcoin_server_a-rest.o CXX libbitcoin_server_a-rpcblockchain.o CXX libbitcoin_server_a-rpcmining.o CXX libbitcoin_server_a-rpcmisc.o CXX libbitcoin_server_a-rpcnet.o CXX libbitcoin_server_a-rpcrawtransaction.o rpcrawtransaction.cpp: In function ‘UniValue sendrawtransaction(const UniValue&, bool)’: rpcrawtransaction.cpp:837:37: error: ‘SyncWithWallets’ was not declared in this scope SyncWithWallets(tx, NULL); ^ At global scope: cc1plus: warning: unrecognized command line option "-Wno-self-assign" Makefile:4070: recipe for target 'libbitcoin_server_a-rpcrawtransaction.o' failed make[2]: *** [libbitcoin_server_a-rpcrawtransaction.o] Error 1 make[2]: Leaving directory '/home/pi/bin/BitcoinUnlimited/src' Makefile:7161: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/pi/bin/BitcoinUnlimited/src' Makefile:638: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 
Can anyone here help me figure this out? I know that some people have posted binaries, but I really would rather build from source than trust some random binaries online. I would appreciate any help. Thanks in advance!
submitted by grnqrtr to bitcoin_unlimited [link] [comments]

Fragmented hardware wallet seed backups

I've been thinking about the best way to safely store the seed phrase of a hardware wallet - the piece of paper (or steel) has always seemed like a bit of a weak point to me. So I'd love a convenient way to be able to split my seed phrase into fragments using a 2-of-3 scheme.
So I came up with a quick-and-dirty approach. Here are the sheets I prepared for this approach:
LibreOffice: https://www.dropbox.com/s/307cqbpgubsz4sb/fragmented-wallets.ods?dl=0
PDF: https://www.dropbox.com/s/bi5geew2i99e7bp/fragmented-wallets.pdf?dl=0
(The LibreOffice version is better because you can edit the wallet name on the sheet)
The idea is to split a 24-word seed phrase into three groups of 8 words - and write down a different pair of two of the groups on each backup fragment. Now, it's certainly not Shamir Secret Sharing, but it's easy to carry out with little risk of error and requires no software or offline computer to carry it out.
By my calculations, the effort required to crack the wallet using a single backup fragment is roughly equivalent (approximately one order of magnitude harder) than cracking the traditional Trezor recovery method: that is, even making some very generous assumptions, it would require an adversory with the resources to design and fabricate HMAC-SHA512 hashing chips of comparable speed to existing bitcoin double-SHA256 chips, and build a cluster the size of the entire bitcoin network, and it would still take years, unless the arracker is very, very lucky.
So although it's not ideal, and not going to remain safe for ever.... Unless you have a lot of coins and some very powerful adversories, it's probably good enough for a good few years :-)
I'd be very interested in thoughts on this - particularly on whether I've correctly calculated the security of this approach. Note, this scheme is only plausibly safe for 24-word seeds. You should not attempt something similar for shorter seeds
Analysis:
The best fragment to steel is the one that contains the first two portions of ENT (which is fragment #2 using my sheets). This gives you 2x88 bits of ENT and leaves 80 bits unknown - so you need to test 280 ENT values.
(One of the other two fragments will give you 88+80 bits of ENT plus the 8-bit checksum. This leaves you with 288 values to test, but one in 256 will fail the checksum, so it's still 280 values to feed to PBKDF2, but with slightly more work to get there.)
Now, creating a seed from the phrase requires 2048=211 rounds of HMAC-SHA512 - so completely ignoring the cost of testing the resulting seeds, we have to do 291 rounds of HMAC-SHA512 to test every value, or 290 on average.
Assuming a cracking cluster that can solve HMAC-SHA512 at the same rate that the entire Bitcoin network solves double-SHA256, it would take an average of 2^90/(6600*10^15)/(31*10^6) = 6 years to crack the seed from a single fragment.
Thoughts?
submitted by roybadami to btc [link] [comments]

Rolling UTXO set hashes | Pieter Wuille | May 15 2017

Pieter Wuille on May 15 2017:
Hello all,
I would like to discuss a way of computing a UTXO set hash that is
very efficient to update, but does not support any compact proofs of
existence or non-existence.
Much has been written on the topic of various data structures and
derived hashes for the UTXO/TXO set before (including Alan Reiner's
trust-free lite nodes [1], Peter Todd's TXO MMR commitments [2] [3],
or Bram Cohen's TXO bitfield [4]). They all provide interesting extra
functionality or tradeoffs, but require invasive changes to the P2P
protocol or how wallets work, or force nodes to maintain their
database in a normative fashion. Instead, here I focus on an efficient
hash that supports nothing but comparing two UTXO sets. However, it is
not incompatible with any of those other approaches, so we can gain
some of the advantages of a UTXO hash without adopting something that
may be incompatible with future protocol enhancements.
  1. Incremental hashing
Computing a hash of the UTXO set is easy when it does not need
efficient updates, and when we can assume a fixed serialization with a
normative ordering for the data in it - just serialize the whole thing
and hash it. As different software or releases may use different
database models for the UTXO set, a solution that is order-independent
would seem preferable.
This brings us to the problem of computing a hash of unordered data.
Several approaches that accomplish this through incremental hashing
were suggested in [5], including XHASH, AdHash, and MuHash. XHASH
consists of first hashing all the set elements independently, and
XORing all those hashes together. This is insecure, as Gaussian
elimination can easily find a subset of random hashes that XOR to a
given value. AdHash/MuHash are similar, except addition/multiplication
modulo a large prime are used instead of XOR. Wagner [6] showed that
attacking XHASH or AdHash is an instance of a generalized birthday
problem (called the k-sum problem in his paper, with unrestricted k),
and gives a O(22*sqrt(n-1)) algorithm to attack it (for n-bit
hashes). As a result, AdHash with 256-bit hashes only has 31 bits of
security.
Thankfully, [6] also shows that the k-sum problem cannot be
efficiently solved in groups in which the discrete logarithm problem
is hard, as an efficient k-sum solver can be used to compute discrete
logarithms. As a result, MuHash modulo a sufficiently large safe prime
is provably secure under the DL assumption. Common guidelines on
security parameters [7] say that 3072-bit DL has about 128 bits of
security. A final 256-bit hash can be applied to the 3072-bit result
without loss of security to reduce the final size.
An alternative to multiplication modulo a prime is using an elliptic
curve group. Due to the ECDLP assumption, which the security of
Bitcoin signatures already relies on, this also results in security
against k-sum solving. This approach is used in the Elliptic Curve
Multiset Hash (ECMH) in [8]. For this to work, we must "hash onto a
curve point" in a way that results in points without known discrete
logarithm. The paper suggests using (controversial) binary elliptic
curves to make that operation efficient. If we only consider
secp256k1, one approach is just reading potential X coordinates from a
PRNG until one is found that has a corresponding Y coordinate
according to the curve equation. On average, 2 iterations are needed.
A constant time algorithm to hash onto the curve exists as well [9],
but it is only slightly faster and is much more complicated to
implement.
AdHash-like constructions with a sufficiently large intermediate hash
can be made secure against Wagner's algorithm, as suggested in [10].
4160-bit hashes would be needed for 128 bits of security. When
repetition is allowed, [8] gives a stronger attack against AdHash,
suggesting that as much as 400000 bits are needed. While repetition is
not directly an issue for our use case, it would be nice if
verification software would not be required to check for duplicated
entries.
  1. Efficient addition and deletion
Interestingly, both ECMH and MuHash not only support adding set
elements in any order but also deleting in any order. As a result, we
can simply maintain a running sum for the UTXO set as a whole, and
add/subtract when creating/spending an output in it. In the case of
MuHash it is slightly more complicated, as computing an inverse is
relatively expensive. This can be solved by representing the running
value as a fraction, and multiplying created elements into the
numerator and spent elements into the denominator. Only when the final
hash is desired, a single modular inverse and multiplication is needed
to combine the two.
As the update operations are also associative, H(a)+H(b)+H(c)+H(d) can
in fact be computed as (H(a)+H(b)) + (H(c)+H(d)). This implies that
all of this is perfectly parallellizable: each thread can process an
arbitrary subset of the update operations, allowing them to be
efficiently combined later.
  1. Comparison of approaches
Numbers below are based on preliminary benchmarks on a single thread
of a i7-6820HQ CPU running at 3.4GHz.
(1) (MuHash) Multiplying 3072-bit hashes mod 23072 - 1103717 (the
largest 3072-bit safe prime).
* Needs a fast modular multiplication/inverse implementation. * Using SHA512 + ChaCha20 for generating the hashes takes 1.2us per element. * Modular multiplication using GMP takes 1.5us per element (2.5us 
with a 60-line C+asm implementation).
* 768 bytes for maintaining a running sum (384 for numerator, 384 
for denominator)
* Very common security assumption. Even if the DL assumption would 
be broken (but no k-sum algorithm faster than Wagner's is found), this
still maintains 110 bits of security.
(2) (ECMH) Adding secp256k1 EC points
* Much more complicated than the previous approaches when 
implementing from scratch, but almost no extra complexity when ECDSA
secp256k1 signature validation is already implemented.
* Using SHA512 + libsecp256k1's point decompression for generating 
the points takes 11us per element on average.
* Addition/subtracting of N points takes 5.25us + 0.25us*N. * 64 bytes for a running sum. * Identical security assumption as Bitcoin's signatures. 
Using the numbers above, we find that:
24ms (2) 100ms
block takes (1) 3ms (2) 0.5ms
Note that while (2) has higher CPU usage than (1) in general, it has
lower latency when using precomputed per-transaction aggregates. Using
such aggregates is also more feasible as they're only 64 bytes rather
than 768. Because of simplicity, (1) has my preference.
Overall, these numbers are sufficiently low (note that they can be
parallellized) that it would be reasonable for full nodes and/or other
software to always maintain one of them, and effectively have a
rolling cryptographical checksum of the UTXO set at all times.
  1. Use cases
computation. This currently requires minutes of I/O and CPU, as it
serializes and hashes the entire UTXO set. A rolling set hash would
make this instant, making the whole RPC much more usable for sanity
checking.
blocks/UTXO sets.
the past few blocks (computed on the fly), a consistency check can be
done that recomputes it based on the database.
[1] https://bitcointalk.org/index.php?topic=88208.0
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013928.html
[5] https://cseweb.ucsd.edu/~mihipapers/inchash.pdf
[6] https://people.eecs.berkeley.edu/~daw/papers/genbday.html
[7] https://www.keylength.com/
[8] https://arxiv.org/pdf/1601.06502.pdf
[9] https://www.di.ens.f~fouque/pub/latincrypt12.pdf
[10] http://csrc.nist.gov/groups/ST/hash/sha-3/Aug2014/documents/gligoroski_paper_sha3_2014_workshop.pdf
Cheers,

Pieter
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options | Colin Lacina | Aug 09 2017

Colin Lacina on Aug 09 2017:
I believe I have come up with a structure that allows for trustless use of
hybrid wallets that would allow for someone to use a hybrid wallet without
having to trust it while still allowing for emergency recovery of funds in
the case of a lost wallet. It would run off of this TX script:
IF
 1 2 CHECKMULTISIGVERIFY 
ELSE
 2 2 CHECKMULTISIG 
ENDIF
A typical transaction using this would involve a user signing a TX with
their userWalletPrivKey, authenticating with the server, possibly with 2FA
using a phone or something like Authy or Google Authenticator. After
authentication, the server signs with their serverWalletPrivKey.
In case the server goes rogue and starts refusing to sign, the user can use
their userRecoveryPrivKey to send the funds anywhere they choose. Because
if this, the userRecoveryPrivKey is best suited to cold wallet storage.
In the more likely event that the user forgets their password and/or looses
access to their userWalletPrivKey as well as loses their recovery key, they
rely on the serverRecoveryPrivKey.
When the user first sets up their wallet, they answer some basic identity
information, set up a recovery password, and/or set up recovery questions
and answers. This information is explicitly NOT sent to serve with the
exception of recovery questions (although the answers remain with the user,
never seeing the server). What is sent to the server is it's 256 bit hash
used to identify the recovery wallet. The server then creates a 1025 bit
nonce, encrypts it, stores it, and transmits it to the user's client.
Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.
Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
SHA512 on the combination of the identity questions and answers, the
recovery password (if used), the recovery questions and answers, and the
nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.
Finally, the already encrypted key is encrypted again for transmission to
the server. The server decrypts it, then rencrypts it for long term storage.
When the user needs to resort to using this option, they 256 bit hash their
information to build their recovery identifier. The server may, optionally,
request e-mail and or SMS confirmation that user is actually attempting the
recovery.
Next, the server decrypts the saved nonce, as well as the first layer of
encryption on the serverRecoveryPrivKey, then encrypts both for
transmission to the user's client. Then the client removes the transmission
encryption, calculates the 512 bit hash that was used to originally encrypt
the serverRecoveryPrivKey by using the provided information and the nonce.
After all of that the user can decrypt the airbitzServerRecoveryPrivKey and
use it to send a transaction anywhere they choose.
I was thinking this may make a good informational BIP but would like
feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170809/9d5ee7a8/attachment-0001.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014819.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.14.2 released | Wladimir J. van der Laan | Jun 17 2017

Wladimir J. van der Laan on Jun 17 2017:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.14.2 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.14.2/
Or by torrent:
magnet:?xt=urn:btih:b4fc7820df95b8b39603ad246c241272ec403619&dn;=bitcoin-core-0.14.2&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on April 8th, 2014,
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes

miniupnp CVE-2017-8798
Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error
(present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers
(within the LAN) to cause a denial of service or possibly have unspecified
other impact.
This only affects users that have explicitly enabled UPnP through the GUI
setting or through the -upnp option, as since the last UPnP vulnerability
(in Bitcoin Core 0.10.3) it has been disabled by default.
If you use this option, it is recommended to upgrade to this version as soon as
possible.
Known Bugs

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin
control and smart fee estimation does not reflect any change in target from the
smart fee slider. It will only present an approximate fee calculated using the
default target. The fee calculated using the correct target is still applied to
the transaction and shown in the final send confirmation dialog.
0.14.2 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

P2P protocol and network code

Build system

Miscellaneous

GUI

Wallet

Credits

Thanks to everyone who directly contributed to this release:
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCgAGBQJZRRTMAAoJEB5K7WKYbNJdqk0IANF5Q49ID3B77b0CwSKzjTxk
Ktp0qgvtig0ZMnzVlgjULUsRW8EbecWCQwmgRo8uUoCGmNS2u7u+s28kIIkicELE
BpWcW4eC6NdCCjB1CSnmX/tno4gFwOZutVj/XUXJCBEuBbo6fIK0cVDas5vw8UVa
gXL5ytwXeCws3z9f3iiD1Nl0k+J+dRb0sJ2u0A1+XqoMFfInMUFiP/fa9XWaimKo
62jD07IJDKtH4PEKG8v+FLZounRP7t1lhU0AiQ0Uj67mBmllwWD0KeZi0f4SokMX
aezEH+2UIW3Ph/QbG+ktZYUzbDALnRIHEBP4GQUuWiUPZKo3vAS3yhvh1nvYUW4=
=VBdE
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014597.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Proposal to update BIP-32 | Jochen Hoenicke | Apr 20 2016

Jochen Hoenicke on Apr 20 2016:
Hello Bitcoin Developers,
I would like to make a proposal to update BIP-32 in a small way.
TL;DR: BIP-32 is hard to use right (due to its requirement to skip
addresses). This proposal suggests a modification such that the
difficulty can be encapsulated in the library.

MOTIVATION:

The current BIP-32 specifies that if for some node in the hierarchy
the computed hash I_L is larger or equal to the prime or 0, then the
node is invalid and should be skipped in the BIP-32 tree. This has
several unfortunate consequences:
I think the first point alone is reason enough to change this. I am
not aware of a BIP-32 application that handles errors like this
correctly in all cases. It is also very hard to test, since it is
infeasible to brute-force a BIP-32 key and a path where the node does
not exists.
This problem can be avoided by repeating the hashing with slightly
different input data until a valid private key is found. This would
be in the same spirit as RFC-6979. This way, the library will always
return a valid node for all paths. Of course, in the case where the
node is valid according to the current standard the behavior should be
unchanged.
I think the backward compatibility issues are minimal. The chance
that this affects anyone is less than 10-30. Even if it happens, it
would only create some additional addresses (that are not seen if the
user downgrades). The main reason for suggesting a change is that we
want a similar method for different curves where a collision is much
more likely.

QUESTIONS:

What is the procedure to update the BIP? Is it still possible to
change the existing BIP-32 even though it is marked as final? Or
should I make a new BIP for this that obsoletes BIP-32?
What algorithm is preferred? (bike-shedding) My suggestion:
Change the last step of the private -> private derivation functions to:
. In case parse(I_L) >= n or k_i = 0, the procedure is repeated
at step 2 with
I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i)) 
I think this suggestion is simple to implement (a bit harder to unit
test) and the string to hash with HMAC-SHA512 always has the same
length. I use I_R, since I_L is obviously not very random if I_L >= n.
There is a minimal chance that it will lead to an infinite loop if I_R
is the same in two consecutive iterations, but that has only a chance
of 1 in 2512 (if the algorithm is used for different curves that make
I_L >= n more likely, the chance is still less than 1 in 2256). In
theory, this loop can be avoided by incrementing i in every iteration,
but this would make an implementation error in the "hard to test" path
of the program more likely.
The other derivation functions should be updated in a similar matter.
Also the derivation of the root node from the seed should be updated
in a similar matter to avoid invalid seeds.
If you followed until here, thanks for reading this long posting.
Jochen
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012611.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Incentives to run full nodes | odinn | Oct 04 2015

odinn on Oct 04 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello,
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:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-Decembe00
3791.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004
049.html
And an interesting post (which led me to explore BCN) via nullc:
https://news.ycombinator.com/item?id=7765455
(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:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006083
.html
Since that time, some new developments have come to light which the
participants in that thread may find interesting;
Please see in part,
https://bytecoin.org/news/bytecoin-wallet-1.0.8-release-introduces-micro
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.
Cheers,
odinn:
Potentially relevant...
"Incentivizing the running of full nodes"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060
28
.html
(However, the issue to which I referred here is now closed)
View whole thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thre
ad
.html#6028
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
power).
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJWEMsvAAoJEGxwq/inSG8CcU8IAMJ+ZYMFzjETUDEZNyUnVd3v
SJCNauufTOcqxLzQoGIj4Y66PDnk9doRy/KJUGhKNtg4vjxiEk+GGHRH02ktvnQB
6MGuDCJS+MLeGi2W2QMr1NdHl09kRo306F5ZgjtZnOqX0mhwhOrIUylpoevcBnSQ
maJ5hpmxqyhxozEyYyu50HwcMQrXeWKZ8G0VSkTqmY5wf0s98MGrFLWSujwsva0e
p4hvG6YgBH85ne7dnBSH/sySreJpRMA0aac/+1j9U3LVvMTsmuaPc71aGI791o/y
+KV+UZ8bgHldfi+NSK8wA4eRi4JQrt+ruE63XlfYl29gWINqsGeVtpW/W3jeDnI=
=KDER
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011359.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.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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]

Native Bitcoin Escrow is live, launch countdown!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, After many hours spent coding and researching, we have finished our initial Bitcoin Multisig Wallet payment system and are glad to announce we have created the first true bitcoin escrow marketplace that allows vendors and customers to transact without fear of having coins stolen as no one party is able to use the bitcoins without 1 other party signing the transaction, all from a simple to use interface. We have built this feature as part of our larger plan to create a completly distributed platform which will take a long time so we felt that we must first ensure that users would be 100% safe if a malicous party takes control of our servers. All code is unit and functional tested to above 85% coverage and we have completed the following: * Full product catalog that allows sorting and filtering by domestic * Bitcoin Multisig payment system * Enforced encryption message system * Dispute resolution centor * Vendor & item reviews We hope to get feedback from users and we will be creating a new i2p forum and wiki in the coming days for community members to converse and learn more. We will also be putting guides for both vendors and customers alike on the wiki. You can acess the marketplace for now at it's B32 I2P address (Put in address bar and go): http://r35rdglu7cjmsxh5qn3v6o5q7cnejanwg4h2viuvaqavpbf5uqaq.b32.i2p If you are a vendor and would like to have your shop setup before launch, it is imperative you contact us at [email protected] Thanks, TMPSchultz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSgdotAAoJEBLtEWOvmHDdiBAIAMZ+I7ZB96RHO2kAcmcXmb+I qsQA8rWgTH6TF0ISvdBY20baHgi41edJ+xRtac8p6xD4JT2ryR6dBqpZr+EU1Yub L3l4bTf6Z9rXFOg9xlud7PtL+jD6JsxWwJ+W8nwJ0vyur7gVlKmyn6EfOqQ9CSny Kqgm5vOPbeC85lrX/ayn7eLg+chfRdqrHn32tgDkekJeFaU+uwxYDROu3JAGGL2W 3506qnH9OcqsiNd517q+rD8mkLa79E3mDkuVZ+srsfhGTCnFTsALeYtUNu6iKZio NvdJzy0TefjsY126JMvSW/8jef1r4bdOKCYR8FDTZ+qOxBIQ9XbcsSEAIAIkrWo= =FJw3 -----END PGP SIGNATURE----- 
submitted by TMPSchultz to themarketplace [link] [comments]

BIP proposal: derived mnemonics | millibitcoin | Jul 26 2016

millibitcoin on Jul 26 2016:
(not sure so sent again after subscribing (one use case added))
Dear Bitcoin developers,
Below is provided a draft BIP proposal for a master mnemonic sentence
from which other mnemonics sentences can be derived in a deterministic
non-reversible way (on an offline computer). This would make it much
easier to split funds into smaller fractions and use those in a
HD-wallet when appropriate (just by inserting 12 or more words), without
ever putting the master mnemonic at risk on an online computer. But
there are many more use cases.
A reference implementation, specifically for use with a Trezor, has been
generated and can be found at:
http://thebitcoinecosystem.info/DerivedMnemonics.html
I'm not a professional programmer or cryptographer, so the idea and
reference implementation will probably need a lot of reviewing but I do
think Bitcoin needs this extension and the corresponding ease of use and
improved security model.
In the hope you like the idea,
Regards,
sumBTC
BIP: ???
Title: Derived mnemonics from a master mnemonic.
Author: sumBTC
Status: For Discussion
Type:
Created: 2016-07-24
==Abstract==
This BIP??? uses a master mnemonic sentence, as described in BIP39, for
the deterministic generation of derived mnemonic sentences. The derived
mnemonics are of the same format as the master mnemonic but can consist
of a higher or lower number of words.
Binary seeds can then be generated for derived mnemonics (and master
mnemonic) as described in BIP39. Each of these seeds can be used to
generate deterministic wallets using BIP-0032 or similar methods.
==Motivation==
A mnemonic code or sentence is superior for human interaction as
described in BIP39 and can, for example, be written on paper or even
memorized. However, once a mnemonic has been used online, even through
the use of a hardware wallet, the mnemonic could be compromised. This
should be considered a bad practice from a security standpoint.
We therefore propose the generation of a master mnemonic offline and
from this generate (also offline) multiple derived mnemonics in a
deterministic way for online use. The master mnemonic is never used
online and the master mnemonic cannot be obtained from the derived
mnemonics. Examples of use cases are described below.
==Generating the master mnemonic==
The master mnemonic is first derived as a standard mnemonic as described
in BIP39.
==From master mnemonic to derived mnemonics==
From the master mnemonic a new string is created:
string = MasterMnemonic + " " + Count + " " + Strength;
Here, MasterMnemonic are the space separated words of the master
mnemonic. Count = 0, 1, 2 denotes the different derived mnemonics of a
given strength and Strength = numWords / 3 * 32, where numWords is the
number of words desired for the derived mnemonic and only integer
arithmetic is used in the calculation (e.g. for numWords = 14, Strength
= 128). Both Count and Strength are converted to strings.
This string is then hashed using sha512:
hash = sha512(string);
and turned into a byte array:
for (var i=0; i>> ((i%4)*8)) & 0b11111111;
}
This byte array is then used to generate a new mnemonic as shown in the
reference implementation using the method described in BIP39. The core
of the new code in the reference manual can be found by jumping to
"start: new code" in the reference software.
A passphrase for the master mnemonic has the same effect on the derived
mnemoncis (so must be included).
==Reference Implementation==
The reference implementation generates addresses based on BIP44 for a 24
word master mnemonic and is available from
http://thebitcoinecosystem.info/DerivedMnemonics.html
or
github (not yet)
==Checking the derived mnemonics using Electrum==
The displayed addresses in each of the reference implementations can be
easily checked using Electrum in the following manner:
move the directory ~/.electrum to a backup directory.
start Electrum and choose:
Restore a wallet or import keys
Hardware wallet
Restore Electum wallet from device seed words
TREZOR wallet
Insert one of the mnemonics and check that the same addresses are
generated by Electrum
Check the private keys:
move the directory ~/.electrum to a backup directory.
start Electrum and choose:
Restore a wallet or import keys
Standard wallet
Import one of the private keys and check that the correct address has
been generated.
Some checks should include a passphrase.
==Examples of Use Cases==
A person with 25 bitcoin splits funds using 5 derived mnemonics and
sends 5 bitcoins to the first address of each derived mnemonic. He can
then use a (hardware) HD-wallet and simply insert one of the derived
mnemonics to put only 5 bitcoins online and at risk at once. All funds
can be recovered from the master mnemonic.
A person wants to give 10 bitcoin to each of his family members, giving
each participant a derived mnemonic and sending bitcoin to each of them.
The donating person can always recover the derived mnemonic if one of
his family members loses his derived mnemonic.
For his Trezor wallet, someone wants to memorize only a 12 words master
seed but wants to insert a 24 words derived seed so a key logger on his
computer has 24! possibilities to check and not 12! (not a possibility
for the current reference implementation but trivial to add).
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012901.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Missed the free vendor account? Why not apply for an almost-free level 2 account instead?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Over the past month we have gained a large amount of users and have quickly risen to be the favorite and most respected market of many users. We have successfully processed over 20 BTC in transactions and proven that Multi Sig transactions are a viable way for vendors and customers to conduct business. As the first Bitcoin Multi Sig implementation in the world, we were forced to build the tools required to transact with Multi Sig escrow wallets and we have continued to simplify the transaction process by providing an Electrum plugin to bulk generate public keys for vendors, single public keys for orders and make signing and broadcasting a simple copy and paste operation. We have recently released a new vendor commission level that will allow smaller vendors to take advantage of our P2P transaction system by paying a higher commission and a reduced fee. Our pricing for the Level 2 account is as follows: Fee: $250 USD Bond: $100 USD Commission: 8% Price limit on items: 400 USD Upgrade Price: $300 USD Vendors may upgrade their accounts to Level 1 at any time by paying the difference plus a small fee (Vendors who have not yet completed 30 transactions must pay a increased bond as well). We hope this opens our platform to even more users who may have been scared away by high sign up fees. Schultz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS1bEjAAoJELlMLWJeibwPgn4QAJI6LFcMGFZV4ud5xAN+WTE4 k1sTkHt2AwQ6DF/3aqMNtvOXRbzi8aS79lEK6HFL7yZ06fQjgmgEPHe5I1f7Or2y +NmjFT7wCDOA8mDkIaqwGL/IaQCXUpAzzAzfmKb4KUiMsybjnBv3jQo4bkPdWQIb MJ9ChENme8RDTRBcshlEwyOMnVQu2PqijD4xhT+LlxsYlvipAuYHZwqcVkTwG6kJ 5kAh9uOSJCb6Cktjp79K5q51Y7Yn99pcnzZSxTMNwtbbVaX7JHvIjJk/1XrbUv/R /8o2tI5BrE5KGpWw2trQhXARemzBRv7sRVwcgRFuw03qLENWi1NU/av7PjKi58kI 5AvmPuCAh4n6Je/xupNd0pszZ3A0aRnc88ODTzNjmWrcrnlSZiyn+Q0Mm/GQfWyy Z7IqiiCickwCE9ppizvUqTgTzJGNJ/pfxkghxsiSnV+1m5NDVjsipVhip3Zgs6TW bJqBYVsvVSk8vGhC2Z3GelqkmvaC+EQOszEIG8G0jOm6vWfxj8ebt1vKCs9zLdaU WG418zDimsOHZaBP7FXCaWSsTsifv1fx7RadVninyD0MHgQkmlZl3azD2g8cti1V A51hTAU1pUwvoaUcyvCfIDWK2BMFMOcdVaX5wZt1/DJaMDK0BURhSsgjhazAyL/u SJrFNquV42q53Qg0Dvaf =m7Zr -----END PGP SIGNATURE----- 
submitted by TMPSchultz to themarketplace [link] [comments]

QUEBRANDO DIVERSOS TIPO DE HASH SEM WORDLIST SHA256 Hashing Using Java - Backbone of any Blockchain or a Cryptocurrency How secure is 256 bit security? - YouTube Windows Crack MD5 SHA1 hash using hashcat GUI Secure Hash Algorithm Explained (SHA)

Das Wort "Wallet" wird verwendet, um ein paar verschiedene Dinge in Bitcoin zu beschreiben. Auf einer high Level Ebene ist eine Wallet eine Anwendung, die als primäre Benutzerschnittstelle dient. Die Wallet steuert den Zugriff auf das Geld eines Benutzers, verwaltet Schlüssel und Adressen, verfolgt den Kontostand und erstellt und signiert Transaktionen. Von dem was ich verstehe, ist die Brieftasche Saatgut wird erstellt durch Eingabe in PBKDF2 (mit HMAC-SHA512, von denen 2048 Runden angewendet werden) eine Reihe von mnemonischen code-Wörter und ein optionaler salt - (standardmäßig auf "mnemonische"). Dies generiert einen 512 bit-Samen, das ist völlig unpraktisch, um brute-force. Dies ist ein Bild des Prozesses, in die ich mich beziehe ... certUtil -hashfile Stacks-Wallet-win10-3.0.0.exe SHA512 certUtil -hashfile Stacks-Wallet-win10-3.0.0.exe SHA512. Verify that the resulting hash (a string of letters and numbers) is the same as the hash published on the Stacks Wallet's Github repository. Additional requirement and option. Sending and receiving Stacks (STX) does require a Bitcoin as fuel. You also have the option to use the ... A bitcoin wallet containing a little over 69,000 BTC is doing the rounds in hacking communities all over the internet. The reason? It’s obvious. Everyone (read seasoned hackers and self-professed bitcoin wallet crackers) wants to break it open and take it all. Or at least, a slice of the almost $750 million pie. For the last two years, however, no one has been able to ‘strike it lucky ... Loose-Key wallets, also called “Just a Bunch Of Keys (JBOK)”, are a deprecated form of wallet that originated from the Bitcoin Core client wallet. The Bitcoin Core client wallet would create 100 private key/public key pairs automatically via a Pseudo-Random-Number Generator (PRNG) for later use.

[index] [24317] [24411] [3621] [41167] [27209] [665] [37043] [30215] [29841] [13826]

QUEBRANDO DIVERSOS TIPO DE HASH SEM WORDLIST

In this video, you will see Secure Hash Algorithm (SHA) explained simply for beginners! Understanding the concept of a Secure Hash Algorithm (SHA) is crucial in order to understand blockchain ... no compre contratos de mineria de bitcoin a hashflare sin antes ver este video glosario de terminos utilizados en criptomonedas: https://goo.gl/tavcdj su... Download Link: https://dailyraffle.page.link/oZiZ Daily Raffle is a Risk-Free app with a daily prizes up to 1000$. This is not like any other game, the chanc... Supplement to the cryptocurrency video: How hard is it to find a 256-bit hash just by guessing and checking? What kind of computer would that take? Cryptocur... Skip navigation Sign in. Search

#