RIPEMD-160 | bitFlyer

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]

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]

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]

Namechains

Namechain Domain Example
Generate a private key from UTF-8('namechain') = 6E 61 6D 65 63 68 61 69 6E (with a bunch of leading zeros to be accurate).
Generate the pubkey: secp256k1(6E 61 6D 65 63 68 61 69 6E)
Generate an actually secure private key.
Generate a pubkey from that.
Create a 2 of 2 multisig address from those two pubkeys. I should note here that for generic TLD names, ideally we wouldn't require a second key and a multisig address, only the first keypair composed of the 'name' keys. The reason I have the second keypair in this iteration is because I'm not proficient enough with P2SH 'redeem scripts' to know how to write a script that guarantees funds flowing through an address without someone being able to sniff node traffic and try and double spend those funds as they 'flow through' (or if that script is possible but I'm fairly certain it is?). This would be pretty useful. As for now, it's just extra data (so extra costs), but it does allow for a 'name' to sign names under it similar to a CA scheme, effectively creating two chains from a name: a signed one and an unsigned one. Maybe this is desirable.
Anyways, fund that multisig address. Spend those funds to an 'ownership' address to expose the public keys (used for verifying names/values with keys). This conveniently lets us establish an ownership address though, whose address itself can be used as the corresponding key to our name that allows us to generate signatures to verify ownership (and can be used later for transferring).
So now a name and key are paired together. If someone signs a message saying they are 'namechain', we can verify this by searching through transactions, attempting to find a public key that matches that name by searching for the first 'place-in-chain' transaction with a signature whose public key matches secp256k1(UTF-8('namechain')) and verify the signature from the ownership address one transaction away (we can use the ownership address to devise a protocol for transferring names too). Even though it's a multisig transaction, each key is exposed individually, so the convention is the 'name' key is always first or something.
Problems:
This method makes names a function of transactions (which miners will like), makes names hard to prune? (if you care about them), effectively putting trust into the blockchain rather than a third party. Names are still discoverable in the sense that you can create a list of names and scan the blockchain for them. As far as how names are domains, consider that namechain is a part of the bitcoin domain. Registering an unsigned name under the namechain domain might involve creating a multisig transaction that includes 'namechain''s keys, your new name's keys, and for now, that pair of secure keys that ensures you don't get robbed while registering. For signed names, that 2 of 2 multisig address you used to register it would act as the signing address similar to a CA scheme. This means we can go as deep as bitcoin allows addresses in a P2SH multisig 'address' (i think 15 or 20, and probably infinite eventually, the current limit is only enforced by the client?). Possible uses for business people: A service that allows users to register a name, and that offers up an API for verifying names and signatures for websites, effectively creating a universal login (because anyone can do it themselves too!). Or a CA service like I mentioned before. Maybe a certain company is developing a compact node you can use at home to verify this kind of stuff and ultimately act as a sort of 1/2FA for pretty much anything. You could do hostname resolution from it by creating a second private key equivalent to an IPv4 or IPv6 address to match with a name and signature. Orphaned blocks are really only a problem if two people register one name in two different valid blocks at the same time, so pretty damn unlikely. There a ton of places to optimize this, but the point is it allows me to associate a name or value with a public key.
Miners could choose to ignore blocks of a name-registration structure without additional fees. Solving the name 'lottery' scenario by using bitcoin Script to allow for registration based on the previously registered name and/or block and necessitating anyone registering a name to create identical transactions would turn the lottery into a 'bid war' per block. Might not be possible. Haven't been looking at the protocol for too long. Tear it to shreds please. Looking into building a proof of concept.
submitted by ftlio to Bitcoin [link] [comments]

Trying to build BU from source for Raspberry Pi 2

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

How miners can support an alternative to the fee market

I've submitted a proposal and would like to get more feedback and support.
The non-technical details:
The fee market is meant to be a way for transaction senders to give up something in exchange for priority processing. Unfortunately because of network congestion, the fees have spiraled out of control.
I have outlined a method for transaction senders to use Proof-of-Work encoded in an OP_RETURN output as a replacement for miner fees. The more work they do, the higher the priority of the transaction.
It won't solve the backlog, but it'll stop the excessive fees for participating transaction senders.
This will require a significant portion of miners to support the concept. If all the miners signaling for a block increase support the policy and run the code, this will work.
Some answers for expected questions or comments
How will we get enough support for it to activate? Since it's just a new mempool prioritization policy, there is no need for any kind of majority of hashpower to support it.
What if it forks the network? There are no risks of forks. This is just mempool prioritization policies for miners.
What clients will be able to create the TxPoW proofs? None yet, obviously, but all the hashing is pretty simple and the methods are already in Bitcoin (SHA256 and RIPEMD160). It would be pretty easy for node implementations or scripts or wallets to add the functionality. Ideally, wallets or nodes will be able to be configured to find the best proof in a certain amount of time (i.e. find the best PoW you can find in 5 seconds)
What about Blockchain bloat? Since the data is stored in OP_RETURN, it can be pruned from block storage.
How can this help with the biggest problem, which is the lack of on-chain scaling? Since it'll allow the "economic majority" to use CPU power to prioritize their transactions on EC supporting miners, they won't signal for USAF because it would force them to use the fee market again. Core also has a problem with "not invented here" syndrome. If it appears in BU/Classic/bcoin/btcsuite first, it'll likely never make it into Core. It'll help illustrate that other than the sep256k speed improvements, Core hasn't really accomplished much of note in the last few years while other implementations are innovating in ways to help Bitcoin and the business community around it thrive.
What would Satoshi think? I think he would like this idea. He embraced PoW as a way for parties to stake an economic interest, and PoW can be used as a way to prove an economic interest in a transaction just as much as miners fees prove.
Why would miners go along with this when they can make so much in transaction fees? Miners are selfish (they're supposed to be), but that doesn't specifically mean that they want to make a load of money in fees. TxPoW transactions will have fees (required to make sure they aren't filtered out on the P2P layer), but they can be the fees we saw a year or two ago. I postulate that miners will see that low transaction fees are better in the long term for the health of the network and will see this as being in their best interest.
What will this enable and why is this good for Bitcoin? If you have a wallet full of dust UTXO's, you can use a lot of CPU power in order to craft a transaction that'll allow you to consolidate them. Micropayments can come back again too.
submitted by DeftNerd to btc [link] [comments]

Bitcoin Miner software PC 2020 windows 10 free download  Mining 0.36 BTC free With Payment Proof Best Bitcoin Mining Software That Work in 2020 The Math Behind Bitcoin The Latest Bitcoin BTC Miner! Bitmain Antminer T19 84 Th/s Review Best Bitcoin Miner in 2020

Bitcoin History is a multipart series from news.Bitcoin.com charting pivotal moments in the evolution of the world’s first cryptocurrency. Read part 16 here . Images courtesy of Shutterstock. RIPEMD160 and SHA256 together, together called HASH160, and Base58Check encoding to produce a Bitcoin wallet address from the public key K. Conclusion When I first started delving into the math of Bitcoin, all I knew was that it uses elliptic curve cryptography in some respect. RIPEMD-160. Bitcoin uses SHA-256 and RIPEMD-160 cryptographic hashes. There are many aspects of Bitcoin that use hashes and the vast majority of them use a double SHA-256 encryption. However, in a few situations that require hashes (such as e-mail addresses), a singular SHA-256 is used in combination with a singular RIPEMD-160 hash.. These hashes, when calculated on a GPU, make it feasible to The address is a unique code that consists of random numbers. The created key should go through two algorithms – SHA-256 and RIPEMD160. This is how the formula looks like (K is for the key and B is for the Bitcoin address) B = RIPEMD160(SHA-256(K)) The main advantage of the use of these two algorithms is an opportunity to create short private OP_HASH160 consumes the topmost item on the stack, computes the RIPEMD160(SHA256()) hash of that item, and pushes that hash onto the stack. There is an incentive model introduced in bitcoin. Whoever the miner first solves the hashing puzzle and adds the block to the blockchain, will get n number of bitcoins.

[index] [24161] [30747] [18871] [12351] [4495] [16318] [9834] [5239] [24977] [20069]

Bitcoin Miner software PC 2020 windows 10 free download Mining 0.36 BTC free With Payment Proof

Bitcoin miner manufacturers like Bitmain and MicroBT are sold out of their Bitcoin BTC ASIC miners, big Bitcoin mining farms are buying up Bitcoin miners in bulk! Clearly, the Bitcoin BTC mining ... #bitcoin #bitcoinminer #giveaway bitcoin,bitcoin mining,free bitcoin mining,free bitcoin,bitcoin giveaway,earn bitcoin,bitcoin mining software,bitcoin generator,best bitcoin mining software ... Smart Bitcoin Miner V1.0 is the perfect Windows mining software for beginners and experts alike, offering a ton of useful features that will help anyone get the greatest amount of Bitcoins with ... bitcoin,bitcoin mining,bitcoin miner,free bitcoin,btc miner,bitcoin news,free bitcoin mining,bitcoin mining 2019,best bitcoin miner,bitcoin free miner,bitcoin mining hardware,bitcoin mining ... Elliptic curves, SHA256, and RIPEMD160, oh my. Dr. Darren Tapp presents the fundamental mathematics needed for Bitcoin to work as intended, prepared so that people of many levels can get something ...

Flag Counter