CashHand

White Paper 2.0

https://cashhand.info/
Introdução Cold Staking Especi cações

O que é CashHand? Governança Masternode Estrutura de

Recompensa

Proof of Staking Masternode Celular Documentação

Masternode Cold Staking Celular Conclusão

 Introdução

As criptomoedas trouxeram uma ampla gama de

oportunidades sem precedentes para empreendedores e investidores com grande potencial de crescimento
econômico.
CashHand surgiu para criar uma oportunidade de pagamento para pequenas compras com criptomoedas.
A indústria de criptomoedas deu origem a um novo mercado e
assim, CashHand; foi criado para fazer mudanças
no mercado, para que o mundo possa aproveitar várias
oportunidades que o mercado de criptografia tem a oferecer.
 O que é CashHand?

CashHand é uma moeda digital descentralizada que não

precisa de um terceiro para funcionar. Isso significa que você não
dependem de bancos, grandes corporações ou governos para mover
seu dinheiro. Com o CashHand, o dinheiro é realmente seu.
CashHand é baseado em um sistema descentralizado extremamente seguro
chamado Blockchain.
 Proof of Staking
Entendendo o Proof of Stake (PoS)
A prova de aposta foi criada como uma alternativa à prova de trabalho (PoW), para resolver questões inerentes a
esta. Quando uma transação é iniciada, os dados da transação são encaixados em um bloco com capacidade
máxima de 1 megabyte e, em seguida, duplicados em vários computadores ou nós na rede. Os nós são o corpo
administrativo do blockchain e verificam a legitimidade das transações em cada bloco. Para realizar a etapa de
verificação, os nós ou mineradores precisariam resolver um quebra-cabeça computacional, conhecido como
problema de prova de trabalho. O primeiro minerador a descriptografar cada problema de transação de bloco é
recompensado com moedas. Depois que um bloco de transações é verificado, ele é adicionado ao blockchain, um
livro-razão público transparente.

Principais vantagens
Com o Proof of Stake (POS), os mineradores CashHand podem minerar ou validar transações em bloco com base
na quantidade que o minerador CashHand mantém.
O Proof of Stake (POS) foi criado como uma alternativa ao Proof of Work (POW), que é o algoritmo de consenso
original na tecnologia Blockchain, usado para confirmar transações e adicionar novos blocos à cadeia.
Prova de Trabalho (POW) requer grandes quantidades de energia, com os mineiros precisando vender suas
moedas para pagar a conta; Prova de aposta (PoS) fornece poder de mineração com base na porcentagem de
moedas em poder de um minerador.
O Proof of Stake (POS) é visto como menos arriscado em termos do potencial para os mineiros atacarem a rede,
pois estrutura a compensação de uma forma que torna o ataque menos vantajoso para o mineiro.
 Masternodes
Além das recompensas tradicionais de Proof of Staking (PoS) para minerar CashHand, os usuários também são recompensados por executar e manter servidores
especiais chamados de masternodes. Masternodes são usados para alimentar o Envio Instantâneo e o sistema de governança. Os usuários são recompensados por
executar masternodes; 85% da recompensa do bloco é alocada para pagar a rede masternode.

Masternodes permitem os seguintes serviços:

Envio Instantâneo
permite transações quase instantâneas. As transações CashHand são totalmente confirmadas em dois segundos.

Cadeados
que protege o blockchain contra ataques de mineração de 51%, assinando blocos à medida que são minerados.

Governança
permitir que as partes interessadas da CashHand determinem a direção do projeto.

Os proprietários do Masternode devem possuir 200 CHND, o que eles provam assinando uma mensagem incluída em uma transação especial gravada no
blockchain. CashHand pode ser movido ou gasto a qualquer momento, mas isso fará com que o masternode saia da fila e pare de ganhar recompensas. Os usuários
do Masternode também têm direito a voto nas propostas. Cada masternode tem um voto e esse voto pode ser usado em propostas de orçamento ou decisões
importantes que afetam o CashHand.

Masternodes custa dinheiro e esforço para hospedar, então eles recebem uma porcentagem da recompensa do bloco como um incentivo. Como apenas um
masternode é pago em cada bloco, a frequência de pagamento pode variar, assim como o valor do CashHand pago.
 Cold Staking

Este documento descreve uma implementação de "Cold Staking" para a rede CASHHAND.
Com o sistema proposto, as chaves privadas das moedas em jogo não precisam mais ser mantidas em um nó
online (quente). O proprietário das moedas pode armazenar as chaves offline com segurança (por exemplo, com
um hardware ou carteira de papel), daí o termo "frio".

https://github.com/CashHand-Project/Cashhand-Wiki/blob/master/Cold-Staking.mediawiki
 Cold Staking

Antecedentes e Motivação

Tradicionalmente, em um algoritmo de consenso de prova de aposta, os produtores de blocos são

obrigados a manter as chaves privadas para as moedas apostadas em nós online.
A razão é dupla. Primeiro, sempre que uma entrada de kernel válida é encontrada, o UTXO
correspondente é usado como entrada para a transação coinstake e, portanto, sua chave privada é
necessária para produzir a assinatura da transação.
Segundo, depois que o bloco é montado, ele deve ser assinado com a mesma chave privada.

Mesmo que o software da carteira tenha uma proteção por senha que permite o uso de chaves
privadas "apenas para piquetagem", a carteira ainda precisa ser descriptografada, o que a deixa sujeita
a vários tipos de ataques em sistemas comprometidos.
Grandes detentores de tokens podem achar que a recompensa por apostar não vale o risco descrito
acima, resultando em menos participação no processo de criação de blocos, o que reduz a segurança
geral da rede (já que é proporcional ao número de moedas apostadas).

Com o "Cold Staking", os produtores de blocos ainda precisam manter um nó online, mas as chaves
privadas para as moedas apostadas podem ser armazenadas offline com segurança. Isto é conseguido
através da assinatura de uma transação especial de "contrato" que transfere os direitos de aposta da
moeda, sem transferir a propriedade da moeda.
 Cold Staking

Definições

A seguinte convenção de nomenclatura é usada para definir os dois atores no sistema:

1 O proprietário da moeda (ou delegador ) é o usuário / carteira que possui as chaves privadas necessárias para gastar as
moedas (por exemplo, uma carteira de hardware).
2 O cold-staker (ou delegado ) é o produtor do bloco, que tem um nó sempre online, com as chaves privadas necessárias
exclusivamente para apostar as moedas. "Cold" aqui alude ao fato de que ele não possui as moedas apostadas, mas ele está
apostando apenas em nome de outra pessoa.
3 A delegação de aposta é a apresentação pelo proprietário da moeda da transação de contrato especial, que transfere os
direitos de aposta para o cold-staker .
4 O saldo delegado é exibido na carteira do proprietário da moeda e representa o valor total dos fundos da carteira que
foram delegados aos cold-stakers. Faz parte do saldo total do dono da moeda, pois pode ser despendido a qualquer
momento.
5 O cold balance é exibido na carteira do cold-staker e representa a soma das moedas recebidas com a delegação da estaca .
NÃO faz parte do saldo total da carteira, pois não pode ser gasto.
 Cold Staking

Especificação
Os recursos de cold staking são obtidos com a introdução na linguagem de script de um novo opcode ,,OP_CHECKCOLDSTAKEVERIFY e a definição de um novo tipo de transação padrão a
partir dele, denominado P2CS (Pay-To-Cold-Staking).

Um script P2CS é definido da seguinte forma:

OP_DUP OP_HASH160 OP_ROT

OP_IF
OP_CHECKCOLDSTAKEVERIFY <HASH160 (stakerPubKey)>
OP_ELSE
<HASH160 (ownerPubKey)>
OP_ENDIF
OP_EQUALVERIFY OP_CHECKSIG
E o scriptSig correspondente é definido como

<signature> OP_TRUE <stakerPubKey> se usado (pelo cold-staker) em uma transação coinstake.

<signature> OP_FALSE <ownerPubKey> se usado (pelo proprietário da moeda) para gastar as moedas em uma transação regular (anulando o contrato de delegação da aposta).
Quando o proprietário da moeda gasta uma saída P2CS, o OP_ELSEramo é selecionado (devido à inclusão de OP_FALSEna pilha), e o script se comporta como uma transação P2PKH normal.
Quando, em vez disso, a saída P2CS é usada como entrada coinstake por um cold-staker, a OP_IFramificação é selecionada e a transação deve passar nas verificações definidas por
OP_CHECKCOLDSTAKEVERIFY:
°A transação deve ser uma transação coinstake
°Todas as entradas devem ter o mesmo scriptSig
°Todas as saídas, exceto a primeira (marcador coinstake) e a última (pagamento de masternode), devem ter o mesmo scriptPubKey e deve corresponder ao scriptPubKey prevtx gasto pelo
scriptSigs de entrada.
Em outras palavras, a única maneira de o cold-staker gastar um UTXO P2CS é enviá-lo para um contrato P2CS idêntico em uma transação coinstake.
Um novo tipo de endereço, "endereço de piquetagem", é definido fornecendo uma versão de codificação Base58Check diferente. Os endereços de piquetagem começam com a letra Sna
rede principal e Wna rede de teste.
Eles são gerados dentro da carteira cold-staker e comunicados ao proprietário da moeda.
O proprietário da moeda, então, cria uma saída P2CS incorporando um de seus endereços (as HASH160(ownerPubKey)) e o endereço de piquetagem recebido (as
HASH160(stakerPubKey)) e envia a transação de delegação de aposta.
A carteira cold-staker reconhece o script de saída P2CS na transação de delegação da aposta e começa a apostar as moedas.
O dono da moeda vê a mudança refletida em seu "saldo delegado", enquanto o apostador vê a quantia em seu "saldo frio".
 Cold Staking

Alterações de validação

A assinatura dos blocos de prova de aposta é tradicionalmente verificada em relação à chave pública
obtida pela segunda saída de coinstake. Para este propósito, os UTXOs P2PKH são convertidos em
P2PK durante o piqueteamento.
Isso não é possível neste sistema porque o proprietário da moeda não conhece a chave pública cold-
staker ao enviar a delegação da estaca.
Ele sabe apenas o endereço de piquetagem, do qual pode derivar apenas o HASH160da chave
pública do cold-staker.
Além disso, o staker (frio) não pode alterar este script como antes, pois as regras definidas acima o
forçam a ser igual ao script de entrada.
No entanto, o cold-staker assina o mesmo script P2CS e publica sua chave no script de entradaSig.
Portanto, os validadores de bloco podem verificar facilmente a assinatura do bloco, obtendo a chave
pública do staker da entrada coinstake, em vez da saída.
 Cold Staking

Fluxo de IU
Dada a especificação acima, a interação básica com o sistema pode ser resumida da seguinte forma:

1) cold-staker cria um endereço de piquetagem (endereço especial começando com 'C') stakerAddr.
2) o proprietário da moeda cria um endereço de recebimento normal ownerAddr.
3) O proprietário da moeda seleciona um número de moedas (ou escolhe um valor CHND permitindo que a carteira escolha as moedas) e cria a
transação especial de "delegação de aposta", usando Próprio endereço stakerAddr, e a transmite para a rede.
4) cold-staker adiciona próprio endereço lista de permissões de delegadores em sua carteira (ou simplesmente "aceita" a delegação tx na GUI).
A partir de agora o cold-staker aposta as moedas enviadas na delegação da estaca em nome do dono da moeda , até que este anule o contrato,
gastando as moedas.
Notas:

A qualquer momento, enquanto o UTXO estiver maduro, o proprietário da moeda pode gastar CHND Próprio endereço (desde que tenha a
chave privada correspondente).
Próprio endereço não precisa necessariamente estar na mesma carteira da qual a transação de delegação de estaca foi enviada. Pode ser
qualquer endereço (por exemplo, uma carteira de papel).
O proprietário da moeda pode reutilizar ownerAddrpara transações de delegação múltipla, até mesmo para diferentes cold stakers (com
stakerAddr endereços diferentes ).
Também stakerAddr pode ser usado para transações de delegação múltipla de proprietários de moedas diferentes (com Próprio endereço
diferentes ).
 Cold Staking

Requisitos de IU
A interface da linha de comando foi enriquecida com as funções necessárias para acessar o recurso.

A GUI terá que fornecer a mesma funcionalidade de uma maneira ergonômica fácil de usar.
Deve-se dar atenção especial ao destacar a diferença visual das transações de cold staking, a fim de evitar que os usuários confundam uma transação de delegação de aposta
específica com uma transação "normal" e a aceitem como um pagamento (como já mencionado, por exemplo, o " equilíbrio frio "deve ser mantido separado do" equilíbrio total "e
deve ficar claro que não faz parte dele).
Outra verificação segura é aplicada no CLI ao enviar uma delegação de estaca usando um "endereço do proprietário" que não está presente na carteira, uma vez que a falta das
chaves privadas correspondentes resultaria em perda de fundos. Para enviar uma delegação de estaca usando um endereço "externo" como proprietário (que seria o caso de uso,
por exemplo, com carteiras de papel), o usuário tem que forçar um argumento específico para true. Isso pode ser simplificado na interface gráfica com um pop-up de aviso.

Por último, a carteira adiciona um sinalizador à transação quando um script P2CS está sendo gasto pelo proprietário da moeda. Isso deve ser conectado na GUI com uma
mensagem de aviso que alerta o usuário de que a delegação da estaca está sendo anulada e pede confirmação antes de prosseguir.
 Governança Masternodes

A governança em um projeto descentralizado é difícil, porque, por definição, não há autoridades centrais para
tomar decisões sobre o projeto.
Na CashHand, tais decisões são tomadas pela rede, ou seja, pelos proprietários dos masternodes.
A Governança do Masternodes permite que cada masternode vote uma vez (sim / não / abstenção) para cada
proposta. Se uma proposta for aprovada, ela pode ser implementada (ou não) pelos desenvolvedores
CashHand.

O Sistema de Governança Masternode da CashHand é implementado na Carteira Móvel descentralizada,

sempre que os desenvolvedores precisam tomar uma decisão importante no projeto, é lançada uma Enquete
na carteira móvel, para que os usuários detentores de Masternodes possam decidir o futuro do projeto.
 Masternodes no Celular

Com o aplicativo CashHand Wallet, você pode executar o Masternode do seu dispositivo móvel
onde quer que esteja.
Esta é a maneira mais segura e fácil de executar Masternodes.
Wallet CashHand masternodes Fácil e prático.
 Cold Staking no celular

CashHand é a primeira criptomoeda do mundo a implementar o

sistema Cold Staking no Wallet mobile.

Ganhe ou mantenha seu CashHand sem comprometer a

segurança, como deveria ser a criptografia.
Leve seu CashHand com você para onde quiser.
 Especificações

Nome: CashHand
Nome Abreviado: CHND
Algoritmo: Quark
Tipo de Bloco: Proof-of-Stake/Masternodes
Tempo de Bloco: 1 Minuto
Recompensa de Staking: 15%
Recompensa de masternodes: 85%
Suprimento Máximo: 42,372,000
Estrutura de Recompensa
 Documentação
Em que tecnologia blockchain CashHand é baseado? BTC ou ETH ou seu próprio blockchain desenvolvido?

CashHand é baseado no código-fonte do BITCOIN / DASH / PIVX . CashHand tem a mesma camada de aplicativo de desenvolvimento do Bitcoin e uma lista de
chamadas de API semelhante.

Website oficial:
https://cashhand.info/

Endereço do Github:
https://github.com/CashHand-Project/cashhand/releases

Documento API:
https://github.com/CashHand-Project/Cashhand-Wiki/tree/master/Developer-Documentation/APIs/JSON-RPC

Como integrar assinatura offline?

Como gerar pares de chaves privadas / públicas e endereços usando Golang?
Como a assinatura da chave privada usa a biblioteca Golang?
Como transmitir a transferência de assinatura?

CashHand pode ser acessado com Golang assim como BITCOIN / DASH / PIVX usando https://github.com/btcsuite/btcd/tree/master/rpcclient
e os documentos de referência em nosso repositório github https://github.com/CashHand-Project/Cashhand-Wiki/tree/master/Developer-
Documentation/APIs/JSON-RPC

Todas as funções ou operações possíveis estão disponíveis no documento Lista de chamadas de API e algumas operações de exemplo sobre elas estão
disponíveis no documento JSON-RPC de referência da API.
 Documentação

Outros exemplos operacionais de recursos online estão disponíveis para Bitcoin que também funciona com Cashhand.

https://www.programmersought.com/article/2595883800/
https://www.thepolyglotdeveloper.com/2018/03/create-sign-bitcoin-transactions-golang/
https://medium.com/swlh/create-raw-bitcoin-transaction-and-sign-it-with-golang-96b5e10c30aa

Navegador de cadeia de blocos:

https://explorer.cashhand.info
https://blockbook.cashhand.info
https://chnd.nodesforall.com

Endereço de download de software / binário

https://github.com/CashHand-Project/cashhand/releases

É aconselhável compilar nosso código-fonte em seu sistema para evitar inconsistências na biblioteca.
https://github.com/CashHand-Project/cashhand/blob/master/doc/build-unix.md

para CentOS, ‘apt-get’ ou ‘apt’ pode ser substituído por ‘yum’

Quantos recursos de CPU e Ram o programa consumirá?

RAM = 512 MB, Disk = 2BG

Quanto espaço em disco é necessário para sincronizar todos os blocos?

O espaço mínimo de armazenamento para dados Cashhand Blockchain requer 2 GB de disco
 Documentação

Principais instruções de operação da API:

Como obter a altura do bloco？

Como criar um novo endereço？
Como transferir？
Como obter todas as transações relacionadas a uma carteira / conta？
Como obter saldo para uma carteira / conta？
Como exportar （despejo / backup） carteira？
Como importar carteira？

Todas as funções ou operações possíveis estão disponíveis no documento Lista de chamadas de API e algumas
operações de exemplo sobre elas estão disponíveis no documento JSON-RPC de referência da API.

https://github.com/CashHand-Project/Cashhand-Wiki/tree/master/Developer-Documentation/APIs/JSON-RPC

https://github.com/CashHand-Project/Cashhand-Wiki/blob/master/Developer-Documentation/APIs/JSON-RPC/API-Calls-List.mediawiki

https://github.com/CashHand-Project/Cashhand-Wiki/blob/master/Developer-Documentation/APIs/JSON-RPC/API-Reference-JSON-RPC.mediawiki
 Conclusão

CashHand é mais do que apenas um novo código criado por desenvolvedores.

É um sistema social que conecta pessoas. Fazer o amanhã um
um mundo melhor e mais acessível deve ser um dever de todos, portanto;
Esse é o objetivo do CashHand.