How do I hash a string using JavaScript with sha512 algorithm

Groestlcoin 6th Anniversary Release


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

UPDATED - Groestlcoin Core 2.18.2

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

How to Upgrade?

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

Other Linux


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


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

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





ALL NEW! – HODL GRS Android Wallet

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



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

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


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

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





ALL NEW! – Groestlcoin EasyVanity 2020

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




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

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


Remastered Improvements



ALL NEW! – BIP39 Key Tool

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



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


ALL NEW! – Electrum Personal Server

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



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

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



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

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




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Trading Crypto with BitHash API

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

How to start trading with Crypto Trading API

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

BitHash API

Security Notes

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

About BitHash

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

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.

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]

Celebrating 20,000 subscribers | Lambo giveaway

The winning number was x0596x

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

How can this be confirmed?

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

What next?

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

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

20k subscribers

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

The Giveaway

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

The drawing

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

Acceptable guess range is 0001 ~ 2000

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

Here are some valid number formats:


Here are some invalid number formats:

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

Secret number

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

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

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

What if no one guesses the number?

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

What if two or more people win?

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

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

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

I saw you edit this post. Are you cheating?

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

Wait, what if I edit my message then?

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

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

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

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

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

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

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

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

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]

xvultx4llltx7w2d.onion is 18 months online today

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

Vultronix encrypted social network.

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

Introduce private mining (Senate) and public mining (House of Representative) into blockchain ecosystem

In my perception, Proof of work mining is in place to finalize the transaction. And it is the most important piece of the blockchain ecosystem. If there is a counterpart in the real word, probably it would be the US congress. Once president has an idea, need to be passed by the 51% of the congress man. Then it would be the legitimate law.
It is fairly wise that let the majority of the people decide the future of the whole system. The president can only behave well.
However the Father has predicted that the small states interest would be jeopardized as they have less population. Say let California and Alaska play a game according to their population. Alaska will never defeat California.
That is probably the situation in the bitcoin mining field. Those giant players holding big capacity of computing resource are taking advantage of the small capacity players
‘Proof of Stake’ is invented. Somehow it is not the perfect solution, what if it is hacked and yields something evil.
So ‘proof the work’ is the right path. And The Father of the United States has inspired us hundreds of years, split the congress with Senate and House
The same concept in the mining domain would be, introduce private mining and public mining
Private mining: is something needs to be done on specific nodes. (Senate)
Public mining: is something could be done only with computing resource solely (House of the representative)
The detailed steps would be:
The player initiates a transaction, it would produce a proposal, then proposal is reworked on , and produce verdict, (this is the private mining step), and verdict is sent to the public mining, form the blockchain.
Will demonstrate below:
Step1: with the raw statement:
\^jungu::821||70e94c78||1->[email protected]@b49febb3ab920878$$)
jungu is the player,
821||70e94c78||1 is the noteId; 821 is the symbol, 70e94c78 is the noteId, 1 is the quantity
0x2e001 is the recipient of the note,
b49febb3ab920878 is the checksum bit
Step 2: Write the proposal based on the statement
Will get the proposal:
950b75f77d77c9071b8c06f4768f02d2f975731e194bcf3bfaf2ed26ac7ddef568f2c4c51e1db57ff03e6e75a7a3c509837ecb95ee93fa91ce3cc8105706261bc3d5c6d8afab5dad0fb58409dafb7f4571cc372f56b31baec41a0f219d1421e91f6a610aa8b4cb8bd8c0b8c96e5b84dd2fbdfea30349094803fb5e6c4c5d476166e73e7b51fb3043f7de51571946df1fc4010d42d56c8d9178061f69bc9dcd169bbbeed84b7323fe9d15dd05b8231fc813229f05e6c198d021262ea2cf7495d2cc37bb213fc3909f6ae900f7de18e84ad4ed63990dcef29a90b884dd3d95edaa9[email protected]@3344a3ae75f0c29b1c3aec06bb54dee63b80b7b1fadf382635dc2fbb1271a45b2c638c185b9d13ce1acd707429fea3e74e3a8ea29654c43cacf5812c4858a14b88df647eb6ee9920781d7ec5075da1bcd34521fe3190e6704dea36648e494204364dcc054ff4984529ebb8d9e7ae9b4e37c14b8c33053d8991411e57503aa5bb16be1f50d3f9bdb21735760795d8377e6ec5e32e06c230f304fab533a0e41efe321e17893ec0ebafa62ba5e5502fc506e4c1290fca5c8ee5b979ace1ad914cdc3cf81779967324c3d02600d4c752de15fa0b6b993f761616835fb60fc50916c4cae4f31e4b4d07020d41a0b06bf692c39e525a212ee40fcf1cfbcdca4d0e38e8
Step3: private mining (Senate confirm the transaction)
Take in the proposal in step1 and produce the verdict: (Senate confirm the transaction)
950b75f77d77c9071b8c06f4768f02d2f975731e194bcf3bfaf2ed26ac7ddef568f2c4c51e1db57ff03e6e75a7a3c509837ecb95ee93fa91ce3cc8105706261bc3d5c6d8afab5dad0fb58409dafb7f4571cc372f56b31baec41a0f219d1421e91f6a610aa8b4cb8bd8c0b8c96e5b84dd2fbdfea30349094803fb5e6c4c5d476166e73e7b51fb3043f7de51571946df1fc4010d42d56c8d9178061f69bc9dcd169bbbeed84b7323fe9d15dd05b8231fc813229f05e6c198d021262ea2cf7495d2cc37bb213fc3909f6ae900f7de18e84ad4ed63990dcef29a90b884dd3d95edaa9[email protected]@9f2da137433e87a79f37e8e6c89ab260a9734f1a31258198ad63a9cfe4cd54f2002a7ffd8dbedf8a6daf33f2212077466d268f1203cca85309030176e7d13a44ad2aecb094398c742ef4b93913ec5b8cbcd685661aee34e9aebed1fb68f86887212fd48be03bee81d6df0ab835aecd6a48e085fbda43b1b3c84e4f74f77faa3e40891cdd628a1c232a9ed2f73c7239d18a87a6bec25c814733d66ae13ca9b3db98df46c564e5205dd67363d3873bf2b31cba6100c9577cb1fcfc567fbbcbedde6aa96b6e1826f9e41c8aa6c981426f9147ac48d655ee1dda67dd5c3503b598353945ca9db555a8e0f976c2f93aedc49b7faad16b236266a6ed43ffcf21744473
Download the binary file ‘
Verify the verdict with “./verify3 ‘verdict’”
Will get the raw statement \^jungu::821||70e94c78||1->[email protected]@b49febb3ab920878$$)
Can Senate produce a verdict without a proposal?
No, it can’t
What if there is an invalid proposal sent to the Senate?
It will be discarded, produce no verdict
Step4: public mining (House of Representative confirms the transaction)
Take the raw statement, proposal, verdict, and get the sha512 signature
Append the above signature with a value that makes a sha512 signature starting with ‘3333333
Yeah: found it.
After spending 11 minutes, I find a value ‘0.07708886703295392’, that will work together with 279155dc685121e837f54a0c906de721958980f63be6a9756986b0c93a8c14f61b262f5cef6d09805ad5cf9d642ccb5935b19051227ec2513ff03b782596b26b and produce a sha512 signature 333333305a00afeeff9a09c8e56d65dc59c3e98cc99c050f3c6d3f287c4ce680fb31ff3fa369ecd520b5f538b1af40f60a35d9fcb93f0946c5cd0796a4eb25c3
Some amendments:
Senate can’t be only 1 member. Senate will be divided into 3 cliques. They are ‘Clique3’, ‘Clique7’, and ‘Cliquef’. Each clique will have a bunch of members. Those cliques will have different algorithms to back the same transaction. Say Clique3 log the transaction via English, Clique7 log the transaction via Chinese, and Cliquef log the transaction via French.
On an approved valid transaction, the senate should speak unanimously; every member in every clique should all agree the transaction, otherwise the system would stop to analyze the issue, possible case would be one senator is compromised; the whole senate should stop and get rid of that node, and replace or introduce new ones.
For productivity sake, in public mining phase, usually a bunch of transactions is packed together, and do the mining job quite similar to the bitcoin mechanism. Somehow in the private mining phase, the single transaction is settled by itself.
submitted by 821credit to CryptoCurrency [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 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 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:
(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
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.
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
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
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
  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
blocks/UTXO sets.
the past few blocks (computed on the fly), a consistency check can be
done that recomputes it based on the database.
[9] https://www.di.ens.f~fouque/pub/latincrypt12.pdf

submitted by dev_list_bot to bitcoin_devlist [link] [comments]

New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH | Johnson Lau | Aug 16 2016

Johnson Lau on Aug 16 2016:
Hash: SHA512
A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
BIP: x
Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
Author: Johnson Lau
Status: Draft
Type: Standards Track
Created: 2016-08-17
This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.
OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.
The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.
In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.
This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.
This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).
This work is placed in the public domain.
Comment: GPGTools -
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

BIP: Using Median time-past as endpoint for locktime calculations | Thomas Kerin | Aug 18 2015

Thomas Kerin on Aug 18 2015:
Hash: SHA512
Hi all,
In collaboration with Mark Friedenbach, we have drawn up a proposal for
the median time of the past 11 blocks in locktime calculations.
Title: Median time-past as endpoint for lock-time calculations
Author: Thomas Kerin <me at>
 Mark Friedenbach <[mark at](> 
Status: Draft
Type: Standards Track
Created: 2015-08-10
This BIP is a proposal to redefine the semantics used in determining a
time-locked transaction's eligibility for inclusion in a block. The
median of the last 11 blocks is used instead of the block's timestamp,
ensuring that it increases monotonically with each block.
At present, transactions are excluded from inclusion in a block if the
present time or block height is less than or equal to that specified
in the locktime. Since the consensus rules do not mandate strict
ordering of block timestamps, this has the unfortunate outcome of
creating a perverse incentive for miners to lie about the time of
their blocks in order to collect more fees by including transactions
that by wall clock determination have not yet matured.
This BIP proposes comparing the locktime against the median of the
past 11 block's timestamps, rather than the timestamp of the block
including the transaction. Existing consensus rules guarantee this
value to monotonically advance, thereby removing the capability for
miners to claim more transaction fees by lying about the timestamps of
their block.
This proposal seeks to ensure reliable behaviour in locktime calculations as
The values for transaction locktime remain unchanged. The difference is
only in
the calculation determining whether a transaction can be included.
Instead of
an unreliable timestamp, the following function is used to determine the
block time for the purpose of checking lock-time constraints:
enum { nMedianTimeSpan=11 }; int64_t GetMedianTimePast(const CBlockIndex* pindex) { int64_t pmedian[nMedianTimeSpan]; int64_t* pbegin = &pmedian;[nMedianTimeSpan]; int64_t* pend = &pmedian;[nMedianTimeSpan]; for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = 
 *(--pbegin) = pindex->GetBlockTime(); std::sort(pbegin, pend); return pbegin[(pend - pbegin)/2]; } 
Lock-time constraints are checked by the consensus method IsFinalTx(),
or LockTime() under BIP68. These methods take the block time as one
parameter. This BIP proposes that after activation calls to
IsFinalTx() or LockTime() within consensus code use the return value
of GetMedianTimePast(pindexPrev) instead.
A reference implementation of this proposal is provided in the
following git repository:
We reuse the double-threshold switchover mechanism from BIPs 34 and 66,
with the
same thresholds, but for block.nVersion = 4. The new rules are in effect for
every block (at height H) with nVersion = 4 and at least 750 out of 1000
preceding it (with heights H-1000...H-1) also have nVersion = 4.
when 950 out of the 1000 blocks preceding a block do have nVersion = 4,
nVersion = 3 blocks become invalid, and all further blocks enforce the
new rules.
It is recommended that this soft-fork deployment trigger include other
proposals for improving Bitcoin's lock-time capabilities, such as BIP
65, BIP68
Mark Friedenbach for designing and authoring the reference
implementation of this BIP.
Thomas Kerin authored this BIP document.
Transactions generated using time-based lock-time will take
approximately an hour longer to confirm than would be expected under
the old rules. This is not known to introduce any compatibility
concerns with existing protocols.
[ BIP65:
[ BIP68:
Consensus-enforced transaction replacement signaled via sequence numbers]
This document is placed in the public domain.
My PGP key can be found here: <>
Version: GnuPG v2
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

New BIP: Low S values signatures | Johnson Lau | Aug 16 2016

Johnson Lau on Aug 16 2016:
Hash: SHA512
As discussed in the 11 Aug 2016 IRC meeting (, a new BIP with implementation is prepared to make low S value signature as a consensus rule:
The softfork is proposed to be deployed with segwit (BIP141), likely in v0.13.1
The text is copied below
BIP: ?
Title: Low S values signatures
Author: Pieter Wuille
 Johnson Lau  
Status: Draft
Type: Standards Track
Created: 2016-08-16
This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to using low S values.
ECDSA signatures are inherently malleable as taking the negative of the number S inside (modulo the curve order) does not invalidate it. This is a nuisance malleability vector as any relay node on the network may transform the signature, with no access to the relevant private keys required. For non-segregated witness transactions, this malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness (BIP141) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay (BIP152).
To fix this malleability, we require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.
Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, MUST use a S value between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive) with strict DER encoding (see BIP66).
These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the IsLowDERSignature check, the entire script evaluates to false immediately. If the signature is valid DER with low S value, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to IsLowDERSignature).
This BIP will be deployed by "version bits" BIP9 using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
The reference client has produced compatible signatures since v0.9.0, and the requirement to have low S value signatures has been enforced as a relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability.
An implementation for the reference client is available at
This document is extracted from the previous BIP62 proposal which had input from various people.
This document is placed in the public domain.
Comment: GPGTools -
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin-development Digest, Vol 48, Issue 41 | Damian Gomez | May 08 2015

Damian Gomez on May 08 2015:
Well zombie txns aside, I expect this to be resolved w/ a client side
implementation using a Merkle-Winternitz OTS in order to prevent the loss
of fee structure theougth the implementation of a this security hash that
eill alloow for a one-wya transaction to conitnue, according to the TESLA
We can then tally what is needed to compute tteh number of bit desginated
for teh completion og the client-side signature if discussin the
construcitons of a a DH key (instead of the BIP X509 protocol)
On Fri, May 8, 2015 at 2:08 PM, <
bitcoin-development-request at> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at
You can reach the person managing the list at
bitcoin-development-owner at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Re: Block Size Increase (Mark Friedenbach)
  2. Softfork signaling improvements (Douglas Roark)
  3. Re: Block Size Increase (Mark Friedenbach)
  4. Re: Block Size Increase (Raystonn) (Damian Gomez)
  5. Re: Block Size Increase (Raystonn)
---------- Forwarded message ----------
From: Mark Friedenbach <mark at>
To: Raystonn <raystonn at>
Cc: Bitcoin Development <bitcoin-development at>
Date: Fri, 8 May 2015 13:55:30 -0700
Subject: Re: [Bitcoin-development] Block Size Increase
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn at> wrote:
Replace by fee is what I was referencing. End-users interpret the old
transaction as expired. Hence the nomenclature. An alternative is a new
feature that operates in the reverse of time lock, expiring a transaction
after a specific time. But time is a bit unreliable in the blockchain
---------- Forwarded message ----------
From: Douglas Roark <doug at>
To: Bitcoin Dev <bitcoin-development at>
Date: Fri, 8 May 2015 15:27:26 -0400
Subject: [Bitcoin-development] Softfork signaling improvements
Hash: SHA512
Hello. I've seen Greg make a couple of posts online
is one such example) where he has mentioned that Pieter has a new
proposal for allowing multiple softforks to be deployed at the same
time. As discussed in the thread I linked, the idea seems simple
enough. Still, I'm curious if the actual proposal has been posted
anywhere. I spent a few minutes searching the usual suspects (this
mailing list, Reddit, Bitcointalk, IRC logs, BIPs) and can't find
Douglas Roark
Senior Developer
Armory Technologies, Inc.
doug at
PGP key ID: 92ADC0D7
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -
---------- Forwarded message ----------
From: Mark Friedenbach <mark at>
To: "Raystonn ." <raystonn at>
Cc: Bitcoin Development <bitcoin-development at>
Date: Fri, 8 May 2015 13:40:50 -0700
Subject: Re: [Bitcoin-development] Block Size Increase
Transactions don't expire. But if the wallet is online, it can
periodically choose to release an already created transaction with a higher
fee. This requires replace-by-fee to be sufficiently deployed, however.
On Fri, May 8, 2015 at 1:38 PM, Raystonn . <raystonn at> wrote:
I have a proposal for wallets such as yours. How about creating all
transactions with an expiration time starting with a low fee, then
replacing with new transactions that have a higher fee as time passes.
Users can pick the fee curve they desire based on the transaction priority
they want to advertise to the network. Users set the priority in the
wallet, and the wallet software translates it to a specific fee curve used
in the series of expiring transactions. In this manner, transactions are
never left hanging for days, and probably not even for hours.
On 8 May 2015 1:17 pm, Aaron Voisine <voisine at> wrote:
As the author of a popular SPV wallet, I wanted to weigh in, in support
of the Gavin's 20Mb block proposal.
The best argument I've heard against raising the limit is that we need
fee pressure. I agree that fee pressure is the right way to economize on
scarce resources. Placing hard limits on block size however is an
incredibly disruptive way to go about this, and will severely negatively
impact users' experience.
When users pay too low a fee, they should:
1) See immediate failure as they do now with fees that fail to propagate.
2) If the fee lower than it should be but not terminal, they should see
degraded performance, long delays in confirmation, but eventual success.
This will encourage them to pay higher fees in future.
The worst of all worlds would be to have transactions propagate, hang in
limbo for days, and then fail. This is the most important scenario to
avoid. Increasing the 1Mb block size limit I think is the simplest way to
avoid this least desirable scenario for the immediate future.
We can play around with improved transaction selection for blocks and
encourage miners to adopt it to discourage low fees and create fee
pressure. These could involve hybrid priority/fee selection so low fee
transactions see degraded performance instead of failure. This would be the
conservative low risk approach.
Aaron Voisine
co-founder and CEO
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.;117567292;y
Bitcoin-development mailing list
Bitcoin-development at
---------- Forwarded message ----------
From: Damian Gomez <dgomez1092 at>
To: bitcoin-development at
Date: Fri, 8 May 2015 14:04:10 -0700
Subject: Re: [Bitcoin-development] Block Size Increase (Raystonn)
I was reading some of the thread but can't say I read the entire thing.
I think that it is realistic to cinsider a nlock sixe of 20MB for any
block txn to occur. THis is an enormous amount of data (relatively for a
netwkrk) in which the avergage rate of 10tps over 10 miniutes would allow
for fewasible transformation of data at this curent point in time.
Though I do not see what extra hash information would be stored in the
overall ecosystem as we begin to describe what the scripts that are
atacrhed tp the blockchain would carry,
I'd therefore think that for the remainder of this year that it is
possible to have a block chain within 200 - 300 bytes that is more
charatereistic of some feasible attempts at attaching nuanced data in order
to keep propliifc the blockchain but have these identifiers be integral
OPSIg of the the entiore block. THe reasoning behind this has to do with
encryption standards that can be added toe a chain such as th DH algoritnm
keys that would allow for a higher integrity level withinin the system as
it is. Cutrent;y tyh prootocl oomnly controls for the amount of
transactions through if TxnOut script and the publin key coming form teh
lcoation of the proof-of-work. Form this then I think that a rate of higher
than then current standard of 92bytes allows for GPUS ie CUDA to perfirm
its standard operations of 1216 flops in rde rto mechanize a new
personal identity within the chain that also attaches an encrypted instance
of a further categorical variable that we can prsribved to it.
I think with the current BIP7 prootclol for transactions there is an area
of vulnerability for man-in-the-middle attacks upon request of bitcin to
any merchant as is. It would contraidct the security of the bitcoin if it
was intereceptefd iand not allowed to reach tthe payment network or if the
hash was reveresed in orfr to change the value it had. Therefore the
current best fit block size today is between 200 - 300 bytws (depending on
how exciteed we get)
Thanks for letting me join the conversation
I welcomes any vhalleneged and will reply with more research as i figure
out what problems are revealed in my current formation of thoughts (sorry
for the errors but i am just trying to move forward - THE DELRERT KEY
---------- Forwarded message ----------
From: Raystonn <raystonn at>
To: Mark Friedenbach <mark at>
Cc: Bitcoin Development <bitcoin-development at>
Date: Fri, 8 May 2015 14:01:28 -0700
Subject: Re: [Bitcoin-development] Block Size Increase
Replace by fee is the better approach. It will ultimately replace zombie
transactions (due to insufficient fee) with potentially much higher fees as
the feature takes hold in wallets throughout the network, and fee
competition increases. However, this does not fix the problem of low tps.
In fact, as blocks fill it could make the problem worse. This feature
means more transactions after all. So I would expect huge fee spikes, or a
return to zombie transactions if fee caps are implemented by wallets.
On 8 May 2015 1:55 pm, Mark Friedenbach <mark at> wrote:
The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.
On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn at> wrote:
Replace by fee is what I was referencing. End-users interpret the old
transaction as expired. Hence the nomenclature. An alternative is a new
feature that operates in the reverse of time lock, expiring a transaction
after a specific time. But time is a bit unreliable in the blockchain
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.;117567292;y
Bitcoin-development mailing list
Bitcoin-development at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.14.1 released | Wladimir J. van der Laan | Apr 22 2017

Wladimir J. van der Laan on Apr 22 2017:
Hash: SHA512
Bitcoin Core version 0.14.1 is now available from:
Or, by torrent:
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:
To receive security and update notifications, please subscribe to:

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

RPC changes
These interface changes break compatibility with 0.14.0, when the named
arguments functionality, introduced in 0.14.0, is used. Client software
using these calls with named arguments needs to be updated.
In previous versions, getblocktemplate required segwit support from downstream
clients/miners once the feature activated on the network. In this version, it
now supports non-segwit clients even after activation, by removing all segwit
transactions from the returned block template. This allows non-segwit miners to
continue functioning correctly even after segwit has activated.
Due to the limitations in previous versions, getblocktemplate also recommended
non-segwit clients to not signal for the segwit version-bit. Since this is no
longer an issue, getblocktemplate now always recommends signalling segwit for
all miners. This is safe because ability to enforce the rule is the only
required criteria for safe activation, not actually producing segwit-enabled
UTXO memory accounting
Memory usage for the UTXO cache is being calculated more accurately, so that
the configured limit (-dbcache) will be respected when memory usage peaks
during cache flushes. The memory accounting in prior releases is estimated to
only account for half the actual peak utilization.
The default -dbcache has also been changed in this release to 450MiB. Users
who currently set -dbcache to a high value (e.g. to keep the UTXO more fully
cached in memory) should consider increasing this setting in order to achieve
the same cache performance as prior releases. Users on low-memory systems
(such as systems with 1GB or less) should consider specifying a lower value for
this parameter.
Additional information relating to running on low-memory systems can be found
0.14.1 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

    • #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
    • #10139 f15268d Remove auth cookie on shutdown (practicalswift)
    • #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
    • #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
    • #10204 3c79602 Rename disconnectnode argument (jnewbery)

Block and transaction handling

    • #10126 0b5e162 Compensate for memory peak at flush time (sipa)
    • #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
    • #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)

P2P protocol and network code

    • #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
    • #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)

Build system

  • - #9973 e9611d1 depends: fix zlib build on osx (theuni)


  • - #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)


    • #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
    • #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)

Tests and QA

  • - #10157 55f641c Fix the test (sdaftuar)


    • #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
    • #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
    • #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)

Thanks to everyone who directly contributed to this release:
    • Alex Morcos
    • Andrew Chow
    • Awemany
    • Cory Fields
    • Gregory Maxwell
    • James Evans
    • John Newbery
    • MarcoFalke
    • Matt Corallo
    • Pieter Wuille
    • practicalswift
    • rawodb
    • Suhas Daftuar
    • Wladimir J. van der Laan
As well as everyone that helped translating on Transifex.
Version: GnuPG v1
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Variable Block Size Proposal | Justin M. Wray | Aug 29 2015

Justin M. Wray on Aug 29 2015:
Hash: SHA512
Hey Bitcoiners!
While I am an avid Bitcoin supporter, long-term user, and have done
development work on tools and platforms surrounding Bitcoin, I have
been very busy these past few weeks and haven't had a chance to fully
(or closely) monitor the Block Size debate.
I'm familiar with the basics, and have read abstracts about the
front-running proposals (BIP 100, 101, and 102). Though I've honestly
not read those in depth either. With that said, I was driving
the other day and thought of a potential idea. I'll be clear, this is
just an idea, and I haven't fully fleshed it out. But I thought I'd
throw it out there and see what people thought.
My Goal:
Provide a variable block size that provides for sustainable, long-term
growth, and balances the block propagation, while also being mindful
of potential spam attacks.
The Proposal:
Every 2016 blocks (approximately every two weeks, at the same time the
difficulty is adjusted), the new block size parameters are calculated.
The calculation determines the average (mean) size of the past 2016
blocks. This "average" size is then doubled (200%) and used as the
maximum block size for the subsequent 2016 blocks. At any point, if
the new maximum size is calculated to be below 1MB, 1MB is used
instead (which prevents regression from our current state).
Introduce a block minimum, the minimum will be 25% of the current
maximum, calculated at the same time (that is, every 2016 blocks, at
the same time the maximum is calculated). All blocks must be at least
this size in order to be valid, for blocks that do not have enough
transactions to meet the 25%, padding will be used. This devalues the
incentive to mine empty blocks in either an attempt to deflate the
block size, or to obtain a propagation advantage. Miners will be
incentivized to include transactions, as the block must meet the
minimum. This should ensure that even miners wishing to always mine
the minimum are still confirming Bitcoin transactions.
At the block in which this is introduced the maximum would stay at 1MB
for the subsequent 2016 blocks. With the minimum being enforced of 256KB
* Average Block Size for the last 2016 blocks: 724KB * New Maximum: 1448KB * New Minimum: 362KB 
Example: (Regression Prevention)
* Average Block Size for the last 2016 blocks: 250KB * New Maximum: 1MB * New Minimum: 256KB 
The Future:
I believe that the 1MB regression prevention might need to be changed
in the future, to prevent a large mining population from continually
deflating the block size (and keeping us at the 1MB limit).
For this, the hard limit could be changed in the future manually,
through a process similar to the current one, though hopefully with
far less urgency and hysteria.
Another option is to add an additional calculation, preventing the new
maximum from being lower than 75% of the current maximum. This would
substantially slow down a block-size deflation attack.
Example of Block-Size Deflation Attack Prevention:
This would provide a maximum growth of 200% per recalculation, but a
maximum shrinkage of 75%.
Request For Comments:
I'd love to hear your thoughts. Why wouldn't this work? What portion
is flawed? Will the miners support such a proposal? Would this even
solve the block size issue?
I will note that I don't find the 100% and 25% to be hard and fast in
my idea. Those we're just the values that initially jumped out at me.
I could easily see the minimum being anything below 50% (above 50% and
the network can never adjust to smaller block sizes). I could also see
the maximum being anything over 100%. Lastly, if a inflation attack
is a valid concern, a hard upper limit could be set (or the historical
32MB limit could remain).
I think the great part about this variable approach is that the
network can adjust to address spikes in volume and readjust once those
spikes dissipate.
Justin M. Wray
Comment: GPGTools -
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.12.1 released | Wladimir J. van der Laan | Apr 15 2016

Wladimir J. van der Laan on Apr 15 2016:
Hash: SHA512
Bitcoin Core version 0.12.1 is now available from:
Or through bittorrent:
This is a new minor version release, including the BIP9, BIP68 and BIP112
softfork, various bugfixes and updated translations.
Please report bugs using the issue tracker at github:
To receive security and update notifications, please subscribe to
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrade warning

Downgrade to a version < 0.12.0

Because release 0.12.0 and later will obfuscate the chainstate on every
fresh sync or reindex, the chainstate is not backwards-compatible with
pre-0.12 versions of Bitcoin Core or other software.
If you want to downgrade after you have done a reindex with 0.12.0 or later,
you will need to reindex when you first start Bitcoin Core version 0.11 or
Notable changes

First version bits BIP9 softfork deployment
This release includes a soft fork deployment to enforce BIP68,
BIP112 and BIP113 using the BIP9 deployment mechanism.
The deployment sets the block version number to 0x20000001 between
midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for
deployment. The version number consists of 0x20000000 to indicate version
bits together with setting bit 0 to indicate support for this combined
deployment, shown as "csv" in the getblockchaininfo RPC call.
For more information about the soft forking change, please see
This specific backport pull-request can be viewed at
BIP68 soft fork to enforce sequence locks for relative locktime
BIP68 introduces relative lock-time consensus-enforced semantics of
the sequence number field to enable a signed transaction input to remain
invalid for a defined period of time after confirmation of its corresponding
For more information about the implementation, see
BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY
BIP112 redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV)
for a new opcode in the Bitcoin scripting system that in combination with
BIP68 allows execution pathways of a script to be restricted based
on the age of the output being spent.
For more information about the implementation, see
BIP113 locktime enforcement soft fork
Bitcoin Core 0.11.2 previously introduced mempool-only locktime
enforcement using GetMedianTimePast(). This release seeks to
consensus enforce the rule.
Bitcoin transactions currently may specify a locktime indicating when
they may be added to a valid block. Current consensus rules require
that blocks have a block header time greater than the locktime specified
in any transaction in that block.
Miners get to choose what time they use for their header time, with the
consensus rule being that no node will accept a block whose time is more
than two hours in the future. This creates a incentive for miners to
set their header times to future values in order to include locktimed
transactions which weren't supposed to be included for up to two more
The consensus rules also specify that valid blocks may have a header
time greater than that of the median of the 11 previous blocks. This
GetMedianTimePast() time has a key feature we generally associate with
time: it can't go backwards.
BIP113 specifies a soft fork enforced in this release that
weakens this perverse incentive for individual miners to use a future
time by requiring that valid blocks have a computed GetMedianTimePast()
greater than the locktime specified in any transaction in that block.
Mempool inclusion rules currently require transactions to be valid for
immediate inclusion in a block in order to be accepted into the mempool.
This release begins applying the BIP113 rule to received transactions,
so transaction whose time is greater than the GetMedianTimePast() will
no longer be accepted into the mempool.
Implication for miners: you will begin rejecting transactions that
would not be valid under BIP113, which will prevent you from producing
invalid blocks when BIP113 is enforced on the network. Any
transactions which are valid under the current rules but not yet valid
under the BIP113 rules will either be mined by other miners or delayed
until they are valid under BIP113. Note, however, that time-based
locktime transactions are more or less unseen on the network currently.
Implication for users: GetMedianTimePast() always trails behind the
current time, so a transaction locktime set to the present time will be
rejected by nodes running this release until the median time moves
forward. To compensate, subtract one hour (3,600 seconds) from your
locktimes to allow those transactions to be included in mempools at
approximately the expected time.
For more information about the implementation, see
The p2p alert system is off by default. To turn on, use -alert with
startup configuration.
0.12.1 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

  • - #7739 7ffc2bd Add abandoned status to listtransactions (jonasschnelli)

Block and transaction handling

  • - #7543 834aaef Backport BIP9, BIP68 and BIP112 with softfork (btcdrak)

P2P protocol and network code

    • #7804 90f1d24 Track block download times per individual block (sipa)
    • #7832 4c3a00d Reduce block timeout to 10 minutes (laanwj)


    • #7821 4226aac init: allow shutdown during 'Activating best chain...' (laanwj)
    • #7835 46898e7 Version 2 transactions remain non-standard until CSV activates (sdaftuar)

Build system

    • #7487 00d57b4 Workaround Travis-side CI issues (luke-jr)
    • #7606 a10da9a No need to set -L and --location for curl (MarcoFalke)
    • #7614 ca8f160 Add curl to packages (now needed for depends) (luke-jr)
    • #7776 a784675 Remove unnecessary executables from gitian release (laanwj)


  • - #7715 19866c1 Fix calculation of balances and available coins. (morcos)


    • #7617 f04f4fd Fix markdown syntax and line terminate LogPrint (MarcoFalke)
    • #7747 4d035bc added depends cross compile info (accraze)
    • #7741 a0cea89 Mark p2p alert system as deprecated (btcdrak)
    • #7780 c5f94f6 Disable bad-chain alert (btcdrak)

Thanks to everyone who directly contributed to this release:
    • accraze
    • Alex Morcos
    • BtcDrak
    • Jonas Schnelli
    • Luke Dashjr
    • MarcoFalke
    • Mark Friedenbach
    • NicolasDorier
    • Pieter Wuille
    • Suhas Daftuar
    • Wladimir J. van der Laan
As well as everyone that helped translating on Transifex.
Version: GnuPG v1
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Decrypt ANY Hash With PasswordsPro [ZIPIX] - YouTube SHA-256 checksum generation in Windows [Tamil] How to quickly verify MD5, SHA1 and SHA2 (256, 384, 512 ... Python Hash-Decrypter Program  Decode Hash Encryption ... Passwords & hash functions (Simply Explained) - YouTube

SHA-512 is a function of cryptographic algorithm SHA-2, which is an evolution of famous SHA-1.. SHA-512 is very close to Sha-256 except that it used 1024 bits "blocks", and accept as input a 2^128 bits maximum length string. SHA-512 also has others algorithmic modifications in comparison with Sha-256. These are examples of commonly used hashing algorithms. In the cryptocurrency world, SHA-256 is generally used the most. Facebook and Bitcoin use SHA-256 as their algorithm. The number means how ... To calculate cryptographic hashing value in Java, MessageDigest Class is used, under the package MessagDigest Class provides following cryptographic hash function to find hash value of a text as follows: MD2; MD5; SHA-1; SHA-224; SHA-256; SHA-384; SHA-512; These algorithms are initialized in static method called getInstance(). After selecting the algorithm the message digest ... The actual value used is of little consequence, but for those interested, the values used are obtained by taking the first 64 bits of the fractional parts of the square roots of the first 8 prime ... A minimal Bitcoin wallet intended for embedded devices - someone42/hardware-bitcoin-wallet. Skip to content. Sign up Why GitHub? ... * \param out A byte array where the HMAC-SHA512 hash value will be written. * This must have space for #SHA512_HASH_LENGTH bytes. * \param key A byte array containing the key to use in the HMAC-SHA512 * calculation. The key can be of any length. * \param key ...

[index] [10747] [18398] [36656] [31466] [50997] [957] [1877] [37849] [27048] [5380]

Decrypt ANY Hash With PasswordsPro [ZIPIX] - YouTube

Please watch: "HINDI What Is Dhcp Server Besics Video 2017 " -~-~~-~~~-~~-~- hi gusy aap ko eis video me Encrypt ... Hash: SHA512 The following is a demo of - a Bitcoin payments and exchange applicaiton which lets canadians pay bills and send money to anyone in Canada with Bitcoin. To find out more ... This video is unavailable. Watch Queue Queue. Watch Queue Queue How can companies store passwords safely and keep them away from hackers? Well let's find out! With all the data breaches lately, it's likely that the passwo... Hash values generation in block chain in Tamil (4) ... What is a Bitcoin hash and SHA-256 - Duration: 1:54. Ofir Beigel 63,450 views. 1:54. How to check the SHA 256 Checksum - Duration: 2:10 ...