Bitcoin Address To Public Key CryptoCoins Info Club

Groestlcoin 6th Anniversary Release

Introduction

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

UPDATED - Groestlcoin Core 2.18.2

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

How to Upgrade?

Windows
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

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

Download

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

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

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

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

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

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

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

Features

Live Version (Not Recommended)

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

Download

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

Source

ALL NEW! – Vanity Search Vanity Address Generator

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

Features

Usage

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

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

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

Features

Download

Source

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

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

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

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

Features

Download

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

Source

ALL NEW! – Electrum Personal Server

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

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

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

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

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

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

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

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

You can call you a Bitcoiner if you know/can explain these terms...

03/Jan/2009
10 Minutes
10,000 BTC Pizza
2016 Blocks
21 Million
210,000 Blocks
51% Attack
Address
Altcoin
Antonopoulos
Asic
Asic Boost
Base58
Batching
Bech32
Bit
Bitcoin Cash
Bitcoin Improvement Proposal (BIP)
Bitcoin SV
Bitmain
Block
Block height
Block reward
Blockchain
Blockexplorer
Bloom Filter
Brain Wallet
Buidl
Change Address
Child pays for parent (CPFP)
Coinbase (not the exchange)
CoinJoin
Coinmarketcap (CMC)
Colored Coin
Confirmation
Consensus
Custodial Wallet
Craig Wright
David Kleinman
Difficulty
Difficulty adjustment
Difficulty Target
Dogecoin
Dorian Nakamoto
Double spend
Elliptic Curve Digital Signature Algorithm (ECDSA)
Ethereum
Faketoshi
Fork
Full Node
Gavin Andresen
Genesis Block
Getting goxed
Halving
Hard Fork
Hardware Wallet
Hash
Hashing
Hierarchical Deterministic (HD) Wallet
Hodl
Hot Wallet
Initial Coin Offering (ICO)
Initial Exchange Offering (IEO)
Ledger
Light Node
Lightning
Litecoin
Locktime
Mainnet
Malleability
Master Private Key
Master Public Key
Master Seed
mBTC
Mempool
Merkle Tree
Mining
Mining Farm
Mining Pool
Mixing
MtGox
Multisig
Nonce
Not your keys,...
Opcode
Orphan block
P2PKH
P2SH
Paper Wallet
Peers
Pieter Wuille
Premining
Private key
Proof of Stake (PoS)
Proof of Work (PoW)
Pruning
Public key
Pump'n'Dump
Replace by Fee (RBF)
Ripemd160
Roger Ver
sat
Satoshi Nakamoto
Schnorr Signatures
Script
Segregated Witness (Segwit)
Sha256
Shitcoin
Sidechain
Signature
Signing
Simplified Payment Verification (SPV)
Smart Contract
Soft Fork
Stratum
Syncing
Testnet
Transaction
Transaction Fees
TransactionId (Txid)
Trezor
User Activated Soft Fork (UASF)
Utxo
Wallet Import Format (WIF)
Watch-Only Address
Whitepaper
List obviously not complete. Suggestions appreciated.
Refs:
https://bitcoin.org/en/developer-glossary https://en.bitcoin.it/wiki/Main_Page https://www.youtube.com/channel/UCgo7FCCPuylVk4luP3JAgVw https://www.youtube.com/useaantonop
submitted by PolaT1x to Bitcoin [link] [comments]

PSA: Guide on how to recover your lost Segwit coins using Electron Cash

How to get your recovered SegWit funds using Electron Cash

Background

Thousands of BCH on thousands of coins that were accidentally send to Segwit 3xxx addresses were recovered by BTC.TOP in block 582705.
This was a wonderful service to the community. This had to be done quickly as the coins were anyone can spend and needed to be sent somewhere. This all had to be done before thieves could get their dirty paws on them.
So.. How were they recovered? Did BTC.TOP just take the coins for themselves? NO: They were not taken by BTC.TOP. This would be wrong (morally), and would open them up to liability and other shenanigans (legally).
Instead --BTC.TOP acted quickly and did the legally responsible thing with minimal liability. They were sent on to the intended destination address of the SegWit transaction (if translated to BCH normal address).
This means BTC.TOP did not steal your coins and/or does not have custody of your funds!
But this does mean you now need to figure out how to get the private key associated with where they were sent -- in order to unlock the funds. (Which will be covered below).
Discussions on why this was the most responsible thing to do and why it was done this way are available upon request. Or you can search this subreddit to get to them.

Ok, so BTC.TOP doesn't have them -- who does?

You do (if they were sent to you)! Or -- the person / address they were sent to does!

HUH?

The Segwit transactions have a bad/crazy/messed-up format which contains an output (destination) which contains a hash of a public key inside. So they "sort of" contain a regular bitcoin address inside of them, with other Segwit garbage around them. This hash was decoded and translated to a regular BCH address, and the funds were sent there.
Again: The funds were forwarded on to a regular BCH address where they are safe. They are now guarded by a private key -- where they were not before (before they were "anyone can spend"). It can be argued this is the only reasonable thing to have done with them (legally and morally) -- continue to send them to their intended destination. This standard, if it's good enough for the US Post Office and Federal Mail, is good enough here. It's better than them being stolen.

Ok, I get it... they are on a regular BCH address now. The address of the destination of the Tx, is it?

Yes. So now a regular BCH private key (rather than anyone can spend) is needed to spend them further. Thus the Segwit destination address you sent them to initially was effectively translated to a BCH regular address. It's as if you posted a parcel with the wrong ZIP code on it -- but the USPS was nice enough to figure that out and send it to where you intended it to go.

Why do it this way and not return to sender?

Because of the ambiguity present-- it's not entirely clear which sender to return them to. There is too much ambiguity there, and would have led to many inputs not being recovered in a proper manner. More discussion on this is available upon request.

Purpose of this guide

This document explains how to:
Complications to watch out for:

Step 1: Checking where your coins went

To verify if this recovery touched one of your lost coins: look for the transaction that spent your coins and open it on bch.btc.com explorer.

Normal aka "P2PKH"

Let’s take this one for example.
Observe the input says:
P2SH 160014d376cf1baff9eeed943d58551d53c48377adb98c 
And the output says:
P2PKH OP_DUP OP_HASH160 d376cf1baff9eeed943d58551d53c48377adb98c OP_EQUALVERIFY OP_CHECKSIG 
Notice a pattern?
The fact that these two highlighted hexadecimal strings are the same means that the funds were forwarded to the identical public key, and can be spent by the private key (corresponding to that public key) if it is imported into a Bitcoin Cash wallet.

Multisig aka "P2SH"

If the input starts with “P2SH 220020…”, as in this example, then your segwit address is a script -- probably a multisignature. While the input says “P2SH 22002019aa2610492ee2c18605597136294596d4f0f9bc6ce0974ed3a975d65da4ca1e”, the output says “P2SH OP_HASH160 21bdc73fb15b3bb7bd1be365e92447dc2a44e662 OP_EQUAL”. These two strings actually correspond to the same script, but they are different in content and length due to segwit’s design. However, you just need to RIPEMD160 hash the first string and compare to the second -- you can check this by entering the input string (after the 220020 part) into this website’s Binary Hash field and checking the resulting RIPEMD160 hash. The resulting hash is 21bdc73fb15b3bb7bd1be365e92447dc2a44e662, which corresponds to the output hex above, and this means the coins were forwarded to the same spending script but in "non-segwit form". You will need to re-assemble the same multi-signature setup and enough private keys on a Bitcoin Cash wallet. (Sorry for the succinct explanation here. Ask in the comments for more details perhaps.)

No match -- what?!

If the string does not match (identically in the Normal case above, or after properly hashing in the Multisig case above), then your coins were sent elsewhere, possibly even taken by an anonymous miner. :'(

Step 2: How To Do the Recovery

Recover "Normal" address transactions (P2PKH above)

This is for recoveries where the input string started with “160014”.
Option 1 (BIP39 seed):
Option 2 (single key):
Option 3 (xprv -- many keys):
Code:
mkey = "yprvAJ48Yvx71CKa6a6P8Sk78nkSF7iqqaRob1FN7Jxsqm3L52K8XmZ7EtEzPzTUWXAaHNfN4DFAuP4cdM38yrE6j3YifV8i954hyD5rhPyUNVP" from electroncash.bitcoin import DecodeBase58Check, EncodeBase58Check EncodeBase58Check(b'\x04\x88\xad\xe4'+DecodeBase58Check(mkey)[4:]) 
Option 4 (hardware wallet):

How to Recover Multisignature wallets (P2WSH-in-P2SH in segwit parlance)

This is for recoveries where the input string started with "220020.
Please read the above instructions for how to import single keys. You will need to do similar but taking care to reproduce the same set of multisignature keys as you had in the BTC wallet. Note that Electron Cash does not support single-key multisignature, so you need to use the BIP39 / xprv approach.
If you don’t observe the correct address in Electron Cash, then check the list of public keys by right clicking on an address, and compare it to the list seen in your BTC wallet. Also ensure that the number of required signers is identical.
submitted by NilacTheGrim to btc [link] [comments]

A 12 word seed provides 128 bit entropy. A 24 word seed provides 256 bit entropy (refuced to 160 bits by ripemd160). How much entropy does a 12 word seed with additional self-chosen password/passphrase provide?

typo: "reduced"
Edit: My conclusion (see comments in the thread) is that already a rather weak password added to the 12 word seed is sufficient to boost the seed's overall entropy from 128 bit to above 160 bit, which is the entropy of a private key itself (due to RIPEMD160 hash).
So with a sole 12-word seed, a brute force attacker would be much better off attacking the seed (128 bit) than the private key itself (160 bit). But with a moderately complex 13th password on top of the 12-word seed, the seed's entropy would exceed 160 bit and the attacker would be better off brute-forcing the private key directly.
Important: This logic only holds if I do NOT use the password-free 12-word-seed wallet at all! Because, if I store some dummy bitcoins on the wallet without passphrase, the successful attacker has already found a valid seed with a 128-bit attack and needs negligible additive (instead of otherwise multiplicative) extra effort (say 32 bits) to find my full wallet, which thereby lost its 160 bit security!
submitted by Amichateur to Bitcoin [link] [comments]

Hashcat benchmark on GeForce NOW

OpenCL Platform #1: NVIDIA Corporation

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

Benchmark relevant options:

* --optimized-kernel-enable

Hashmode: 0 - MD5

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

Hashmode: 100 - SHA1

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

Hashmode: 1400 - SHA2-256

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

Hashmode: 1700 - SHA2-512

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

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

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

Hashmode: 1000 - NTLM

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

Hashmode: 3000 - LM

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

Hashmode: 5500 - NetNTLMv1 / NetNTLMv1+ESS

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

Hashmode: 5600 - NetNTLMv2

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

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

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

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

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

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

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

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

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

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

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

Hashmode: 13100 - Kerberos 5 TGS-REP etype 23

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

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

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

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

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

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

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

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

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

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

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

Hashmode: 13000 - RAR5 (Iterations: 32767)

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

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

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

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

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

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

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

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

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

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

An exhaustive look at private keys for the uninitiated.

I wrote this explanation of private keys several months ago for folks in /BitcoinBeginners, but I thought some of the new people here might get some benefit out of it. There is no TL;DR. Sorry for the length! Any corrections or clarifications are welcome and appreciated!
A private key is just a really big number--that's it. If someone discovers the number you've chosen to use as your private key, they will be able to access any bitcoins assigned to that number. This may seem disconcerting at first. After all, if someone were to just happen to guess your number, they would have access to all your bitcoins, right? But many types of security come down to knowing or possessing something that is difficult to guess or reproduce. For example, a Master brand combination padlock with a 3 number combination on a dial with 0-36 has around 50,653 possible combinations (373 ). A typical pin-tumbler lock today has 5 pins with each pin having only about 10 different height levels meaning that there are only 100,000 (105 ) effective combinations for an average house key. Even a credit card number is only 15 characters long with 10 digits per character. That means there are only 1015 possible combinations of credit card numbers which is equivalent to about 1 quadrillion (there is some added security by combining that number with an expiration date and 3-digit security code, but I'm ignoring that for now). The point is, we're accustomed to using much smaller pools of possible combinations to protect many parts of our lives today.
By comparison, a private key for Bitcoin begins as a 256-bit number or a number that is 256 characters long with 2 digits per character (a bit in the binary number system that computers understand is either 1 or 0), which is 2256. That's huge. How huge? Remember that 1015 was equal to a quadrillion? A 256-bit private key used for Bitcoin can be any number between 0 and 115 quattuorvigintillion 792 trevigintillion 89 duovigintillion 237 unvigintillion 316 vigintillion 195 novemdecillion 423 octodecillion 570 septendecillion 985 sexdecillion 8 quindecillion 687 quattuordecillion 907 tredecillion 852 duodecillion 837 undecillion 564 decillion 279 nonillion 74 octillion 904 septillion 382 sextillion 605 quintillion 163 quadrillion 141 trillion 518 billion 161 million 494 thousand 336.
In reality (because of some of the fancy math we do to that 256-bit number to make it a bit more useable create the public key pair value which we will use as the address), some of the available addresses will overlap, so the actual pool of available addresses is more like 2160, but we're still talking about a gigantic number of possible addresses. To give you some context on the sheer scale of 2160, the number of grains of sand on the Earth is estimated at about 266. The number of stars in the universe is estimated at about 276. There are approximately 296 atoms in a cubic meter of water, and the number of atoms in the sun is estimated at 2190. Need a visual comparison? This graph shows the number of available Bitcoin addresses compared to the width of the universe in Zeptometers (one Zeptometer is one quintillionth of a meter) and the age of the universe in Yoctoseconds (one Yoctosecond is one sextrillionth of a second). So your private key with its 2160 possible combinations should be pretty safely hidden. Even a computer that could execute 1013 instructions per second would take around 5 trillion years to guess your private key.
Since most humans can't keep a number in the quatturovigintillion's in their head, there are a number of tricks we can use to make it easier to manage. One thing we can do is to reduce the number of characters we have to remember, and the way to do that is to change the numerical base we use. Computers represent numbers in binary (also called base 2) which means every digit in the number is either a 0 or 1. To represent a private key in base 2, we have to use 256 places. To represent the same number in the base 10 we most commonly use, where each digit can be 0-9, we would only need 77 places. So, the higher the base, the smaller the resulting string. Base 16 (also known as hexadecimal) uses 0-9 and A-F for a total of 16 different possibilities for each digit. This reduces the number of places needed to represent the number to 64. There are many other bases that use different characters to represent more and more of the number, but the most common numerical base to use for Bitcoin addresses is Base 58 (actually, it's a special version of Base 58 called Base58Check which only uses characters that are not easily confused visually like 0 and O, and includes a 32-bit checksum appended to the payload, and has an extra step to preserve leading zero bytes). The result is a string of letters and numbers that is usually about 51 characters long.
Of course, if you don't want to waste time trying to memorize a string of 51 characters, most of us trust our Bitcoin wallet applications to write that number to a file and to keep track of it for us. But anytime you write down your key, you make it vulnerable to being discovered, especially if the thing you write it on is connected to the Internet. This is why it is smart to encrypt the file containing your private key. And this is where some people get confused: The passphrase for your private key, in this example, is only for locally decrypting a file on your computer or device that stores your private key. It is not for using or accessing the private key itself. You cannot passphrase-protect the ability to use your private key to prevent an unauthorized person from using your private key, you can only take steps to hide what that key actually is.
Another way you can hide your private key to make it easier to transport on paper is by using an encryption process developed specifically for Bitcoin addresses known as BIP38 (BIP stands for Bitcoin Improvement Proposal). BIP38 allows you to create a new address which looks similar to a Bitcoin private key, but will not function as one directly. Instead, you will need to decrypt the BIP38 address using a program that understands how to decrypt BIP38 using the passphrase that encrypted the address. This is a handy process because you can carry a BIP38 protected address around on a piece of paper, and as long as you remember the passphrase, your bitcoins should remain safe even if the paper is stolen or lost. Again, this doesn't protect someone from using your private key if they discover it in some other way, but it will conceal your private key when you write it down to make it more difficult to discover.
Now, you may have heard in some cases that a passphrase is a private key. This may be confusing, but this is just referring to another way to keep track of this very large number. There are mathmatical formulas that can take data of any length and by passing it through the formula they create a number with the same number of bits every time. These formulas are called hashing algorithms. One such hashing algorithm is called SHA-256 which can take data of any length and produce a 256-bit number from it. You could give it a single word that's 6 letters long, or give it a text file with all the collected works of William Shakespeare in it and each one would produce a unique 256-bit number. And because of the properties of the formula, as long as you feed it the same data that you did originally it will always produce the same number as a result (called a hash). So, when someone tells you that their passphrase is their private key, they mean that they have fed their passphrase through a hashing algorithm to produce a 256-bit number from which they can use as their private key. This process is also known as a brain wallet. While this may seem clever you're essentially pitting your memory capacity against a cracker with a computer, and the odds are the computer will win. Please avoid using brain wallets if you have the choice.
If your private key is ever exposed or if it can ever be calculated using a hashing algorithm, that is all someone needs to take any bitcoins contained in that address, so take good care of it!
edit: just clarifying a couple of points
edit2: updated the name of the number between which private keys can be used, and clarifying that the math is applied to the public key which is what introduces the potential for collisions
edit3: clarifying what Base58Check differs from Base58
submitted by spectyr to Bitcoin [link] [comments]

Transcript of Open Developer Meeting in Discord - 7/19/2019

[Dev-Happy] BlondfrogsLast Friday at 3:58 PM
Hey everyone. The channel is now open for the dev meeting.
LSJI07 - MBITLast Friday at 3:58 PM
Hi
TronLast Friday at 3:59 PM
Hi all!
JerozLast Friday at 3:59 PM
:wave:
TronLast Friday at 3:59 PM
Topics: Algo stuff - x22rc, Ownership token for Restricted Assets and Assets.
JerozLast Friday at 4:00 PM
@Milo is also here from coinrequest.
MiloLast Friday at 4:00 PM
Hi :thumbsup:
Pho3nix Monk3yLast Friday at 4:00 PM
welcome, @Milo
TronLast Friday at 4:00 PM
Great.
@Milo Was there PRs for Android and iOS?
MiloLast Friday at 4:01 PM
Yes, I've made a video. Give me a second I'll share it asap.
JerozLast Friday at 4:02 PM
I missed the iOS one.
MiloLast Friday at 4:02 PM
Well its 1 video, but meant for all.
JerozLast Friday at 4:02 PM
Ah, there's an issue but no pull request (yet?)
https://github.com/RavenProject/ravenwallet-ios/issues/115
[Dev-Happy] BlondfrogsLast Friday at 4:03 PM
nice @Milo
MiloLast Friday at 4:04 PM
Can it be that I have no video post rights?
JerozLast Friday at 4:05 PM
In discord?
MiloLast Friday at 4:05 PM
yes?
[Dev-Happy] BlondfrogsLast Friday at 4:05 PM
just a link?
JerozLast Friday at 4:05 PM
Standard version has a file limit afaik
Pho3nix Monk3yLast Friday at 4:05 PM
try now
gave permissions
MiloLast Friday at 4:05 PM
it's not published yet on Youtube, since I didn't knew when it would be published in the wallets
file too big. Hold on i'll put it on youtube and set it on private
LSJI07 - MBITLast Friday at 4:06 PM
no worries ipfs it...:yum:
Pho3nix Monk3yLast Friday at 4:06 PM
ok, just send link when you can
[Dev-Happy] BlondfrogsLast Friday at 4:07 PM
So guys. We released Ravencoin v2.4.0!
JerozLast Friday at 4:08 PM
If you like the code. Go update them nodes! :smiley:
[Dev-Happy] BlondfrogsLast Friday at 4:08 PM
We are recommending that you are upgrading to it. It fixes a couple bugs in the code base inherited from bitcoin!
MiloLast Friday at 4:08 PM
https://www.youtube.com/watch?v=t\_g7NpFXm6g&feature=youtu.be
sorry for the hold up
YouTube
Coin Request
Raven dev Gemiddeld
LSJI07 - MBITLast Friday at 4:09 PM
thanks short and sweet!!
KAwARLast Friday at 4:10 PM
Is coin request live on the android wallet?
TronLast Friday at 4:10 PM
Nice video.
It isn't in the Play Store yet.
Pho3nix Monk3yLast Friday at 4:10 PM
Well, this is the first time in a while where we have this many devs online. What questions do y'all have?
LSJI07 - MBITLast Friday at 4:11 PM
Algo questions?
Pho3nix Monk3yLast Friday at 4:11 PM
sure
KAwARLast Friday at 4:11 PM
KK
LSJI07 - MBITLast Friday at 4:12 PM
what are the proposed 22 algos in x22r? i could only find the original 16 plus 5 on x21.
TronLast Friday at 4:12 PM
Likely the 5 from x21 and find one more.
We need to make sure they're all similar in time profile.
liqdmetalLast Friday at 4:14 PM
should we bother fixing a asic-problem that we dont know exists for sure or not?
TronLast Friday at 4:14 PM
That's the 170 million dollar question.
[Dev-Happy] BlondfrogsLast Friday at 4:14 PM
I would prefer to be proactive not reactive.
imo
JerozLast Friday at 4:14 PM
same
LSJI07 - MBITLast Friday at 4:15 PM
RIPEMD160 is a golden oldie but not sure on hash speed compared to the others.
liqdmetalLast Friday at 4:15 PM
in my mind we should focus on the restricted messaging etc
Sevvy (y rvn pmp?)Last Friday at 4:15 PM
probably won't know if the action was needed until after you take the action
liqdmetalLast Friday at 4:15 PM
we are at risk of being interventionistas
acting under opacity
TronLast Friday at 4:15 PM
Needs to spit out at least 256 bit. Preferably 512 bit.
LSJI07 - MBITLast Friday at 4:15 PM
ok
TronLast Friday at 4:15 PM
If it isn't 512 bit, it'll cause some extra headache for the GPU mining software.
liqdmetalLast Friday at 4:16 PM
i seek to avoid iatrogenics
TronLast Friday at 4:16 PM
Similar to the early problems when all the algos except the first one were built for 64-bytes (512-bit) inputs.
Had to look that one up. TIL iatrogenics
JerozLast Friday at 4:17 PM
I have to google most of @liqdmetal's vocabulary :smile:
liqdmetalLast Friday at 4:17 PM
@Tron tldr: basically the unseen, unintended negative side effects of the asic "cure"
Sevvy (y rvn pmp?)Last Friday at 4:18 PM
10 dolla word
liqdmetalLast Friday at 4:19 PM
we need a really strong case to intervene in what has been created.
TronLast Friday at 4:19 PM
I agree. I'm less concerned with the technical risk than I am the potential split risk experienced multiple times by Monero.
Sevvy (y rvn pmp?)Last Friday at 4:20 PM
tron do you agree that forking the ravencoin chain presents unique risks compared to other chains that aren't hosting assets?
JerozLast Friday at 4:21 PM
Yes, if you fork, you need to figure out for each asset which one you want to support.
Sevvy (y rvn pmp?)Last Friday at 4:21 PM
yeah. and the asset issuer could have a chain preference
TronLast Friday at 4:22 PM
@Sevvy (y rvn pmp?) Sure. Although, I'd expect that the asset issuers will be honor the assets on the dominant chain. Bigger concern is the branding confusion of multiple forks. See Bitcoin, Bitcoin Cash, Bitcoin SV for an example. We know they're different, but do non-crypto folks?
Hans_SchmidtLast Friday at 4:22 PM
I thought that the take-away from the recently published analyses and discussions was that ASICs for RVN may be active, but if so then they are being not much more effective than GPUs.
Sevvy (y rvn pmp?)Last Friday at 4:22 PM
agreed on all accounts there tron
TronLast Friday at 4:23 PM
I'm not yet convinced ASICs are on the network.
KAwARLast Friday at 4:23 PM
It would be better to damage an asic builder by forking after they made major expenses. Creating for them the type of deficit that could be negated by just buying instead of mining. Asic existence should be 100 percent confirmed before fork.
liqdmetalLast Friday at 4:23 PM
170million dollar question is right.lol
TronLast Friday at 4:24 PM
I've had someone offer to connect me to the folks at Fusion Silicon.
Sevvy (y rvn pmp?)Last Friday at 4:25 PM
yes. and if they are active on the network they are not particularly good ASICs
which makes it a moot point probably
TronLast Friday at 4:26 PM
The difficult part of this problem is that by the time everyone agrees that ASICs are problematic on the network, then voting the option in is likely no longer an option.
Sevvy (y rvn pmp?)Last Friday at 4:26 PM
yes. part of me wonders if we would say "okay, the clock on the asic countdown is reset by this new algo. but now the race is on"
[Dev-Happy] BlondfrogsLast Friday at 4:26 PM
There are always risks when making a change that will fork the network. We want wait to long though, as tron said. It wont be a voting change. it will be a mandatory change at a block number.
Sevvy (y rvn pmp?)Last Friday at 4:26 PM
acknowledge the inevitable
MiloLast Friday at 4:27 PM
I had just a small question from my side. When do you think the android version would be published, and do you maybe have a time-frame for the others?
TronLast Friday at 4:27 PM
Quick poll. How would everyone here feel about a BIP9 option - separate from the new features that can be voted in?
KAwARLast Friday at 4:27 PM
Maybe voting should not be a strictly blockchain vote. A republic and a democratic voice?
[Dev-Happy] BlondfrogsLast Friday at 4:27 PM
@Milo We can try and get a beta out next week, and publish soon after that.
MiloLast Friday at 4:28 PM
@[Dev-Happy] Blondfrogs :thumbsup::slight_smile:
[Dev-Happy] BlondfrogsLast Friday at 4:28 PM
BIP9 preemptive vote. I like it.
TronLast Friday at 4:30 PM
The advantage to a BIP9 vote is that it puts the miners and mining pools at a clear majority before activation.
LSJI07 - MBITLast Friday at 4:30 PM
Centralisation is inevitable unless we decide to resist it. ASIC's are market based and know the risks and rewards possible. A key step in resisting is sending a message. An algo change to increase asic resistance is imho a strong message. A BIP9 vote now would also be an indicator of bad actors early....
TronLast Friday at 4:30 PM
The disadvantage is that it may not pass if the will isn't there.
LSJI07 - MBITLast Friday at 4:30 PM
Before assets are on main net and cause additional issues.
KAwARLast Friday at 4:31 PM
I am not schooled in coding to have an educated voice. I only understand social problems and how it affects the economy.
SpyderDevLast Friday at 4:31 PM
All are equal on RVN
TronLast Friday at 4:31 PM
It is primarily a social problem. The tech change is less risky and is easier than the social.
LSJI07 - MBITLast Friday at 4:32 PM
All can have a share....people who want more of a share however pay for the privilege and associated risks.
KAwARLast Friday at 4:33 PM
Assets and exchange listings need to be consistent and secure.
brutoidLast Friday at 4:36 PM
I'm still not entirely clear on what the overall goal to the algo change is? Is it just to brick the supposed ASICs (unknown 45%) which could still be FPGAs as seen from the recent block analysis posted in the nest. Is the goal to never let ASICs on? Is it to brick FPGAs ultimately. Are we making Raven strictly GPU only? I'm still unclear
LSJI07 - MBITLast Friday at 4:37 PM
What about the future issue of ASICs returning after a BIP9 fork "soon"? Are all following the WP as a community? i.e asic resistant or are we prepared to change that to asic resistant for early coin emission. Ideally we should plan for the future. Could the community make a statement that no future algo changes will be required to incentivise future public asic manufacturers?
Lol. Same question @brutoid
brutoidLast Friday at 4:37 PM
Haha it is
You mind-beamed me!
[Dev-Happy] BlondfrogsLast Friday at 4:38 PM
The is up to the community.
Currently, the feel seems like the community is anti asic forever.
The main issue is getting people to upgrade.
KAwARLast Friday at 4:38 PM
Clarity is important. Otherwise we are attacking windmills like Don Quixote.
brutoidLast Friday at 4:39 PM
I'm not getting the feeling of community ASIC hate if the last few weeks of discussion are anything to go by?
Hans_SchmidtLast Friday at 4:39 PM
A unilateral non-BIP9 change at a chosen block height is a serious thing, but anti-ASIC has been part of the RVN philosophy since the whitepaper and is therefore appropriate for that purpose.
[Dev-Happy] BlondfrogsLast Friday at 4:39 PM
We can use the latest release as an example. It was a non forking release, announced for 2 weeks. and only ~30% of the network has upgraded.
TronLast Friday at 4:39 PM
@Hans_Schmidt Well said.
liqdmetalLast Friday at 4:40 PM
I'm not concerned about a "asic hardware problem" so much as I believe it more likely what we are seeing is several big fish miners (perhaps a single really big fish). For now I recommend standing pat on x16r. In the future I can see an algo upgrade fork to keep the algo up to date. If we start fighting against dedicated x16r hashing machines designed and built to secure our network we are more likely to go down in flames. The custom SHA256 computers that make the bitcoin the most secure network in existence are a big part of that security. If some party has made an asic that performs up to par or better than FPGA or GPU on x16r, that is a positive for this network, a step towards SHA256 security levels. It is too bad the community is in the dark regarding their developments. Therefore I think the community has to clarify its stance towards algorithm changes. I prefer a policy that will encourage the development of mining software, bitstreams and hardware by as many parties as possible. The imminent threat of ALGO fork screws the incentive up for developers.
JerozLast Friday at 4:40 PM
@brutoid the vocal ones are lenient towards asics, but the outcome of the 600+ votes seemed pretty clear.
brutoidLast Friday at 4:40 PM
This is my confusion
TronLast Friday at 4:41 PM
More hashes are only better if the cost goes up proportionally. Machines that do more hashes for less $ doesn't secure the network more, and trends towards centralization.
JerozLast Friday at 4:41 PM
I would argue for polling ever so often as it certainly will evolve dynamically with the state of crypto over time.
TronLast Friday at 4:41 PM
Measure security in two dimensions. Distribution, and $/hash.
liqdmetalLast Friday at 4:41 PM
and volume of hash
traysiLast Friday at 4:42 PM
45% of the hashrate going to one party is unhealthy, and standing pat on x16r just keeps that 45% where it is.
TronLast Friday at 4:42 PM
Volume doesn't matter if the cost goes down. For example, lets say software shows up that does 1000x better than the software from yesterday, and everyone moves to it. That does not add security. Even if the "difficulty" and embedded hashes took 1000x more attempts to find.
brutoidLast Friday at 4:42 PM
My issue is defintely centralization of hash and not so much what machine is doing it. I mine with both GPU and FPGA. Of course, the FPGAs are not on raven
TJayLast Friday at 4:44 PM
easy solution is just to replace a few of 16 current hash functions, without messing with x21r or whatever new shit
TronLast Friday at 4:44 PM
How do folks here feel about allowing CPUs back in the game?
traysiLast Friday at 4:44 PM
Botnets is my concern with CPUs
brutoidLast Friday at 4:44 PM
Botnets is my concern
SpyderDevLast Friday at 4:44 PM
Yes please.
LSJI07 - MBITLast Friday at 4:44 PM
the poll votes seem not very security conscious. More of day miners chasing profits. I love them bless! Imho the future is bright for raven, however these issues if not sorted out now will bite hard long term when asset are on the chain and gpu miners are long gone.....
ZaabLast Friday at 4:45 PM
How has the testing of restricted assets been on the test net?
liqdmetalLast Friday at 4:45 PM
Agreed. I dont think x16r is obsolete like that yet however
[Dev-Happy] BlondfrogsLast Friday at 4:45 PM
@Zaab not enough testing at the moment.
HedgerLast Friday at 4:45 PM
Yes, how is the Testing going?
justinjjaLast Friday at 4:45 PM
Like randomX or how are cpus going to be back in the game?
TronLast Friday at 4:45 PM
@Zaab Just getting started at testing at the surface level (RPC calls), and fixing as we go.
ZaabLast Friday at 4:45 PM
And or any updates on the review of dividend code created by the community
Lokar -=Kai=-Last Friday at 4:45 PM
if the amount of hash the unknown pool has is fixed as standarderror indicated then waiting for the community of FPGAers to get onto raven might be advantageous if the fork doesn't hurt FPGAs.
ZaabLast Friday at 4:45 PM
Can't rememeber who was on it
SpyderDevLast Friday at 4:45 PM
@Zaab But we are working on it...
Lokar -=Kai=-Last Friday at 4:46 PM
more hash for votes
JerozLast Friday at 4:46 PM
@Maldon is, @Zaab
TronLast Friday at 4:46 PM
@Zaab There are unit tests and functional tests already, but we'd like more.
[Dev-Happy] BlondfrogsLast Friday at 4:46 PM
@Zaab Dividend code is currently adding test cases for better security. Should have more update on that next meeting
KAwARLast Friday at 4:46 PM
Absolute democracy seems to resemble anarchy or at least civil war. In EVE online they have a type of community voice that get voted in by the community.
ZaabLast Friday at 4:46 PM
No worries was just curious if it was going as planned or significant issues were being found
Obviously some hiccups are expected
More testing is always better!
TronLast Friday at 4:47 PM
Who in here is up for a good civil war? :wink:
ZaabLast Friday at 4:47 PM
Tron v Bruce. Celebrity fight night with proceeds to go to the RVN dev fund
SpyderDevLast Friday at 4:48 PM
Cagefight or mudpit?
JerozLast Friday at 4:48 PM
talking about dev funds..... :wink:
Pho3nix Monk3yLast Friday at 4:49 PM
and there goes the conversation....
KAwARLast Friday at 4:49 PM
I am trying to be serious...
ZaabLast Friday at 4:49 PM
Sorry back to the ascii topic!
traysiLast Friday at 4:49 PM
@Tron What do we need in order to make progress toward a decision on the algo? Is there a plan or a roadmap of sorts to get us some certainty about what we're going to do?
LSJI07 - MBITLast Friday at 4:50 PM
Could we have 3 no BIP9 votes? No1 Friendly to asics, retain status quo. No2 change to x17r minimal changes etc, with no additional future PoW/algo upgrades. No3. Full Asic resistance x22r and see what happens...
:thonk~1:
Sounds messy....
TronLast Friday at 4:51 PM
Right now we're in research mode. We're building CNv4 so we can run some metrics. If that goes well, we can put together x22rc and see how it performs. It will likely gore everyone's ox. CPUs can play, GPUs work, but aren't dominant. ASICs VERY difficult, and FPGAs will have a tough time.
ZaabLast Friday at 4:51 PM
Yeah i feel like the results would be unreliable
TronLast Friday at 4:51 PM
Is this good, or do we lose everyone's vote?
PlayHardLast Friday at 4:52 PM
Fpga will be dead
Lokar -=Kai=-Last Friday at 4:52 PM
why isn;t a simple XOR or something on the table?
ZaabLast Friday at 4:52 PM
The multiple bip9 that is
Lokar -=Kai=-Last Friday at 4:52 PM
something asic breaking but doesn't greatly complicate ongoing efforts for FPGA being my point.
justinjjaLast Friday at 4:52 PM
How are you going to vote for x22rc?
Because if by hashrate that wouldn't pass.
traysiLast Friday at 4:52 PM
Personally I like the idea of x22rc but I'd want to investigate the botnet threat if CPUs are allowed back in.
TronLast Friday at 4:52 PM
XOR is on the table, and was listed in my Medium post. But, the social risk of chain split remains, for very little gain.
traysiLast Friday at 4:53 PM
@Lokar -=Kai=- A small change means that whoever has 45% can probably quickly adapt.
LSJI07 - MBITLast Friday at 4:53 PM
Research sounds good. x22rc could be reduce to x22r for simplicity...
TronLast Friday at 4:53 PM
x22r is a viable option. No CNv4.
LSJI07 - MBITLast Friday at 4:53 PM
Don't know how much time we have to play with though...
Lokar -=Kai=-Last Friday at 4:53 PM
if they have FPGAs yes if they have ASIC then not so much, but I guess that gets to the point, what exactly are we trying to remove from the network?
PlayHardLast Friday at 4:54 PM
Guys my name is Arsen and we designed x16r fpga on bcus. Just about to release it to the public. I am buzzdaves partner.
Cryptonight
Will kill us
But agreed
Asic is possible on x16r
And you dont need 256 core
Cores
traysiLast Friday at 4:55 PM
Hi Arsen. Are you saying CN will kill "us" meaning RVN, or meaning FPGA?
JerozLast Friday at 4:55 PM
This is what im afraid of ^ an algo change killing FPGA as I have the feeling there is a big fpga community working on this
PlayHardLast Friday at 4:55 PM
Fpgas ))
whitefire990Last Friday at 4:55 PM
I am also about to release X16R for CVP13 + BCU1525 FPGA's. I'm open to algo changes but I really don't believe in CPU mining because of botnets. Any CNv4 shifts 100% to CPU mining, even if it is only 1 of the 22 functions.
Lokar -=Kai=-Last Friday at 4:55 PM
namely FPGAs that aren;t memory equipped
like fast mem
not ddr
PlayHardLast Friday at 4:55 PM
Hbm non hbm
Cryptonight
whitefire990Last Friday at 4:56 PM
Right now with both Buzzdave/Altered Silicon and myself (Zetheron) about to release X16R for FPGA's, then the 45% miner's share will decrease to 39% or less.
PlayHardLast Friday at 4:56 PM
Will be dead for fpga
LSJI07 - MBITLast Friday at 4:56 PM
sound so x22r is fpga "friendly" ... more so than asic anyway...
PlayHardLast Friday at 4:56 PM
But a change must be planned
X16r is no way possible to avoid asics
TJayLast Friday at 4:56 PM
@LSJI07 - MBIT I would say less friendly...
whitefire990Last Friday at 4:57 PM
As I mentioned in thenest discussion, asic resistance increases with the square of the number of functions, so X21R is more asic resistant than X16R, but both are pretty resistant
PlayHardLast Friday at 4:58 PM
Yeah more algos make it heavier on ASIC
DirkDiggler (Citadel Architect)Last Friday at 4:58 PM
My interpretation of the whitepaper was that we used x16r as it was brand new (thus ASIC resistant), and that was to ensure a fair launch... We've launched... I don't like the idea of constantly forking to avoid the inevitable ASICs.
x16r was a great "experiment" before we had any exchange listings... that ship has sailed though... not sure about all these x22rs lmnop changes
KAwARLast Friday at 5:00 PM
I believe that it is easier to change the direction of a bicycle than an oil tanker. We feel more like a train. We should lay out new tracks and test on them and find benefits that are acceptable to everyone except train robbers. Then open the new train station with no contentious feelings except a silently disgruntled minority group. ???
Hans_SchmidtLast Friday at 5:01 PM
The most productive action the community can do now re ASICs is to voice support for the devs to make a non-BIP9 change at a chosen block height if/when the need is clear. That removes the pressure to act rashly to avoid voting problems.
LSJI07 - MBITLast Friday at 5:01 PM
Thats why im proposing to fork at least once to a more asic resistant algo (but FPGA "friendly/possible"), with the proviso ideally that no more PoW algo forks are require to provide future ASICs some opportunity to innovate with silicon and efficiency.
TJayLast Friday at 5:01 PM
folks should take into account, that high end FPGAs like BCU1525 on x16r can't beat even previous gen GPUs (Pascal) in terms of hash cost. so they aren't a threat to miners community
PlayHardLast Friday at 5:02 PM
A proper change
Requires proper research
eyz (Silence)Last Friday at 5:02 PM
Just so I'm clear here, we are trying to boot ASICS, don't want CPUs because of Botnets, and are GPU and FPGA friendly right?
PlayHardLast Friday at 5:02 PM
It is not a quick one day process
eyz (Silence)Last Friday at 5:02 PM
If there is a bip9 vote there needs to be a clear explanation as I feel most in the community don't understand exactly what we are trying to fix
TronLast Friday at 5:03 PM
@Hans_Schmidt I like that route. It has some game theoretics. It gives time for miners to adapt. It is only used if needed. It reduces the likelihood of ASICs dominating the network, or even being built.
[Dev-Happy] BlondfrogsLast Friday at 5:03 PM
Hey guys. great convo. We are of course looking to do the best thing for the community and miner. We are going to be signing off here though.
justinjjaLast Friday at 5:03 PM
TJay that comes down to power cost.
If your paying 4c/kw gpus all the way.
But if your a home miner in europe an fpga is your only chance
LSJI07 - MBITLast Friday at 5:03 PM
@Hans_Schmidt How do we decide the block limit and when sufficient evidence is available? I would say we have had much compelling information to date...
[Dev-Happy] BlondfrogsLast Friday at 5:03 PM
Thanks for participating. and keep up the good work :smiley:
Have a good weekend.
CAWWWW
TronLast Friday at 5:03 PM
I haven't seen any compelling evidence of ASICs - yet.
Pho3nix Monk3yLast Friday at 5:03 PM
:v:
JerozLast Friday at 5:04 PM
I suggest to continue discussion in #development and #thenest :smiley:
thanks all!
TronLast Friday at 5:04 PM
Cheers everyone!
KAwARLast Friday at 5:04 PM
Agree with Hans.
DirkDiggler (Citadel Architect)Last Friday at 5:04 PM
thanks Tron
Pho3nix Monk3yLast Friday at 5:04 PM
Ending here. continue in Nest if wanted
DirkDiggler (Citadel Architect)Last Friday at 5:04 PM
I am waiting for compelling evidence myself.
submitted by mrderrik to Ravencoin [link] [comments]

Attention, benevolent BCH miners: A BCH segwit-recovery service is sorely needed!

These BCH are now recoverable; please read the update at the end of the post!

 
 

Background

In the short while since segwit activated on the BTC network and segwit addresses even-more-recently became the default for receiving BTC in the Trezor wallet - and perhaps other wallets too (soon?) - people have started accidentally sending their BCH to BTC-segwit addresses.
 
Due to the fact(s) that...
a) the BCH network supports P2SH (i.e. addresses starting with 3), but not segwit
... and ...
b) the sending wallets thus have no way of knowing that P2SH-wrapped segwit addresses really are "hiding" a segwit redeemscript
... people are losing access to their BCH, there's currently no way to prevent this, and it will continue happening.
 

Examples

(These are just the ones that I've noticed, but I'm sure there are many more that go straight to the various wallet service providers' support teams instead of via Reddit.)
 
To add insult to injury, the unlucky BCH owners are routinely told that there's no way to recover the coins (including by myself at the start) due to BCH not supporting segwit. And while that's currently true, it is ultimately only a half-truth.
After all, segwit opponents have often said that the satoshis in segwit addresses would be "anyone-can-spend" if the miners didn't enforce the segwit rules (i.e. ensuring that there's a proper witness/signature in the "segregated" part of the txs).
And on the BCH network the segwit rules aren't being enforced!
 

A Partial Solution

So I did some digging (e.g. in the segwit documentation and P2SH specification, BIP16) and came to the conclusion, which I'm sure that many have before me, that in order to spend money sent to a P2SH-wrapped segwit address, you only need to know the public key of the address (or more precisely: the RIPEMD160 hash of the SHA256 hash of a the public key).
Yes, a hash derived from the public key, not the private key.
Luckily, the 3-addresses don't by themselves reveal this public key hash, or anyone could've made "signed" txs from these "BCH-segwit" addresses - and someone probably already would have.
 

More Problems

So, given that it's relatively easy (for a technically inclined person, anyway) to get the public key corresponding to an address from their BIP39 mnemonic (aka wallet recovery seed), why aren't people re-claiming their BCH from these addresses?
Well, the "signature" that's needed isn't really a digital signature in the normal sense. Regular cryptocurrency transactions include a digital signature that doesn't reveal the private key that was used to make the signature in question. What's needed to "sign" for BCH-segwit addresses, however, is just literally including the public key hash that was mentioned above instead of a proper digital signature.
This means that anyone who sees such a transaction can just extract the public key hash from it - and then go on to create a conflicting transaction, using the same public key hash, that sends the same money elsewhere (to themselves, I would presume).
Technically, the second transaction would be a double-spend of the original and, as with all double-spends, it's the miners that would be the final arbiters of which transaction gets recorded in the block chain.
Additionally, a malicious miner could just create their own version of the transaction, either overtly redirecting the money to themselves, or covertly by changing the transaction to have no monetary outputs (i.e. all the money would go to the miner as "fee").
But the problems don't stop there. These segwit-spending transactions would be non-standard and as such wouldn't be relayed to the miners in the first place, nor would it be mined by miners even if it reached them (provided that the nodes and miners run with the default policy of ignoring non-standard txs, that is).
 

Suggested Solution

What we need is one or more trustworthy (yes, trust would unfortunately be required) miners to step up and make a BCH Segwit-Recovery Service for this particular purpose, in a somewhat similar way that they provided acceleration services for the BTC network (example1 and example2).
 
So... Does anyone know if a) miners are already working on this or b) know how to get in touch with them about this?
Or are there any benevolent miners here, that would like to:
 
/btc users, feel free to notify any miner contacts you may have - let's make this happen!
 
 

Update 1 (2017-09-11)

I made a proof-of-concept frontend to "show" what I'm envisioning such a service would look like for the end users (obviously it's ugly and needs to include javascript for key/hash/address validation, etc., but it should get the intention across), here:
https://btctroubadour.github.io/bch-recovery.html

Update 2 (2017-11-21)

It looks like some greyhat/vigilante, working with an unknown miner, was able to unilaterally claim some of the BCH that were "stuck" in BTC-segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses), as explained in this post and comments: https://np.reddit.com/Bitcoin/comments/7eixcu/recovering_bch_sent_to_segwit_addresses/
For those that are affected by this, it means you no longer control your BCH (they were "stolen" by the greyhat), but he seems to be offering to give them back if you agree to letting him keep 30 % for his service (or "service", however you look at it). Either way, and given the alternative (100 % loss), you should certainly check if you're affected and decide how you want to proceed. As if that wasn't enough to deal with, there seems to be a ~2 week deadline, until "December 5th, 2017 at 23:59:59 UTC", after which it seems he's decided he's entitled to keep your money. :(

Update 3 (2017-11-28)

It looks like the greyhat has turned white! He's now offering to give back, for free, any and all BCH that were transferred to him (yes, 100 %!). Read his new update post and check if you were affected by this transfer.

Update 4 (2017-12-05)

Benevolent BCH miner finally found! The good people at btc.com have announced an automated BCH-segwit-recovery service, just as I outlined in my original post. Thanks a lot to Stellaluna19 for bringing it to my attention.
Here are links to btc.com's Twitter announcement as well as the recovery service itself:
https://twitter.com/btccom_official/status/933682190424199169
https://bch.btc.com/docs/help/bch_segwit_recovery
(Note that SatoshiLabs/Trezor developer, and well-known whitehat, -johoe have suggested some improvements to secure the process outlined by btc.com. You can read his suggestions in the last paragraph of this post - or in this one.)
submitted by btctroubadour to btc [link] [comments]

1st Round AMA Answers!

Based on the volume of questions from the East and West, we have compiled them all here. We also want to make sure the community has a chance to see all of the answers in a neat and orderly presentation.
 
Reddit 1st AMA Answers
What do you mean by “side chains”? Will the Hcash main chain run parallel with other chains, or are other chains plugged in based on certain block numbers? My question is based around the vertical and parallel scalability I see with EOS. What is the interaction with the side chains? Is this faster than vertical scaling?
Side chains will run parallel and be interoperable with the main chain. Side chains allow for new, more efficient, consensus mechanisms as well as smart contract functionality. Eventually other major blockchains will be interoperable with Hcash, through side chains and relays, DAG EVM for ETH, and other “Layer 2” solutions (Lightning Network for BTC and BTC forked code). Side chains allow for different scalability methods, flexibility and accessibility.
Is quantum resistance to protect against hacking, or against “fast mining” (preventing inequality between PoW miners)? How is it possible to guarantee quantum resistance? Isn’t our understanding of quantum computing just based on theories since quantum computers are not fully functional yet?
Quantum resistance is the protection against attacks made by quantum computers, which is currently contrasted by what we know about classical computers. Quantum computers weaken the security assumptions of certain types of cryptography, including ECDSA. If ECDSA were broken, attackers could steal balances in addresses that have made previous spends because the ECDSA public key for the address is revealed to the blockchain. Addresses with unexposed ECDSA keys will be resistant to this type of attack, as they are secured by RIPEMD160 and their ECDSA keys have not been revealed. Quantum resistance does not mean quantum proof. Quantum resistance means that quantum-based attacks do not have a significant advantage over the computers we have today. Based on what we currently know, our signature scheme is quantum resistant. No one knows what the future holds which is why it is important to always continue research and development into quantum resistant cryptography.
What do you mean by “exchange of value and valuable information”? Is this the exchange of coins and smart contracts?
The “value” you are referring is not derived from our current understanding of value (fiat). The “true value” that blockchain systems hold is stored in the hashes themselves. Data and information is king.
Imagine that in 2 years, a kid walks up to you and asks, “What do you do and how does it help society?”
We are one of many projects that helped build a more secure web of connected devices, and revolutionized peoples’ opinion on value and what really matters.
An uninformed businessman who has no understanding of blockchain, but has heard Bitcoin approaches you. How do you explain your product and the benefits to him so that he remembers to give you a call the next day?
Tell him to do his research on blockchain first before selling him on some grand idea. Smart investors grow a stable smart economy, not dumb money.
After reviewing the Hcash source code on GitHub https://github.com/HcashOrg/hcashd, I've found that almost all the Hcash main chain code has been written by SJTU (Shanghai Jiao Tong University), for example https://github.com/sammy00 https://github.com/yczhangsjtu. What have other contributors, such as the Nucleus Team, done for Hcash?
Shanghai Jiao Tong University’s Lab of Cryptography and Computer Security is the primary contributor to the main chain code. It is no small feat to have the 4th best university in China working on this project. The Nucleus Team is working with them to finish main chain testing. After the main chain launch, the Nucleus team will focus on the future development for Hcash including our side DAG EVM and main chain Lightning interoperability.
The main chain public repo hasn’t been updated very frequently.
Please refer to our new GitHub. The frequency of updates will increase as we approach/ pass the main chain launch.
When will the swap from Hshares to Hcash take place?
The swap to the main chain will take place after the main chain launch mid-February. Announcements will be made as to how and where you can swap your Hshares for Hcash.
What is the exact date of main chain launch?
The main chain launch will take place mid-February. We are aiming for release on February 15th.
Will you provide interoperability for all the existing blockchains?
We hope to provide interoperability for all blockchains in the future. That is a lot of work though. We will start with the larger chains that have healthy development and community sizes first. To make this easier, we plan to provide a back-end solution for new blockchains to make this process easier.
Will the interoperability between the blockchains support both transfer of data and transfer of value?
Yes
What is a block-less blockchain? Is this a traditional distributed system?
A block-less blockchain accomplishes the same goals as a traditional blockchain by using consensus to determine the order of transactions. A block-less blockchain, such as a DAG, allows for faster consensus without traditional block size requirements. Faster consensus means higher throughput.
How will Hcash bridge block-less and traditional blockchains?
Through relays between our main chain and side DAG. A more technical analysis will be available in our upcoming yellow paper.
What signature scheme will you use to achieve quantum resistance? Why?
Hcash is using the BLISS signature scheme. Hcash’s version of BLISS has been hardened to mitigate side channel attacks. BLISS was chosen for its efficient key and signature size.
Provide an overview as to how inoperability will be achieved.
We will be using relays to Hashed Timelock Contracts for Lightning Network interop on our main chain, relays and colored coins that operate with our DAG EVM, bridges to side chains for more uncommon chains, and back-end protocols for newer blockchains.
Specifically, what is the theory behind Hcash’s interoperability?
This answer would be longer than the entire AMA. Unfortunately, the specifics will have to wait until the yellow paper release. In the meantime, I would read the Lightning Network whitepaper because it is an excellent source of information. You could also research BTC relays and EVMs.
What is the timeline for interoperability? Will this be the main focus of Hcash? When can be expect an Alpha version?
We will be updating the roadmap in Q2. Interop timeframes will be easier to gauge after the main chain release. There are quite a few ideas around what we would like to tackle next, whether it would be assisting other projects on Lightning Network development, the DAG EVM implementation, or possibly both at the same time.
How will swap values be calculated when switching between blockchains? Is it based on the current market value?
Yes, it would be based on the current, real time market value.
Will you update the whitepaper to include a comprehensive overview of interoperability, its theory and its exchange functions?
In the coming months we plan to do an update on the white paper. The technical analysis will be provided in our yellow paper. These will be detailed in the updated roadmap to be released after the main chain launch.
Can you explain who will use the Hcash? I am trying to figure out where the supply and demand will come from.
Our target audience is everyone, from people playing mobile games to supporting business and government logic. The supply and demand will come with the need to transfer more and more data across multiple platforms. As for the economic model, this has not been outlined yet. We will be exploring all methods that fall in line with creating smart economies, including 2 token models.
Will you be hiring an advertising team?
We are already expanding Western marketing, primarily in the US. More focus on this will come soon after the main chain.
What are ring signatures in cryptography? How do they work?
At this time, we are exploring more efficient transaction schemes, such as bulletproofs. Bulletproofs can reduce the computational power needed for privatized/ anonymous transactions.
Most of us understand the interoperability of the network. What is a specific use case for Hcash? What role will Hcash have in the network? What makes it a requirement for interoperability? If someone has Bitcoin and wants to convert it to Ethereum using Hcash’s network wallet, is Hcash used as a fee for that conversion?
Here is an analogy. You walk into an arcade with 20 different machines. Each of these machines takes a different token, but you only have coins that operate with one of these machines. This would be the type of solution we hope to provide. Fees can be paid with Hcash. In the future we can explore taking fees in other denominations as well. More of this would be explained in detail with our yellow paper and economic model.
 
Baidu 1st AMA Answers
What specific date will the main chain go online?
Main chain release is mid-February, but we are aiming for launch on February 15th.
Are you willing to divulge how many apps you have in development for the Hcash main chain?
The primary focus right now is to improve the stability of the Hcash main chain. This will ensure successful launches in the future for developers on our side DAG EVM.
What is the Martian’s current relationship to Hcash? Is he still part of its team?
The Hcash team is currently located on Earth. The last I heard the Martian was returning to Mars.
Will the main chain go up according to schedule? Are there any problems with Hcash? The specialist sales team was made up of shareholders/ investors, right?
Provided no unforeseen circumstances, we are on schedule for the main chain release. There are roadblocks and disconnects with every project. This is a new world of technology we are exploring. I think the team you may be referring to is the Hcash Foundation themselves. A lot of the Western marketing and development is being handled by the Nucleus Team.
Is the code on GitHub all original? Are all developments executed on GitHub? Why is there so little original code? There are so few modifications. I also noticed there are remarkably few references to the code. Most of them are from documents that have been updated.
Many engineers have worked to contribute to the blockchain community over the years. We are taking advantage of the hard work and research that has been done while also making our own meaningful contributions for others to use in their code. It is important to acknowledge the contributions of others. The work completed by Decred in particular has allowed us to grow. Now we will have our chance to contribute back to them and others with our post quantum signature scheme and NG implementation. There are advantages of having similar projects that people don’t realize. For example, after our main chain launch we can explore assisting with development on the Lightning Network. As for GitHub, you will see activity increase when the main chain launches.
What is scope of the Hcash R&D team?
To assess, research and develop cutting edge decentralized consensus mechanisms and applications.
Hcash is currently collaborating with three universities. Shanghai Jiao Tong University has been working on the main chain quantum resistance. What are the main responsibilities of the other two universities?
Building blockchain technology is a group effort. The other teams have also been researching other options for main chains, smart contracts etc. For example, Dr. Joseph Liu from Monash University is working on ring signature schemes to continue our research and development into privatized transactions. We are looking forward to taking the best efforts of all teams and bringing them to the blockchain communities at large, starting with the post quantum implementation from LoCCS at Shanghai Jiao Tong University.
The Westerners working on Hcash don't seem very enthusiastic. They aren't following a lot of people on Twitter. Does the team have any clearer plans for increasing publicity?
The Westerners are primarily focused on the technology, development, and creating more content. The community management will be increasing transparency and activity in time. More Western marketing can be done after the launch of the main chain.
Are there plans to get onto more exchanges such as Bittrex?
When moon? We are constantly considering all options to allow users to access Hcash. Currently we are listed amongst some of the top exchanges like Binance and growing exchanges like KuCoin.
When will quantum resistant technology be implemented into Hcash? Where can we follow the developments being made and is there anywhere we can go to participate in the project?
Quantum resistant technology is available now on GitHub at https://github.com/HcashOrg/hcashd and will be available for use outside of the testing environment when the main chain launches in the middle of February.
Where do you download the wallet? How do you mine?
The wallet for the new main chain can be found on GitHub at https://github.com/HcashOrg/hcashwallet. You can mine on the new main chain by joining a pool or using the hcashd node to solo-mine.
When will Hshares swap Hcash? Can you announce a general time?
Hshares can be redeemed for Hcash after the main chain launches in the middle of February. Announcements will be made regarding how and where to swap your Hshares for Hcash.
Will there be an address mapping when Hshares swaps to Hcash like there was with EOS? What other kind of mechanism will be used for the coin swap?
A snapshot of Hshares will be included in the Genesis (first) block of Hcash’s launch to allow users to convert their Hshares into Hcash. An announcement will be made as to how, when and where conversions will take place.
When will the main chain that can support smart contracts go online? When will tokenization for Hcash take place?
Smart contract functionality will be available when our side DAG launches. Users, businesses and developers will be able to build dApps, launch tokens and more. We are making sure the main chain is a stable foundation before adding our DAG to the Hcash ecosystem.
There aren't many updates on GitHub and there aren’t many contributors. What kind of coordination is going on with the development team?
Both the Nucleus Team and members of Shanghai Jiao Tong University LoCCS are working together to finalize testing. Updates are being made to our GitHub at https://github.com/HcashOrg/hcashd.
Based on what I've been reading, Shanghai Jiao Tong University is mainly responsible for the main chain portion of the project. How is their team doing? How many research students in their labs are helping them?
Shanghai Jiao Tong is responsible for building and launching the new main chain. Their team there has been doing a great job with research and development and we look forward to seeing more of their work. The Nucleus Team is currently working with them to finish testing. After testing, the Nucleus team will focus on the future development of the project including our side DAG. I do not know the size of their team as we have not visited their lab.
Can you confirm that the main chain will finally go up in mid-February? Is it just a hypothetical date and then a further delay?
The primary responsibility is to make sure the main chain is stable and secure so that it can be used as the foundation to add other important features to the Hcash ecosystem, like smart contracts and hidden transactions. Everyone is working very hard to hit the target release date of mid-February. We are planning on mid-February for the launch unless anything unexpected comes up.
What is the status of these interoperability features? When is the main chain going online?
Main chain will be released mid-February. The interoperability features depend on the stability of the network. Our side DAG EVM will be the quickest addition to the Hcash ecosystem that will allow for ETH interoperability. Lightning Network on the main chain will require further research and development.
Won’t zero knowledge proofs conflict with the system’s throughput?
We are currently working on more uncommon implementations of zero proof knowledge, such as bulletproofs that allow for efficient transaction speeds. We can also achieve higher throughput with our side DAG.
 
Thank you to everyone who participated! Round 2 of our AMA session leading up to the launch of the main chain will be announced shortly 😊
submitted by Mr_Handsome_Nucleus to hcash [link] [comments]

Atomic Swap with USDT: Swap Online solution in two hundred lines of code

Atomic Swap with USDT: Swap Online solution in two hundred lines of code
https://preview.redd.it/3mx7amtio9g11.png?width=696&format=png&auto=webp&s=f2bd956843196fa2f51048a86f9608b6e714f62e
On the eve of the release on the mainnet, the team of the cross-chain wallet Swap Online is publishing a research study and the code of the atomic swapusing USDT.

USD Tether — the equivalent of the dollar on Omni Layer

The solution described above with the protocol “over” the Bitcoin network gave life to one of the most controversial cryptocurrency projects of the last two years — Tether. Tether (symbol Tether — ₮, ticker — USDT) is a hybrid cryptocurrency with a rate binding to one US dollar. Moreover, according to the assurances of Tether Limited, the issuer of the given tokens, the “binding” is to be understood literally, as each purchased token of USDT corresponds to one US dollar available at the disposal of the company.
If we take the three largest exchanges based on their daily turnover of transactions at the time of writing (Binance, OKEx and HuObi), and then track the five most popular trading pairs for each, we will encounter USDT in 13 out of 15 cases.

USDT — the token with the largest capitalization in the world.

All this generates great community interest in faster, safer and cheaper solutions for exchanging Tether into other currencies. Obviously, such a solution could be atomic swaps, which are instant, decentralized cross-chain exchanges. The Komodo laboratory, the main headliners of this technology, who presented it in the autumn of 2017, reported on the successful exchange of KMD to USDT carried out on the BarterDEX platform, Komodo’s own exchanger.
https://preview.redd.it/z7tx3cv0p9g11.png?width=597&format=png&auto=webp&s=f0944434f691d69ae45c5b80e00fed2736423f7a
At the same time, according to our data, the developers of Komodo made a swap on the ERC20-a version of Tether, which is only available in 3% of cases. Approximately 60 million USDT from global turnover can thus be exchanged using this method, which, obviously, cannot be considered as a solution to the problem. Striking examples of imperfections of existing solutions can be found even on Etherscan.
https://preview.redd.it/39nc2ji6p9g11.png?width=800&format=png&auto=webp&s=992a4adc022175d90d111f030047ba8adeda14f8
This fall, the team of Swap Online is ready to present an atomic swap with Tether. And here’s how we did it.

How Omni conducts transactions

To carry out the Omni transaction, a user needs to create a regular Bitcoin transaction-transfer of 546 satoshi (minimum) with an additional output storing payload using the OP_RETURN op-code. An example of such a transaction. The payload is a mandatory part of any Omni transaction, as it is a sequence of bytes containing all the necessary information about the transaction.

Let us consider what information is stored in the payload itself

transaction marker — 4 bytes, the mandatory part of any Omni payload is always equal to 0x6f6d6e69 — ASCII code omni. If the first 4 bytes of the sequence are not equal to 0x6f6d6e69, then this sequence is not a payload of Omni.
version — 2 bytes, an analog version of the transaction in Bitcoin. For the described algorithm to work, version 0 is used, or that is the same as 0x0000.
transaction type — 2 bytes, transaction type, for an atomic swap it is sufficient to use only “Simple send” transactions, as simple send is the usual sending of omni currency from its address to the address of the recipient. Simple send corresponds to the transaction type code 0, that is, the next 2 bytes 0x0000. Other possible types of transactions exist in Omni.
token identifier — 4 bytes, identifier of the currency used. For example TetherUS has the identifier 31 or 0x0000001f. All tokens created by the Omni protocol at this time can be seen via the following link.
amount — 8 bytes, for a transaction of type Simple send, this is the amount of the sent currency.
As you can see, payload does not store the addresses of senders and recipients of the transactions, these addresses are determined by the Bitcoin transaction in which the payload output was detected. By scanning inputs, the Omni protocol determines who makes the transfer by finding the output of the corresponding address from among the inputs of the transaction p2pkh.
Thus, for a transfer from Alice to Bob of, for example, 50,000,000 TetherUS, we need to create a Bitcoin transaction where one of the inputs will refer to the p2pkh output corresponding to the Alice address. It is also important that this entry be the first in this transaction (the index of this entry in the received transaction would be is minimal or none at all). One of the outputs of this transaction should be the output of p2pkh to Bob’s address, and another output must have been one of the outputs with the following payload:
https://preview.redd.it/0kmuzds8p9g11.png?width=575&format=png&auto=webp&s=af2f496596684af18091fb044f4e20b7e546c32f
Example 1
Example 2

Atomic Swap on Omni Layer

Suppose that Alice and Bob are willing to make an inter-blockchain exchange of cryptocurrencies. Alice wants to exchange the units of any Omni currency, for example TetherUS (the given currency has the currency identifier # 31 in the Mainnet, then in the text we will only talk about this currency of the Omni protocol, since it is the most popular at the moment, but the algorithm below will work for any currency of the Omni protocol as well) for b units of a cryptocurrency working on another blockchain. (Omni works on top of the Bitcoin blockchain, of course, according to the algorithm below it is possible to exchange TetherUS for Bitcoins, but due to their work on one and the same blockchain, this exchange can be done in a different, more efficient way).

Glossary

A — blockchain of Bitcoin.
B — the blockchain of the cryptocurrency for which TetherUS is being exchanged.
a — the sum of TetherUS, which Alice wants to exchange.
b — the sum of the cryptocurrency of the adjoining blockchain B, to which Alice wants to exchange her a TetherUS.

Creating a Transaction

1) Bob generates a random value secret.
2) Bob calculates the secretHash by performing the following operation: secretHash = RIPEMD160 (secret)
3) Bob creates and sends an htlc transaction sealed by secretHash
4) Bob sends Alice a secretHash value, and a hash of the hrlc transaction he created in the previous paragraph in order for Alice to make sure that the correct htlc transaction is actually present in the B blockchain.
5) Alice received from Bob the secretHash and hash of the htlc-transaction Bob created, and is convinced that such a transaction is really present in the B blockchain, and that this is indeed a htlc-transaction sealed by the secretHash value.
6) using the received secretHash, Alice creates the following transaction and translates it into the Bitcoin blockchain:
https://preview.redd.it/oxri5a7gp9g11.png?width=735&format=png&auto=webp&s=14e88db4fc4d1743406939343d42e33352b05782
Let us call such a transaction financing_tx. In fact, it is almost an ordinary Bitcoin htlc transaction that is used in atomic swap with the only difference that in the amount field, 546 satoshi is the minimum number of Bitcoins that can be at the output of the transaction, below this value, Bitcoin counts the transaction as dust and does not conduct it.
7) Alice creates a transaction according to the following scheme:
https://preview.redd.it/awz9uzuhp9g11.png?width=1000&format=png&auto=webp&s=9ca79e77ca6aff631a39ae95dfaa70aa06d695ec
Let us call this transaction redeem_tx. Alice creates such a transaction with two inputs: the first is the input referencing the output of funding_tx, which contains the htlc script. Alice does not sign this script, that is, the SigScript field remains completely empty. The second input is the input referring to any unspent exits of Alice, the main condition is that at this output stage there are enough Bitcoins to pay the transaction fee, and this entry is signed by Alice with her private key with the signature type SIGHASH_ALL (that is, she signs the entire transaction except for SigScript fields on the inputs transaction, which makes this transaction immutable. The outputs of the same transaction are the elementary Simple Send and a TetherUS from Alice to Bob (details of what Simple Send, payload is and how it works can be found in another section).
8) Alice sends Bob the redeem_tx created in the previous paragraph and the one she signed herself.
9) Bob got the redeem_tx sent by Alice, checks it, just looks through the inputs and outputs, making sure that this is really a transaction that Alice should have created using the real algorithm. After that, Bob signs the transaction with his private key and provides the secret value in the SigScript of the corresponding redeem_tx entry.
10) Bob sends the signed redeem_tx transaction to the blockchain, thereby transferring the TetherUS currency from Alice to himself. Note — before carrying out this step, we still need to check that Alice’s address has the necessary amount of TetherUS.
11) Alice looks through blockchain A and gets the value secret and uses it in the B blockchain to transfer the funds using the htlc transaction Bob created in point 3. The exchange ends here.
Stating the obvious: naturally the timelock value used by Bob when creating the htlc-transaction must be significantly longer than the timelock that Alice uses, since her htlc transaction should be spent earlier than the htlc created by Bob. This is necessary so that Bob cannot manage to spend both htlc.

Conclusion

Thus, connecting Omni Layer to Swap Online allows users to cover transactions.

Full research you may find in our Github

C++ source code for creating TX
C++ source code for redeem TX

Swap.Online Essential Links

Website: https://testnet.swap.online GitHub: https://github.com/swaponline Email: [email protected] Telegram: https://t.me/swaponline Facebook: https://www.facebook.com/Swaponline Twitter: https://twitter.com/SwapOnlineTeam Wiki: https://wiki.swap.online/ Bitcointalk: https://bitcointalk.org/index.php?topic=4636633
submitted by noxonsu to SwapOnline [link] [comments]

Where is my bitcoin ?! What are bitcoin and cryptocurrency wallets ?

Wallets, Digital Keys and Addresses
Digital keys are used to establish ownership of bitcoin and other cryptocurrencies. Typically, keys are stored in a wallet and the keys are rarely seen by the wallet owner. Every bitcoin transaction requires a valid signature, which can only be generated with the valid private key.
There are two elements of digital keys: a private key and a public key. In a simplistic view, the public key can be considered the equivalent of an email address and the private key as the password. In the previous example of Alice sending bitcoin to Bob, Bob’s public key is represented by a bitcoin address which Alice remits the bitcoins to. Bob’s bitcoin address is derived from his public key. The private and public keys are mathematically linked so addresses generated from the keys can be unlocked through Bob’s private key.
Every bitcoin transaction has a signature to prove that the transaction is valid as it can only be generated from the private key. The signature can be validated against the public key without revealing any information about the private key.

What is a private key and public key?
A private key can be presented in a number of different formats. In a binary format, it is a series of 0s and 1s. However, it is common to represent private keys in a Wallet Import Format (WIF) as it is more readable and practical. Ownership of the private key is the ultimate control of the bitcoins. Revealing the private key to any person or institution will enable them to access the respective bitcoin and conduct transactions.
Below is an example of a private key in a WIF and the associated public key:
Example of a private key: L4mWALaGRp5PJEADLm8TbDPT6KwipPCmaHYmviSq5tLPSXkq3CRm
Example of the corresponding public key:
03492957C680E6F5AA9189056CFAE66D5CA25B3F51C6A81D596908E142D81C0756
Don't try and steal my bitcoins!

The bitcoin address is derived using two one-way hashing algorithms. The algorithms that are used to create a bitcoin address from a public key are Secure Hash Algorithm (SHA) and RACE Integrity Primitives Evaluation Message Digest (RIPEMD). Specifically, they are SHA256 and RIPEMD160.
Starting with the public key, it is put through the SHA256 function followed by the RIPEMD160 algorithm, which produces the bitcoin address. The following bitcoin address corresponds to the above key pairs.
Bitcoin address 1PCW2Cg4butxaaSkEGKw31zc5ZbABjGYHH
The transaction history, all debits and credits that are associated with the above address, can be viewed on a blockchain explorer such as www.blockchain.info by simply pasting this address into the search function.

Wait... I thought BTC was used by hackers as nobody can trace the funds ?! you are telling me that I can view someones transaction history ?? My money is in a glass safe?! What the fuck
submitted by Cryptocobbler to DigitalAssetResearch [link] [comments]

Time to worry about 80-bit collision attacks or not? | Gavin Andresen | Jan 07 2016

Gavin Andresen on Jan 07 2016:
I'm hoisting this from some private feedback I sent on the segregated
witness BIP:
I said:
"I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
bytes-- a successful preimage attack against that ain't gonna happen before
we're all dead. I'm probably being dense, but I just don't see how a
collision attack is relevant here."
Pieter responded:
"The problem case is where someone in a contract setup shows you a script,
which you accept as being a payment to yourself. An attacker could use a
collision attack to construct scripts with identical hashes, only one of
which does have the property you want, and steal coins.
So you really want collision security, and I don't think 80 bits is
something we should encourage for that. Normal pubkey hashes don't have
that problem, as they can't be constructed to pay to you."
... but I'm unconvinced:
"But it is trivial for contract wallets to protect against collision
attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off, just
ignore that arbitrary data" a wallet can just refuse. Even more likely, a
contract wallet won't even recognize that as a pay-to-gavin transaction.
I suppose it could be looking for some form of "gavin_pubkey
somebody_else_pubkey CHECKMULTISIG ... with the attacker using
somebody_else_pubkey to force the collision, but, again, trivial contract
protocol tweaks ("send along a proof you have the private key corresponding
to the public key" or "everybody pre-commits pubkeys they'll use at
protocol start") would protect against that.
Adding an extra 12 bytes to every segwit to prevent an attack that takes
280 computation and 280 storage, is unlikely to be a problem in practice,
and is trivial to protect against is the wrong tradeoff to make."
20 bytes instead of 32 bytes is a savings of almost 40%, which is
significant.
The general question I'd like to raise on this list is:
Should we be worried, today, about collision attacks against RIPEMD160 (our
160-bit hash)?
Mounting a successful brute-force collision attack would require at least
O(280) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin
POW has computed more SHA256 hashes than that). But it also requires
O(280) storage, which is utterly infeasible (there is something on the
order of 235 bytes of storage in the entire world). Even assuming
doubling every single year (faster than Moore's Law), we're four decades
away from an attacker with THE ENTIRE WORLD's storage capacity being able
to mount a collision attack.
References:
https://en.wikipedia.org/wiki/Collision_attack
https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/

Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/09860830/attachment.html
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Public Key Derivation

Hi Guys,
I have decoded the way the EOS key pair works. Instead of using the generated key pair, you may use (AT YOUR OWN RISK) your own private key and then generate the EOS public key as follows:
DISCLAIMER AND WARNING! THE CONTENTS ARE, ALTHOUGH VERIFIED BY ME, I SHALL NOT BE LIABLE FOR ANY FUND LOSS DUE TO USE OF MY METHOD AND THIS IS FOR EDUCATION PURPOSE ONLY.
  1. Go to https://www.bitaddress.org > wallet details (Bitcoin) and paste your private key. The UNCOMPRESSED private WIF key will be your EOS private key.
  2. Copy the generated Compressed Public Key (66 hex characters) and paste in a text file (say, temp.txt).
  3. Using EDXOR or some good Hex convertor, convert temp.txt file from hex to raw ANSI characters (binary format) and save the file.
  4. Find Ripemd160 of the temp.txt file.
  5. Copy first 8 hex characters of the Ripemd160 hash and concatenate to the Compressed public key obtained in step2.
  6. Using brainwallet.org (now removed, google it to find old archives) convert the hex string obtained in step 5 to Base58 format.
  7. Prefix EOS to the code obtained in step 6.
Voila, you obtained the corresponding EOS Public key.
Vote up if you liked.
Please also visit my website www.SunnySaini.com > Suncryt v1 and post comments there.
Thanks in advance.
Sunny Saini
submitted by www_SunnySaini_com to eos [link] [comments]

Trying to build BU from source for Raspberry Pi 2

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

BIP Number Request: Open Asset | Nicolas Dorier | May 26 2016

Nicolas Dorier on May 26 2016:
Open Asset is a simple and well known colored coin protocol made by Flavien
Charlon, which has been around for more than two years ago.
Open Asset is OP_RETURN to store coin's color. Since then, the only
modification to the protocol has been for allowing OA data to be into any
push into an OP_RETURN.
The protocol is here:
https://github.com/OpenAssets/open-assets-protocol/blob/mastespecification.mediawiki
I asked to Flavien Charlon if he was OK if I submit the protocol to the
mailing list before posting.
Additional BIP number might be required to cover for example the "colored
address" format:
https://github.com/OpenAssets/open-assets-protocol/blob/masteaddress-format.mediawiki
But I will do it in a separate request.
Here is the core of the Open Asset specification:
Title: Open Assets Protocol (OAP/1.0)
Author: Flavien Charlon
Created: 2013-12-12
==Abstract==
This document describes a protocol used for storing and transferring
custom, non-native assets on the Blockchain. Assets are represented by
tokens called colored coins.
An issuer would first issue colored coins and associate them with a
formal or informal promise that he will redeem the coins according to
terms he has defined. Colored coins can then be transferred using
transactions that preserve the quantity of every asset.
==Motivation==
In the current Bitcoin implementation, outputs represent a quantity of
Bitcoin, secured by an output script. With the Open Assets Protocol,
outputs can encapsulate a quantity of a user-defined asset on top of
that Bitcoin amount.
There are many applications:
could then be traded frictionlessly through the Bitcoin
infrastructure.
could withdraw and deposit money in colored coins, and trade those, or
use them to pay for goods and services. The Blockchain becomes a
system allowing to transact not only in Bitcoin, but in any currency.
of colored coins. The door would only open when presented with a
wallet containing that specific coin.
==Protocol Overview==
Outputs using the Open Assets Protocol to store an asset have two new
characteristics:
asset stored on the output.
many units of that asset are stored on the output.
This document describes how the asset ID and asset quantity of an
output are calculated.
Each output in the Blockchain can be either colored or uncolored:
both undefined).
non-null asset ID.
The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the
output script referenced by the first input of the transaction that
initially issued that asset (script_hash =
RIPEMD160(SHA256(script))). An issuer can reissue more of an
already existing asset as long as they retain the private key for that
asset ID. Assets on two different outputs can only be mixed together
if they have the same asset ID.
Like addresses, asset IDs can be represented in base 58. They must use
version byte 23 (115 in TestNet3) when represented in base 58. The
base 58 representation of an asset ID therefore starts with the
character 'A' in MainNet.
The process to generate an asset ID and the matching private key is
described in the following example:

The issuer first generates a private key:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725.

He calculates the corresponding address:

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM.

Next, he builds the Pay-to-PubKey-Hash script associated to that

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY
OP_CHECKSIG.

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

Finally, the hash is converted to a base 58 string with checksum

using version byte 23:
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC.
The private key from the first step is required to issue assets
identified by the asset ID
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. This acts as a
digital signature, and gives the guarantee that nobody else but the
original issuer is able to issue assets identified by this specific
asset ID.
==Open Assets Transactions==
Transactions relevant to the Open Assets Protocol must have a special
output called the marker output. This allows clients to recognize such
transactions. Open Assets transactions can be used to issue new
assets, or transfer ownership of assets.
Transactions that are not recognized as an Open Assets transaction are
considered as having all their outputs uncolored.
===Marker output===
The marker output can have a zero or non-zero value. The marker output
starts with the OP_RETURN opcode, and can be followed by any sequence
of opcodes, but it must contain a PUSHDATA opcode containing a
parsable Open Assets marker payload. If multiple parsable PUSHDATA
opcodes exist in the same output, the first one is used, and the other
ones are ignored.
If multiple valid marker outputs exist in the same transaction, the
first one is used and the other ones are considered as regular
outputs. If no valid marker output exists in the transaction, all
outputs are considered uncolored.
The payload as defined by the Open Assets protocol has the following format:
{|
! Field !! Description !! Size
|-
! OAP Marker || A tag indicating that this transaction is an
Open Assets transaction. It is always 0x4f41. || 2 bytes
|-
! Version number || The major revision number of the Open Assets
Protocol. For this version, it is 1 (0x0100). || 2 bytes
|-
! Asset quantity count || A
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] representing the number of items in the asset
quantity list field. || 1-9 bytes
|-
! Asset quantity list || A list of zero or more
[http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
|-
! Metadata length || The
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] encoded length of the metadata field. || 1-9
bytes
|-
! Metadata || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
|}
Possible formats for the metadata field are outside of
scope of this protocol, and may be described in separate protocol
specifications building on top of this one.
The asset quantity list field is used to determine the
asset quantity of each output. Each integer is encoded using variable
length [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also
used in [https://developers.google.com/protocol-buffers/docs/encoding#varints
Google Protocol Buffers]). If the LEB128-encoded asset quantity of any
output exceeds 9 bytes, the marker output is deemed invalid. The
maximum valid asset quantity for an output is 263 - 1
units.
If the marker output is malformed, it is considered non-parsable.
Coinbase transactions and transactions with zero inputs cannot have a
valid marker output, even if it would be otherwise considered valid.
If there are less items in the asset quantity list than
the number of colorable outputs (all the outputs except the marker
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the asset quantity list than the
number of colorable outputs, the marker output is deemed invalid. The
marker output is always uncolored.
After the asset quantity list has been used to assign an
asset quantity to every output, asset IDs are assigned to outputs.
Outputs before the marker output are used for asset issuance, and
outputs after the marker output are used for asset transfer.
====Example====
This example illustrates how a marker output is decoded. Assuming the
marker output is output 1:
Data in the marker output Description ----------------------------- 
0x6a The OP_RETURN opcode. 0x10 The PUSHDATA opcode for a 16 bytes payload. 0x4f 0x41 The Open Assets Protocol tag. 0x01 0x00 Version 1 of the protocol. 0x03 There are 3 items in the asset quantity list. 0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list: - '0xac 0x02' means output 0 has an 
asset quantity of 300.
 - Output 1 is skipped and has an 
asset quantity of 0
 because it is the marker output. - '0x00' means output 2 has an 
asset quantity of 0.
 - '0xe5 0x8e 0x26' means output 3 
has an asset quantity of 624,485.
 - Outputs after output 3 (if any) 
have an asset quantity of 0.
0x04 The metadata is 4 bytes long. 0x12 0x34 0x56 0x78 Some arbitrary metadata. 
===Asset issuance outputs===
All the outputs before the marker output are used for asset issuance.
All outputs preceding the marker output and with a non-zero asset ...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012741.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Advanced Bitcoin Scripting -- Part 1: Transactions & Multisig Hack Bitcoin Wallet 2019/2020 (CryptoKeys) Cracking ... Hashcat running in Termux (part 1 - testing crack RIPEMD-160 hash)

Create your own wallet. Powered by GitBook. Bitcoin address. You know that your Bitcoin Address is what you share to the world to get paid. You probably know that your wallet software uses a private key to spend the money you received on this address. The keys are not stored on the network and they can be generated without access to the Internet. This is how you generate a private key with ... Introduction. Ownership of Bitcoin Cash is established through digital keys, Bitcoin Cash addresses, and digital signatures.The digital keys are not actually stored in the network, but are instead created and stored by users in a file, or simple database, called a wallet.The digital keys in a user’s wallet are completely independent of the Bitcoin Cash protocol and can be generated and ... Calculate the RIPEMD160 for large password lists and stores them as key-value pairs in a database (RIPEMD160 -> password). I've used leveldb for this. With a blockchain parser I parse the blockchain and extract all the RIPEMD160 hashes of each bitcoin address. Then I just make a lookup of each hash in the database, and if I find an entry, I've cracked a brainwallet. As an additional step, it ... Bei Bitcoin bedeutet dies im Wesentlichen, dass die Währung anonym ist, wenn nicht nach- gewiesen werden kann, welche (reale) Identität Überweiser und/oder Empfänger haben. Diese Eine Bitcoin-Wallet enthält eine Sammlung von Schlüsselpaaren, die jeweils aus einem privaten Schlüssel und einem öffentlichen Schlüssel bestehen. Der private Schlüssel (k) ist eine Zahl, die normalerweise zufällig ausgewählt wird. Aus dem privaten Schlüssel verwenden wir eine elliptische Kurvenmultiplikation, eine kryptographische Einwegfunktion, um einen öffentlichen Schlüssel (K ...

[index] [36177] [12498] [36938] [20987] [39334] [48692] [34610] [38113] [22140] [46876]

Advanced Bitcoin Scripting -- Part 1: Transactions & Multisig

This is the first part of a more technical talk where Andreas explores Bitcoin script, with examples from the 2nd edition of Mastering Bitcoin, focusing on t... How to Brute Force a Bitcoin Wallet with Hashcat - Duration: 16:56. Bitcoin Daytrader 18,124 views. 16:56. The Fastest Hash Decrypter - Juggernaut v1000 - Duration: 4:38. ... Hacking Bitcoin Wallets. Showing here how to crack a Bitcoin Wallet (Blockchain, Coinbase, +) Private Key. Full Demonstration Video. What does this tool make...

#