Bitcoin Cash Lays Roadmap for Reinstating Script Opcodes ...

RXC new video: "Dear Roger, why DSV is a million fold subsidy"

RXC new video: submitted by heuristicpunch to btc [link] [comments]

A TL:DR version of WTF is going on

Can anyone give a TL:DR version of WTF is going on?
I've gathered there is a disagreement over the development path of the coin, and that it's basically ABC vs Nchain, but what is the essence of their disagreement and why? I'm seeking unbiased explanations, thanks
submitted by Tomayachi to btc [link] [comments]

May upgrade is about sending the market the same signal that bitcoin sent 9 years ago:"We are ready. We have revolutionary technology that you can use and that is reliable because we are years ahead of the current demand. Businesses and users, join us and let's all improve our lives with free trade"

May upgrade is about sending the market the same signal that bitcoin sent 9 years ago: submitted by zhell_ to btc [link] [comments]

Since 1.5 years ago, I stopped recommending Bitcoin to family & friends (due to the Bitcoin's failure to scale & censorship). I stopped buying it myself and I haven't bought a single Bitcoin since. Today I just bought $10,000 of Bitcoin Cash. I have renewed confidence in the future of Bitcoin (Cash)

Bitcoin Cash is the scaling that satoshi envisioned. It's what's described in the whitepaper, and it's the Bitcoin I (and most of us) signed up for.
I think the market cap's transition (from Bitcoin to Bitcoin Cash) could take some time. We could be looking at years while the market caps swap.
But the way I see it: Core's plan will not work. 1MB blocks cannot win. And it is my opinion that off-chain scaling solutions are going to be too-little too-late (they already are too-little too-late, and they aren't even ready yet).
Bitcoin Cash's simplicity is what is needed by the market and by actual users and businesses.
I am optimistic for Bitcoin Cash's future-- the first optimism I have felt in the Bitcoin space in 1.5 years. Thank you all who are a part of this movement. We shall keep satoshi's vision alive. Let Core tear it down. Because that is what they are doing.
update: I bought BCH around $208. Now BCH is $265. Buying at the dip was smart.
Also, for any trolls who are thinking about wasting people's time by posting their replies to this thread, please just refrain from posting at all. You realize you don't have to post here right? So please don't. Just go spread your hate for Bitcoin Cash in bitcoin and leave it civilized here. Thank you.
submitted by BitcoinIsTehFuture to btc [link] [comments]

Contrats d'exécution consensuels de VDS et processus du téléchargement à la chaîne

Résumé des contrats d’exécution consensuels
Le concept de base du contrat d’exécution consensuels
Contrats d’exécution consensuels, connu sous le nom de contrat intelligent dans l'industrie de la blockchain, mais l'équipe de VDS estime que ce terme est trop marketing, car nous n'avons pas trouvé à quel point la technologie de programmation contractuelle est intelligente jusqu'à présent, il s'agit simplement d'un système décentralisé dans le réseau distribué, la procédure prédéfinie de comportement consensuel formée par l'édition de code. Dans l'esprit de rechercher la vérité à partir des faits, nous pensons qu'il est plus approprié de renommer le contrat intelligent en tant que contrat d'exécution de consensus. Lorsque les humains combineront la technologie blockchain avec la technologie d'intelligence artificielle de AI à l'avenir, les obstacles à la compréhension des noms sont éliminés.
Le contrat d'exécution consensuel peut être appliqué à de nombreuses industries, telles que la finance, l'éducation, les systèmes administratifs, l'Internet des objets, le divertissement en ligne, etc. Grâce à la technologie de la blockchain, dans un réseau distribué spécifique, un script d'exécution qui est formé par l'édition de pré-code sans aucune intervention de tiers et le comportement de consensus des deux parties ou de plusieurs parties impliquées dans le protocole. Il garantit l’exécution sûre, stable et équitable des droits et intérêts de tous les participants au contrat.
Le contrat d'exécution consensuel a joué un rôle dans l'accélération de l'atterrissage de diverses applications pour le développement de l'industrie de la blockchain et a incité davantage de développeurs à y participer activement, révolutionnant l'expérience réelle des produits de la technologie de la blockchain. Tout découle des contributions exceptionnelles de l'équipe Ethereum, ouvrant une nouvelle porte à l'ensemble de l'industrie.
Structure de base et jonction
L’intégration de EVM
La machine virtuelle Ethereum (EVM) utilise un code machine 256 bits et est une machine virtuelle basée sur la pile utilisée pour exécuter les contrats d'exécution consensuels d'Ethereum. Étant donné que l'EVM est conçu pour le système Ethereum, le modèle de compte Ethereum (Account Model) est utilisé pour la transmission de valeurs. La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La raison de cette conception est, d'une part, c'est en raison de la nécessité de réaliser la fonction d'échange de résonance de VDS et la fonction d'échange inter-chaîne unidirectionnelle de bitcoin à chaîne VDS, qui peuvent réaliser la génération de deux adresses différentes de bitcoin et VDS avec une clé privée. D'autre part, l'équipe VDS estime que la structure sous-jacente des transactions Bitcoin est plus stable et fiable grâce à 10 ans de pratique sociale. Par conséquent, VDS utilise une couche d'abstraction de compte (Account Abstraction Layer) pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par EVM. De plus, VDS a ajouté une interface basée sur le modèle de compte, afin qu'EVM puisse lire directement les informations sur la chaîne VDS. Il convient de noter que la couche d'abstraction de compte peut masquer les détails de déploiement de certaines fonctions spécifiques et établir une division des préoccupations pour améliorer l'interopérabilité et l'indépendance de la plate-forme.
Dans le système Bitcoin, ce n'est qu'après la vérification du script de déverrouillage (Script Sig) et du script de verrouillage (Script Pub Key) que la sortie de transaction correspondante peut être dépensée.
Par exemple, le script de verrouillage verrouille généralement une sortie de transaction sur une adresse bitcoin (la valeur de hachage de la clé publique). Ce n'est que lorsque les conditions de configuration du script de déverrouillage et du script de verrouillage correspondent, que l'exécution du script combiné affiche le résultat sous la forme True (la valeur de retour de système est 1), de sorte que la sortie de transaction correspondante sera dépensée.
Dans le système distribué de VDS, nous soulignons l'opportunité de l'exécution du contrat d'exécution consensuel. Par conséquent, nous avons ajouté les opérateurs OP_CREATE et OP_CALL au script de verrouillage. Lorsque le système de VDS détecte cet opérateur, les nœuds de l'ensemble du réseau exécuteront la transaction. De cette façon, le rôle joué par le script Bitcoin est plus de transférer les données pertinentes vers EVM, pas seulement en tant que langage de codage. Tout comme Ethereum exécute un contrat d'exécution de consensus, le contrat déclenché par les opérateurs OP_CREATE et OP_CALL, EVM changera son état dans sa propre base de données d'état.
Compte tenu de la facilité d'utilisation du contrat d'exécution du consensus de la chaîne VDS, il est nécessaire de vérifier les données qui déclenchent le contrat et la valeur de hachage de la clé publique de la source de données.
Afin d'éviter que la proportion d'UTXO sur la chaîne de VDS ne soit trop importante, la sortie de transaction de OP_CREATE et OP_CALL est t conçue pour être dépensée. La sortie de OP_CALL peut envoyer des fonds pour d'autres contrats ou adresses de hachage de clé publique.
Tout d’abord, pour le contrat d'exécution consensuel créé sur la chaîne VDS, le système généreraune valeur de hachage de transaction pour l'appel de contrat.Le contrat nouvellement libéré a un solde initial de 0 (les contrats avec un solde initial ne sont pas 0 ne sont pas pris en charge). Afin de répondre aux besoins du contrat d'envoi de fonds, VDS utilise l'opérateur OP_CALL pour créer une sortie de transaction. Le script de sortie du contrat d'envoi de fonds est similaire à :
1: the version of the VM
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
Ce script n'est pas compliqué et OP_CALL effectue la plupart du travail requis. VDS définit le coût spécifique de la transaction (sans tenir compte de la situation de out-of-gas) comme Output Value, qui est Gas Limit. Le mécanisme spécifique du Gas sera discuté dans les chapitres suivants. Lorsque le script de sortie ci-dessus est ajouté à la blockchain, la sortie établit une relation correspondante avec le compte du contrat et se reflète dans le solde du contrat. Le solde peut être compris comme la somme des coûts contractuels disponibles.
La sortie d'adresse de hachage de clé publique standard est utilisée pour le processus de base des transactions de contrat, et le processus de transaction entre les contrats est également généralement cohérent. En outre, vous pouvez effectuer des transactions par P2SH et des transactions non standard (non-standard transactions). Lorsque le contrat actuel doit être échangé avec un autre contrat ou une adresse de hachage de clé publique, la sortie disponible dans le compte du contrat sera consommée. Cette partie de la sortie consommée doit être présente pour la vérification des transactions dans le réseau de VDS, que nous appelons la transaction attendue du contrat (Expected Contract Transactions). Étant donné que la transaction attendue du contrat est générée lorsque le mineur vérifie et exécute la transaction, plutôt que d'être générée par l'utilisateur de la transaction, elle ne sera pas diffusée sur l'ensemble du réseau.
Le principe de fonctionnement principal de la transaction attendue du contrat est réalisé par le code OP_SPEND. OP_CREATE et OP_CALL ont deux modes de fonctionnement. Lorsque l'opérateur est utilisé comme script de sortie, EVM l'exécute, lorsque l'opérateur est utilisé comme script d'entrée, EVM ne sera pas exécuté (sinon il provoquera une exécution répétée). Dans ce cas, OP_CREATE et OP_CALL peuvent être utilisés comme Opération sans commandement. OP_CREATE et OP_CALL reçoivent la valeur de hachage de transaction transmise par OP_SPEND et renvoient 1 ou 0 (c'est-à-dire il peut être dépensé ou pas). Il montre l'importance de OP_SPEND dans la transaction attendue de l'intégralité du contrat. Plus précisément, lorsque OP_SPEND transmet la valeur de hachage de transaction à OP_CREATE et OP_CALL, OP_CREATE et OP_CALL comparent si la valeur de hachage existe dans la liste des transactions attendues du contrat. S'il existe, renvoyez 1 pour dépenser, sinon retournez 0, ce n'est pas pour dépenser. Cette logique fournit indirectement un moyen complet et sûr de garantir que les fonds du contrat ne peuvent être utilisés que par le contrat, ce qui est cohérent avec le résultat des transactions UTXO ordinaires.
Lorsque le contrat EVM envoie des fonds à l'adresse de hachage de clé publique ou à un autre contrat, une nouvelle transaction sera établie. À l'aide de l'algorithme de Consensus-critical coin picking, la sortie de transaction la plus appropriée peut être sélectionnée dans le pool de sortie disponible du contrat. La sortie de transaction sélectionnée sera utilisée comme script d'entrée pour exécuter un seul OP_SPEND, et la sortie est l'adresse cible des fonds, et les fonds restants seront renvoyés au contrat, tout en modifiant la sortie disponible pour la consommation. Ensuite, la valeur de hachage de cette transaction sera ajoutée à la liste des transactions attendues du contrat. Lorsque la transaction est exécutée, la transaction sera immédiatement ajoutée au bloc. Une fois que les mineurs de la chaîne ont vérifié et exécuté la transaction, la liste des transactions attendues du contrat est à nouveau parcourue. Une fois la vérification correcte, la valeur de hachage est supprimée de la table. De cette façon, l'utilisation de OP_SPEND peut effectivement empêcher l'utilisation de valeurs de hachage codées en dur pour modifier le coût de la sortie.
La couche d'abstraction des comptes VDS élimine la nécessité pour l'EVM d'accorder trop d'attention à coin-picking. Il lui suffit de connaître le solde du contrat et peut échanger des fonds avec d'autres contrats ou même des adresses de hachage de clé publique. De cette façon, seule une légère modification du contrat d'exécution du consensus Ethereum peut répondre aux exigences de fonctionnement du contrat VDS.
En d'autres termes, tant que le contrat d'exécution consensuel peut être exécuté sur la chaîne Ethereum, il peut s'exécuter sur la chaîne VDS.
Achèvement de AAL
La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La plate-forme générale de contrat d'exécution de consensus utilise le modèle de compte. Étant donné que le contrat en tant qu'entité nécessite un logo de réseau, ce logoest l'adresse du contrat, de sorte que le fonctionnement et la gestion du contrat d'exécution consensuel peuvent être effectués par cette adresse. La couche d'abstraction de compte est ajoutée à la conception du modèle (Account Abstraction Layer, AAL) de chaîne de VDS, qui est utilisée pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par le contrat.
Pour les développeurs qui exécutent des contrats par consensus, le modèle de compte de la machine virtuelle est relativement simple. Il prend en charge l'interrogation des soldes des contrats et peut également envoyer des fonds pour d'autres contrats. Bien que ces opérations semblent très simples et basiques, toutes les transactions de la chaîne VDS utilisent le langage de script Bitcoin, et il est plus compliqué que prévu d'être implémenté dans la couche d'abstraction de compte de la chaîne VDS basée sur le modèle Bitcoin UTXO. AAL a donc élargi sa base en ajoutant trois nouveaux opérateurs :
OP_CREATE est utilisé pour effectuer la création de contrats intelligents, transmettre le code d'octet transmis via la transaction à la base de données de stockage de contrats de la machine virtuelle et générer un compte de contrat.
OP_CALL est utilisé pour transférer les données pertinentes et les informations d'adresse nécessaires pour appeler le contrat et exécuter le contenu du code dans le contrat. (Cet opérateur peut également envoyer des fonds pour des contrats d'exécution consensuels).
OP_SPEND utilise la valeur de hachage de ID de contrat actuel comme transaction d'entrée HASH ou transaction HASH envoyée à l'UTXO du contrat, puis utilise OP_SPEND comme instruction de dépense pour créer un script de transaction.
Utilisation des Contrats et processus du téléchargement à la chaîne
Rédiger les contrats
Il est actuellement possible d'utiliser le langage Solidity pour rédiger des contrats d'exécution de consensus.
Utilisez Solidity Remix ou un autre Solidity IDE pour l'écriture et la compilation de code.
solidity remix(https://remix.ethereum.org/
Il est recommandé d'utiliser le mode homestead pour compiler.
Il est recommandé d'utiliser la version solidité 0.4.24 (si d'autres versions sont utilisées, cela peut provoquer des erreurs ou des échecs).
La syntaxe Solidity peut être référencée(https://solidity.readthedocs.io/en)
Compiler et déployer les contrats
Fonctionnement du contrat intelligent de vdsd
Examiner les variables de fonctionnement de l'environnement
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
> Les tests sous contrat sont effectués dans l'environnement de test. Il est recommandé de tester après avoir atteint une hauteur de 440 blocs.
440 blocs hautement achevés l'opération de retour de fonds après les événements anormaux du contrat (refund) et (revert).
La commande de contrat de déploiement est :
```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
Cette fonction est utilisée pour l'exécution du constructeur du contrat avec les paramètres entrants pour obtenir le ByteCode qui est finalement utilisé pour le déploiement.
(Cette méthode consiste à associer le bytecode à ABI et à le stocker localement pour l'enregistrement. Il peut appeler des méthodes internes localement et renvoyer le bytecode approprié)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
La valeur de retour est : txid, éxpéditeur, hachage de l'expéditeur160, adresse du contrat
Consulter si la commande a été exécutée avec succès :
```vds-cli gettransactionreceipt txid```
La valeur de retour de txid pour les transactions non contractuelles est vide
La valeur de retour est : Les informations pertinentes de txid sur la BlockHash Hachage du bloc
- blockNumber Hauteur de bloc
- transactionHash Hachage de transaction
- transactionIndex La position de l'échange dans le bloc
- from Hachage de l’adresse de l’expéditeur 160
- to Le destinataire est l'adresse du contrat, le lieu de création de la transaction contractuelle est 00000000000000000000000000000
- cumulativeGasUsed Gas accumulé
- gasUsed Gaz réellement utilisé
- contractAddress Adresse du contrat
- excepted Y a-t-il des erreurs
- exceptedMessage Message d'erreur
-
Il convient de noter que le champ excepted n'est pas None, ce qui indique que l'exécution du contrat a échoué. Bien que la transaction puisse être vérifiée sur la chaîne, cela ne signifie pas que le contrat a été exécuté avec succès, c'est-à-dire que les frais de traitement pour l'exécution de ce contrat ne sont pas remboursables. Les frais de traitement ne seront remboursés que si la méthode revert est entrée dans le contrat, et les frais de méthode ne seront pas remboursés pour la méthode assert.
Appel des contrats
```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
Cette fonction est utilisée pour ajouter le contrat ABI à la base de données locale.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
Cette fonction est utilisée pour obtenir les informations du contrat ajouté.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
Cette fonction renverra le résultat de l'exécution lors de l'appel de la méthode constante ordinaire, comme l'appel de la méthode d'opération de données de contrat retournera la chaîne de format hexadécimal du script d'opération.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
Cette fonction est utilisée pour envoyer le script d'opération de contrat au contrat spécifié et le faire enregistrer sur la blockchain.
Consultation des résultats d’exécution des contrats
```vds-cli gettransaction txid```
Cette commande est utilisée pour afficher les heures de confirmation de la transaction de portefeuille actuelle.
```vds-cli gettransactionreceipt txid```
Cette commande est utilisée pour vérifier les résultats d'exécution de la création de contrat et des transactions d'appel, s'il y a des exceptions levées et des consommations réelles de GAS.
`${datadir}/vmExecLogs.json` enregistrera les appels de contrat sur la blockchain. Ce fichier servira d'interface externe pour les événements de contrat.
Interface d'appel des contrats
l Interface de création de contrat createcontract
l Interface de déploiement de contrat deploycontract
l Interface d'ajout ABI addcontract
l Interface d’appel des contrats avec l’opération des fons sendtocontract
l Interface de lecture des informations sur les contrats callcontractfunc
l Interface d'acquisition d'informations sur l'exécution des transactions contractuelles gettransactionreceipt
L’expliquation des coûts d’expoitation des contrats
Les coûts de fonctionnement de la création d'un contrat sont toutes des méthodes estimées, et un succès d'exécution à 100% ne peut pas être garanti, car gas limit a une limite supérieure de 50000000, et les contrats dépassant cette limite entraîneront un échec. La chaîne de VDS utilise une méthode de rendre la monnaie, ce qui signifie que même si beaucoup de gaz est envoyé, le mineur n'utilisera pas tout le gas et restituera le gas restant. Alors ne vous inquiétez pas de dépenser trop de gas.
Le coût de création d'un contrat est approximativement de la taille du Byte Code * 300 comme gas limit, le gas price minimum est de 0.0000004, gas price * gas limit est le coût de création d'un contrat.
En ce qui concerne l'exécution de la méthode dans un contrat, le gas requis est estimé. En raison de la congestion du réseau, l'estimation ne garantit pas que 100% peuvent être téléchargés avec succès dans la chaîne. Par conséquent, je crains de tromper et de demander au développeur de vérifier les résultats.
submitted by YvanMay to u/YvanMay [link] [comments]

Upcoming Updates to Bitcoin Consensus

Price and Libra posts are shit boring, so let's focus on a technical topic for a change.
Let me start by presenting a few of the upcoming Bitcoin consensus changes.
(as these are consensus changes and not P2P changes it does not include erlay or dandelion)
Let's hope the community strongly supports these upcoming updates!

Schnorr

The sexy new signing algo.

Advantages

Disadvantages

MuSig

A provably-secure way for a group of n participants to form an aggregate pubkey and signature. Creating their group pubkey does not require their coordination other than getting individual pubkeys from each participant, but creating their signature does require all participants to be online near-simultaneously.

Advantages

Disadvantages

Taproot

Hiding a Bitcoin SCRIPT inside a pubkey, letting you sign with the pubkey without revealing the SCRIPT, or reveal the SCRIPT without signing with the pubkey.

Advantages

Disadvantages

MAST

Encode each possible branch of a Bitcoin contract separately, and only require revelation of the exact branch taken, without revealing any of the other branches. One of the Taproot script versions will be used to denote a MAST construction. If the contract has only one branch then MAST does not add more overhead.

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

A Guide To The BCH Fork on November 15th - Be Informed!

BCH November 15th Forking Guide
 
Intro
As you may have heard, on 15th November 2018 the Bitcoin Cash Blockchain will fork into at least two separate chains. We felt it our duty to provide information to the community on the situation that we hope will offer some clarity on this rather complex situation.
 
What Is A Fork?
A fork occurs when at least one group of miners decide to follow a separate set of rules from the current consensus protocol. Due to the way bitcoin is designed, these miners will then operate on a separate network from the current network. This was in fact how Bitcoin Core and Bitcoin Cash was created from the original Bitcoin. Both changed the consensus rules in different ways that made them incompatible.
To make the current situation slightly more complex, there are to be two sets of miners that are changing the protocol rules away from the current protocol. It is not expected that the currently operating consensus rules will be in operation by any significant set of miners after November 15th. This means that after November 15th there will be two new sets of competing protocol rules. For simplicity these will be described as the BitcoinABC ruleset and the BitcoinSV ruleset (although other implementations such as Bitcoin Unlimited, bcash, bchd, BitcoinXT and bitprim all also have the ABC consensus ruleset).
This is quite a unique fork situation as one side (BitcoinSV) has indicated that they will be willing to attack their competition (BitcoinABC) using reorgs and doublespends to destabilise and reduce confidence in it.
 
BitcoinABC Fork Details
The main new features in the BitcoinABC that make it incompatible with the current protocol are CTOR and DSV.
To summarise:
CTOR (Canonical Transaction Ordering) is a technology that allows blocks to be transmitted in a much more efficient way. This means that as blocks become larger as the network gains more adoption, the hardware and bandwidth requirements on nodes is decreased. This reduces centralisation pressures and allows us to scale the network with fewer adverse effects. You can read more about CTOR in this excellent ARTICLE by u/markblundeberg.
DSV (CheckDataSigVerify) is a technology that allows oracles directly on the Bitcoin blockchain. This means that the transactions on the Bitcoin blockchain can be dependent on actions that happen in the real world. For example you could bet on the weather tomorrow, or if a specific candidate wins an election, all directly on the blockchain. You can read more about DSV at this excellent ARTICLE by u/mengerian.
 
BitcoinSV Fork Details
The main new features in the BitcoinSV that make it incompatible with the current protocol are an increase in the default block size limit to 128MB, increase of the 201 opcode limit within Bitcoin’s script system to a maximum of 500 opcodes, and a new set of opcodes including; OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT.
The increase in the default block size limit will in theory allow miners on the BitcoinSV ruleset to produce and propagate blocks up to 128MB in size. It may be the case that the current state of the network cannot handle, or at least sustain, 128MB blocks but this will allow miners to decide if they want to try and produce blocks over 32MB (the current protocol limit agreed upon by miners).
Increasing the opcode limit will allow miners to make transactions using scripts of larger lengths. This means that more complex scripts can be developed.
The new opcodes allow new operations to happen within the Bitcoin scripting system.
 
What Are Your Options?
When the fork happens your coins will become available on both chains. This is because both chains will share the same blockchain history up until the point the fork occurs. Things are unfortunately not quite as simple as that (when are they ever in cryptoland?). Transactions that would be valid on both chains will occur on both chains. Your transactions will be considered valid on both chains as long as you do not use any of the exclusive features from either ruleset, or use inputs from transactions that are considered invalid on one of the chains. You can alternatively split your coins so that you can control them exclusively on each chain.
So what should you do? We won’t recommend what you should do with your own money, and this is not financial advice, but here are some of your options.
 
Do Nothing and HODL
The simplest option is to keep your Bitcoin Cash in a wallet you control and wait for things to blow over. Make sure you have the private keys and or the seed written down in at least one place to be able to recover your funds if needed. As long as you do not move your funds they will be available on both chains after the fork.
Risks - Price volatility. Like always the price can go up and down any amount. Only risk what you can afford to lose.
 
Sell BCH for Fiat
Another simple option is to sell your BCH for fiat. This means moving your Bitcoin Cash to an exchange such as Bitstamp.net, Kraken.com or Coinbase, and then selling them for a fiat currency. You may also consider then withdrawing your funds to your bank account for extra security (exchanges have been known to implode with everyone’s funds every now and again).
Risks - If the BCH price increase while you hold fiat your BCH holdings will be less if and when you buy back. Exchanges and banks can confiscate your money if they like (that why love Bitcoin remember). By selling you may also be liable for taxes in your jurisdiction.
 
Split Your Coins and HODL
If you want to be ready for anything then you can split your coins after the fork occurs. This means that you will be able to control your coins exclusively on each chain. You will still need to make sure you have your wallet(s) backed up and have the private keys and seeds written down somewhere.
To split your coins you can use a tool developed on Electron Cash HERE. This is unfortunately not a simple tool to use right now. Make sure to read the tips and advice given in that thread. You can also use http://forkfaucet.cash/ to receive a tiny amount of split coins to your address(es) so that they will become split once you spend from them.
Risks - This has the same risks as simply HODLing your BCH. You should also be aware that some services have decided to refuse to use split coins during the fork. This means that if you send them split coins they will not allow you to spend them. These services include: Yours.org, moneybutton, HandCash, CentBee and CoinText.
 
Split Your Coins and Sell Some
If you interested in gambling on which chain will be more successful you can split your coins using the method above, and can then send coins from either chain to an exchange that allows buying and selling of specific sides of the chain. Most exchanges have decided to close deposits and withdrawals of BCH and even trading of BCH until the outcome of the forks have become more clear. After the fork occurs exchanges will likely make announcements about whether which chain they will support (potentially both), and you will then be able to trade each fork as separate cryptocurrencies.
Risks - By selling your coins on one of the chains you will no longer be invested in that side of the fork. In the case that one side of the fork ceases to exist and you are only holding coins on that side, you will have lost that money. By selling you may also be liable for taxes in your jurisdiction.
 
Summary
It is unfortunate that Bitcoin Cash has to go through a fork without unanimous consensus on the new protocol rules. The unique situation with this fork, in particular, has presented some interesting new issues, and it is likely that we as a community will learn a lot from it.
We hope that in similar situations in the future that the major entities in the industry, including miners, developers, businesses and community leaders can come together to find compromise that keeps the ecosystem stable and focused on adoption.
Further Resources
You can get more information at bitcoincash.org, bitcoinabc.org, bitcoinsv.io, and bitcoin.com.
If you have further questions about this or just want to discuss the fork in general, we encourage you to join our chat at bitcoincashers.org/chat and join the conversation.
 
Edit: The fork will occur at roughly 17:40 UTC+0 15.11.2018
Edit 2: Join a livestream at https://www.youtube.com/watch?v=SxeeQ_-QVNo
submitted by cashassociation to btc [link] [comments]

Gavin Wood: the attacker is back - looks like he's managing to push required memory usage up quite a bit partly through exploiting a 0-cost SUICIDE issue; basically they're able to create loads of new accounts at near 0 cost.

Gavin Wood: the attacker is back - looks like he's managing to push required memory usage up quite a bit partly through exploiting a 0-cost SUICIDE issue; basically they're able to create loads of new accounts at near 0 cost. submitted by arrnx to ethereum [link] [comments]

ETH is getting over run by ASIC and will almost be entirely secured by ASICs come end of October.

Come end of October when block rewards change, all I would assume the majority of GPU that secure the network will go offline. Power costs are much higher than rewards unless you have free power. We will have what was supposed to be an ASIC resististant crypto be almost entirely secured by ASICs because dev's cant keep their word. Until it switches to POS, there will be a sizable period where decentralisation will be at an all time low.
submitted by NexusKnights to ethereum [link] [comments]

Why CHECKDATASIG Does Not Matter

Why CHECKDATASIG Does Not Matter

In this post, I will prove that the two main arguments against the new CHECKDATASIG (CDS) op-codes are invalid. And I will prove that two common arguments for CDS are invalid as well. The proof requires only one assumption (which I believe will be true if we continue to reactive old op-codes and increase the limits on script and transaction sizes [something that seems to have universal support]):
ASSUMPTION 1. It is possible to emmulate CDS with a big long raw script.

Why are the arguments against CDS invalid?

Easy. Let's analyse the two arguments I hear most often against CDS:

ARG #1. CDS can be used for illegal gambling.

This is not a valid reason to oppose CDS because it is a red herring. By Assumption 1, the functionality of CDS can be emulated with a big long raw script. CDS would not then affect what is or is not possible in terms of illegal gambling.

ARG #2. CDS is a subsidy that changes the economic incentives of bitcoin.

The reasoning here is that being able to accomplish in a single op-code, what instead would require a big long raw script, makes transactions that use the new op-code unfairly cheap. We can shoot this argument down from three directions:
(A) Miners can charge any fee they want.
It is true that today miners typically charge transaction fees based on the number of bytes required to express the transaction, and it is also true that a transaction with CDS could be expressed with fewer bytes than the same transaction constructed with a big long raw script. But these two facts don't matter because every miner is free to charge any fee he wants for including a transaction in his block. If a miner wants to charge more for transactions with CDS he can (e.g., maybe the miner believes such transactions cost him more CPU cycles and so he wants to be compensated with higher fees). Similarly, if a miner wants to discount the big long raw scripts used to emmulate CDS he could do that too (e.g., maybe a group of miners have built efficient ways to propagate and process these huge scripts and now want to give a discount to encourage their use). The important point is that the existence of CDS does not impeded the free market's ability to set efficient prices for transactions in any way.
(B) Larger raw transactions do not imply increased orphaning risk.
Some people might argue that my discussion above was flawed because it didn't account for orphaning risk due to the larger transaction size when using a big long raw script compared to a single op-code. But transaction size is not what drives orphaning risk. What drives orphaning risk is the amount of information (entropy) that must be communicated to reconcile the list of transactions in the next block. If the raw-script version of CDS were popular enough to matter, then transactions containing it could be compressed as
....CDS'(signature, message, public-key)....
where CDS' is a code* that means "reconstruct this big long script operation that implements CDS." Thus there is little if any fundamental difference in terms of orphaning risk (or bandwidth) between using a big long script or a single discrete op code.
(C) More op-codes does not imply more CPU cycles.
Firstly, all op-codes are not equal. OP_1ADD (adding 1 to the input) requires vastly fewer CPU cycles than OP_CHECKSIG (checking an ECDSA signature). Secondly, if CDS were popular enough to matter, then whatever "optimized" version that could be created for the discrete CDS op-codes could be used for the big long version emmulating it in raw script. If this is not obvious, realize that all that matters is that the output of both functions (the discrete op-code and the big long script version) must be identical for all inputs, which means that is does NOT matter how the computations are done internally by the miner.

Why are (some of) the arguments for CDS invalid?

Let's go through two of the arguments:

ARG #3. It makes new useful bitcoin transactions possible (e.g., forfeit transactions).

If Assumption 1 holds, then this is false because CDS can be emmulated with a big long raw script. Nothing that isn't possible becomes possible.

ARG #4. It is more efficient to do things with a single op-code than a big long script.

This is basically Argument #2 in reverse. Argument #2 was that CDS would be too efficient and change the incentives of bitcoin. I then showed how, at least at the fundamental level, there is little difference in efficiency in terms of orphaning risk, bandwidth or CPU cycles. For the same reason that Argument #2 is invalid, Argument #4 is invalid as well. (That said, I think a weaker argument could be made that a good scripting language allows one to do the things he wants to do in the simplest and most intuitive ways and so if CDS is indeed useful then I think it makes sense to implement in compact form, but IMO this is really more of an aesthetics thing than something fundamental.)
It's interesting that both sides make the same main points, yet argue in the opposite directions.
Argument #1 and #3 can both be simplified to "CDS permits new functionality." This is transformed into an argument against CDS by extending it with "...and something bad becomes possible that wasn't possible before and so we shouldn't do it." Conversely, it is transformed to an argument for CDS by extending it with "...and something good becomes possible that was not possible before and so we should do it." But if Assumption 1 holds, then "CDS permits new functionality" is false and both arguments are invalid.
Similarly, Arguments #2 and #4 can both be simplified to "CDS is more efficient than using a big long raw script to do the same thing." This is transformed into an argument against CDS by tacking on the speculation that "...which is a subsidy for certain transactions which will throw off the delicate balance of incentives in bitcoin!!1!." It is transformed into an argument for CDS because "... heck, who doesn't want to make bitcoin more efficient!"

What do I think?

If I were the emperor of bitcoin I would probably include CDS because people are already excited to use it, the work is already done to implement it, and the plan to roll it out appears to have strong community support. The work to emulate CDS with a big long raw script is not done.
Moving forward, I think Andrew Stone's (thezerg1) approach outlined here is an excellent way to make incremental improvements to Bitcoin's scripting language. In fact, after writing this essay, I think I've sort of just expressed Andrew's idea in a different form.
* you might call it an "op code" teehee
submitted by Peter__R to btc [link] [comments]

ATTENTION MINERS: Recommending miners lower the gas limit target to 2 million

Although the hard fork yesterday was successful and network health improved, there is an ongoing attack that causes increased block processing times on certain blocks. Mitigation strategies are being investigated. In order to subvert some of the negative affects of the current attack, we are asking miners to lower their gas limit target to 2 million.
More details: https://www.reddit.com/ethereum/comments/589l6b/lol_i_think_its_another_attack_contract_burns/
submitted by Souptacular to ethereum [link] [comments]

Welcome to r/Bithereum - The official subreddit for the Bithereum Network!

Hello and welcome to the official Bithereum subreddit! Our goal here is to provide a home for friendly and informative discussions regarding Bithereum and to build a positive community. We encourage all to participate while respecting our community guidelines outlined below.
What is Bithereum?
Bithereum is a coin that is created via forking the Bitcoin blockchain. BTH will function as a peer-to-peer electronic cash system similar to Bitcoin, however it will fuse with the technological roadmap of Ethereum to create a more technologically advanced platform which is structured around Proof of Stake consensus.
The current issues plaguing Bitcoin are the community schism, scalability, proof of work, and the rise of the mining cartel. The deep divide has pitted the once strong community against each other with no common ground on solutions for any of the current/future issues. In addition, the rise of ASICs and the 4 mining pools that dominate 61% of the hashpower create a level of centralization in consensus. Instead of sparring over on-chain and off-chain scaling solutions, Bithereum recognizes the importance of both, and will incorporate all-encompassing solutions.
Proof of Stake will make the network faster, more efficient, cheaper to run, and more secure. It eliminates the need for expensive hardware, mitigates high energy costs, prevents both ASICs/large pools from dominating, and increases the network security from 51% attacks. Issues faced in common PoS protocols are alleviated through Ethereum’s Casper protocol and its slashing conditions. With this implemented into Bithereum, the benefits of this technology will positively affect Bitcoin’s issues and ensure its long term success.
Since a Casper contract can be created using Ethereum smart contracts, which is not the case with Bitcoin, Bithereum will leverage various opcodes and introduce new opcodes with built in functionality that mimics Casper-like Proof of Stake. More details about our Proof of Stake model can be found starting on page 14 of our white paper.
Bithereum essentially creates an outlet for both Bitcoin and Ethereum, allowing BTC to take on its new role as digital gold, and allowing ETH to be used for its true purpose, as fuel for a worldwide computer that can contain a vast ecosystem of dApps on its platform. With the harmonization of Ethereum’s technology and Bitcoin’s vision, Bithereum will bring together the best of the two leading cryptocurrencies to create an unparalleled peer-to-peer digital currency.
What’s a Spork?
Bithereum will be a coin that benefits both Bitcoin and Ether holders, becoming the first hard spork of its kind. Bitcoin will first be hard forked to make changes to the protocol that will allow it to be a more technologically advanced peer-to-peer currency, while Ethereum will be hard spooned (thanks to the Cosmos team for this term) by taking a snapshot of the existing account balances of ETH holders to reward them in Bithereum. As BTH utilizes a significant portion of Ethereum's vision, unlike all of the other BTC forks, we will also be awarding all ETH holders with coins, giving them the ability to stake their coins in the future as well. All ETH will be redeemable at a price ratio of ETH:BTC at the time of the spork (i.e if the ratio is 10:1 and you have 10 ETH, you can redeem 1 BTH.)
For further details on the process, you can head over to the FAQ section of the website at https://bithereum.network/#section-faq.
ETH holders can get started on the process at https://bithereum.network/ethredeem.
Note: Bithereum coins will be released to the BTH address you create for redemption upon the launch in late-September.
Where to find us:
Website: http://bithereum.network
Whitepaper: http://bithereum.network/storage/whitepaper.pdf
Twitter: https://twitter.com/BithereumBTH
Facebook: https://www.facebook.com/BithereumBTH
Telegram: https://t.me/BithereumNetwork
Medium: https://medium.com/@bithereumnetwork
LinkedIn: https://www.linkedin.com/company/bithereumnetwork/
Github: https://github.com/BTHPOS
Community Guidelines:
submitted by BithereumNetwork to Bithereum [link] [comments]

PC keeps shutting down when playing games or running benchmarks

Userbenchmark Test: https://www.userbenchmark.com/UserRun/20687675
What is your parts list?
[PCPartPicker Part List](https://pcpartpicker.com/list/8Z3QzN)

Type|Item|Price
:----|:----|:----
**CPU** | [AMD Ryzen 5 2600 3.4 GHz 6-Core Processor](https://pcpartpicker.com/product/jLF48d/amd-ryzen-5-2600-34ghz-6-core-processor-yd2600bbafbox) | $118.00 @ Amazon
**CPU Cooler** | [NZXT Kraken M22 Liquid CPU Cooler](https://pcpartpicker.com/product/fmx2FT/nzxt-kraken-m22-liquid-cpu-cooler-rl-krm22-01) | $79.99 @ Amazon
**Thermal Compound** | [ARCTIC MX4 4 g Thermal Paste](https://pcpartpicker.com/product/HBXfrH/arctic-cooling-thermal-paste-acmx4) | $8.49 @ OutletPC
**Motherboard** | [ASRock AB350M Pro4 Micro ATX AM4 Motherboard](https://pcpartpicker.com/product/dWL7YJ/asrock-ab350m-pro4-micro-atx-am4-motherboard-ab350m-pro4) | $82.55 @ Amazon
**Memory** | [G.Skill Trident Z RGB 16 GB (2 x 8 GB) DDR4-3000 Memory](https://pcpartpicker.com/product/qjM323/gskill-trident-z-rgb-16gb-2-x-8gb-ddr3-3000-memory-f4-3000c16d-16gtzr) | $88.99 @ Newegg
**Storage** | [Kingston A400 120 GB 2.5" Solid State Drive](https://pcpartpicker.com/product/2FDzK8/kingston-a400-120gb-25-solid-state-drive-sa400s37120g) | $21.99 @ Amazon
**Storage** | [Western Digital Caviar Blue 1 TB 3.5" 7200RPM Internal Hard Drive](https://pcpartpicker.com/product/MwW9TW/western-digital-internal-hard-drive-wd10ezex) | $42.89 @ OutletPC
**Video Card** | [EVGA GeForce GTX 1080 Ti 11 GB SC Black Edition Video Card](https://pcpartpicker.com/product/gwJkcf/evga-geforce-gtx-1080-ti-11gb-sc-black-edition-video-card-11g-p4-6393-kr) | $1199.99 @ Amazon
**Case** | [Phanteks Enthoo EVOLV TG MicroATX Mini Tower Case](https://pcpartpicker.com/product/VkZ2FT/phanteks-enthoo-evolv-tg-black-atx-mini-tower-case-ph-es314etg_bk) | $137.98 @ Newegg
**Power Supply** | [Enermax Platimax 1500 W 80+ Platinum Certified Fully Modular ATX Power Supply](https://pcpartpicker.com/product/yjtCmG/enermax-power-supply-epm1500egt) |-
**Operating System** | [Microsoft Windows 10 Pro OEM 64-bit](https://pcpartpicker.com/product/MfH48d/microsoft-os-fqc08930) | $133.88 @ Amazon
**Monitor** | [Asus MG278Q 27.0" 2560x1440 144 Hz Monitor](https://pcpartpicker.com/product/fMcMnQ/asus-monitor-mg278q) | $413.99 @ Amazon
| *Prices include shipping, taxes, rebates, and discounts* |
| **Total** | **$2328.74**
| Generated by [PCPartPicker](https://pcpartpicker.com) 2019-10-05 09:55 EDT-0400 |

Describe your problem. List any error messages and symptoms. Be descriptive.
Whenever I am playing a game or running benchmarks my monitor will go to a no input screen after a few minutes of running. Sometimes it will freeze and I need to turn off the PSU to turn off the PC. When it shuts down I also hear a click sound, seems like it is coming from the psu, but I am not sure.
System
[ Name] Microsoft-Windows-Kernel-Power [ Guid] {331c3b3a-2005-44c2-ac5e-77220c37d6b4}
EventID 41
Version 6
Level 1
Task 63
Opcode 0
Keywords 0x8000400000000002
[ SystemTime] 2019-09-24T10:06:02.859840100Z
EventRecordID 848
Correlation
[ ProcessID] 4 [ ThreadID] 8
Channel System
Computer DESKTOP-FM7BHJL
[ UserID] S-1-5-18
List anything you've done in attempt to diagnose or fix the problem.
My gaming PC hasn't been working properly for like a year or more. A year or 2 ago I changed all my pc parts for new ones, so all the stuff in my computer is not more than 2 years old. Whenever I am playing a game or running benchmarks my monitor will go to a no input screen after a few minutes of running. I first thought it might be a GPU problem, so i RMA'd it. I have had about 5 different 1080Ti's that were all back from RMA. I have already brought my PC to a repair shop here, they also didnt know where the problem would be. They have checked all the parts, but they couldn't check the MB and CPU. So I send my MB to the place where i bought it from, they tested the MB for 4 hours in different benchmarks and nothing was wrong. I tried installing the gpu into my dad's pc, it still crashed, but after like half a day. I swapped the cpu for a Ryzen 3 1200, but still no luck. I've tried almost anything but nothing seems to work. Reinstalling and factory resetting also doesn't seem to fix the issue. When i unplug the pc and remover the psu cables from the GPU and plug Them back in a fee seconds later, my pc will take longer to crash.
I should add that the PSU is from an old bitcoin miner, i don't know if that has any negative effect on the system.
I hope this is enough info for you guys to help me out with, if any more info is needed just say so ,
thanks in advance
submitted by baslammers to pcgamingtechsupport [link] [comments]

Is it possible to "wrap" BTC as an ERC20 token?

With the bridge recently created by Truebit between the Doge and Ethereum chains, does anyone foresee something similar being possible with BTC?
submitted by celticwarrior72 to ethereum [link] [comments]

How is Craig planning to implement his "lotto" scheme?

So, here, Craig seems to be planning to do a second hard fork (post Nov 15th) to implement a new consensus rule, where a script that contains any unknown OP CODE (including CHECKDATASIG) becomes a miner's fee.
Even if it worked.. flooding miners with thousands upon thousands (millions?) of BCH(SV) in free fees whenever somebody uses DSV or unknown op code on other chain.. would flood the market with free money.. that would dump the price of BCH(SV).. But..
To me it seems technically impossible.
EDIT: Ok, maybe it is possible without implementation of each code: "When SV sees a transaction with P2SH input that has unknown op code, but valid script hash - consider input valid (check all other inputs for validity in the same way), then ignore all outputs (send to miner)." I'm not yet sure if that's exploitable as in "Case 1".
It seems very easy to protect your money from such actions when the particular consensus rule is activated on SV chain. Other implementation possibilities just seem dumb.
Let's say he implements this new rule as:
1) "Any script that has unknown OP CODE - miner takes the input"
First miner immediately takes all BCH(SV) in existence. He just broadcasts a transaction that takes all existing outputs and spend them using DSV opcode. This transaction is valid under new consensus rule (even if he has no private keys) and the miner just took all BCH(SV) money (until next block, where next miner takes it all to him, etc...)
Just plain dumb.
2) "Any unknown OP CODE fails immediately".
Doesn't work. Nobody can take the coins, incl. miners.
3) "Any unknown OP CODE is treated as PUSH FALSE"
Ok, so, I can send P2SH to this redeem script:
op_checkdatasig "known valid data" if true // on abc chain allow private key for pubKeyABC to spend it else // on sv chain allow private key for pubKeySV to spend it end 
op_checkdatasig will return true on ABC chain (since "known valid data + known signature" is ok) and "false" on SV chain.
Therefore, miners can't take it and I have safely split the coin (not that I want to, really, just thought experiment). I have the private keys for pubKeyABC and pubKeySV, the miner doesn't.
3) "Any unknown OP CODE is treated as PUSH TRUE"
Same as 2, but check for "known invalid data"/"nonsense":
op_checkdatasig "nonsense" if true // on sv chain allow private key for pubKeySV to spend it else // on abc chain allow private key for pubKeyABC to spend it end 
4) Finally, last chance: "Any unknown OP CODE is treated as NOOP, but if transaction is valid with NOOP - miner takes the input"
Easy...
op_checkdatasig "nonsense" op_depth if 3 // on sv chain fail else // on abc chain allow private key for pubKeyABC to spend it end 
So, on ABC chain op_checkdatasig would take 3 items from stack and push 1 back (FALSE, not that we care). But, on SV chain that would be a NOOP, so 3 items are still on stack. OP_DEPTH checks for number of items on stack and we split into branches.
On SV branch we unconditionally fail. SV rejects this transaction (since it fails). ABC accepts it.
So, on SV I can safely spend original output, on ABC I can safely spend from pubKeyABC.
Again, successful split, miners get nothing.
Note that "Any unknown OP CODE is treated as NOOP, but we don't care if transaction is valid with NOOP - miner takes the input" -- is the same as first case (1).
EDIT: There is one possible way that I haven't yet proven to fail. SV needs to actually implement the DSV and all other codes, but instead send the output to miner. This is exactly opposite of what Craig suggests in the article ("we implement this once and all new op codes will send money to miners", "we don't touch the protocol ever, because it's not stable money"... They would need to carefully implement each and every new code with a modification), but the jury is still out of whether it's also exploitable. (will update)
submitted by fromaratom to btc [link] [comments]

Six Hundred Microseconds.

A perspective from the Bitcoin Cash and Bitcoin Unlimited developer who discovered CVE-2018–17144.
That is about the time that Matt Corallo wanted to shave off of block validation with his pull request in 2016 to Bitcoin Core. 600µs is a lot less than what is saved with more efficient block propagation, like XThin, Compact Blocks, or now Graphene over typical links, especially those that are of similar low-end quality in network speed like Raspberry Pis are in compute speed. An optimization that was not in the focus by Core until XThin from Bitcoin Unlimited came onto the scene and kicked the Core team into gear on this issue. Furthermore, 600 microseconds is an order of magnitude or more below the variance between node validation speeds from a Raspberry Pi to a more high-end miner node and thus wholly in the range that the network already deals with. This 600 microsecond optimization now resulted in CVE-2018–17144. Certainly the most catastrophic bug in recent years, and certainly one of the most catastrophic bugs in Bitcoin ever. This bug was initially suspected to potentially cause inflation, was reported because it led to reliable crashes and confirmed by closer analysis… to be actually allowing inflation! I have consistently and repeatedly criticized hubris and arrogance in the most prominent Core developers, and done so since 2013, when the bullshitting around the 1MB block size limit started. Here we have an optimization that talks about avoiding “duplicate” validation like validation is nothing to worry about, an afterthought in Bitcoin almost. And a change that is quickly found to be good in peer reviewed, ACKed in Core-speak, in a rubber-stamp-like manner by Core developers such as Gregory Maxwell. Developers which I fully respect for their intelligence and knowledge by the way, but still, well, dislike as much for their overblown egos and underhanded discussion style as well as having done all they can to handicap Bitcoin with the 1MB limit. I also have to be honest, this change creates an unavoidable element of suspicion in me. For anyone who knows what went down and what the code paths do, it is just unavoidable to have this thought here. I like to qualify that this is not what I assert nor think is happening, but definitely crosses my mind as a potentiality! Because what is better to destroy the value of Bitcoin in the public’s eye than a silent inflation bug? What is better than creating code paths that look harmless for themselves but combined with some other, seemingly harmless rework in other areas of the code, result in utter catastrophe? And it looks like CVE-2018–17144 would eventually have become exactly this. The only thing that saved Core is their effective client diversity between revisions and someone actually noticing that there is a problem. After two years of this bug sitting around idle and exploitable. Client diversity that has been much criticized on the Bitcoin Cash side of things, but it obviously shows its advantages now. Reading the title of the original PR: “Remove duplicatable duplicate-input check from CheckTransaction” , as well as the message therein: “Benchmark results indicate this saves about 0.5–0.7ms during CheckBlock.” almost reads like it could be a sick joke being played on us all now. I always feared that someone from the bankster circles, someone injected into the Bitcoin development circles with the sole goal of wreaking unsalvageable havoc, would do exactly what happened. Injecting a silent inflation bug. Because that is what would destroy one of the very core advantages that Bitcoin has over the current status quo. That of transparency and a verifiable money supply. And, even though as a Bitcoin/BCHer, I do not see true long term prospects in Bitcoin/BTC anymore, calling the whole foundation of crypto into question just like that would have been equally disastrous to “our” variant of Bitcoin. Now, again, I am definitely not saying this is the case with PR 9049 for sure. I actually think the explanation of a young, cocky Core developer, a new “master of the universe” wreaking havoc by sheer arrogance and hubris, is the more likely explanation. People in general, but I don’t even exclude myself here, tend to believe in the competence of others if they appear just self-assured enough. This is part of the problem with attitude and psychological dynamics in this space. It creates a dangerous aura of ‘these guys know what they are doing’. I myself have done some minor work on sensitive areas in the Bitcoin Unlimited implementation. And I am working on some more “consensus critical” code for BCH now (see below). And, yes, I sometimes do lose some sleep over what could go wrong. I know I make mistakes. I have done so. I will. We all do. But I have yet to see anything resembling an admission of being imperfect by the developer in question, or any other prominent Core developer for that matter. The folks in question know exactly who I mean. There must be more reasonable folks in Core, but they are rather silent. Much worse even: In the discussion on github that follows this PR, user freetrader (a well known anonymous but still respected member of the Bitcoin Cash community who helped to create the Bitcoin Cash initial fork) asks the very valid question:
Which is answered in the, all-too-typical for Core, smug manner by Matt Corallo, notably the original author of the bug who has all reason to be a bit more careful and respectful:
The bug was disclosed in an absolutely responsible manner. As even the full disclosure on bitcoincore.org’s own pages notices, it went to a set of trustworthy people by the person who found the bug and did so in an encrypted PGP message only. This leaves the question why Core recklessly endangered the security of Bitcoin Cash as well endangering the myriad of altcoins that are out there and still susceptible with this premature and hasty publication. The back references from altcoins merging the change trickling into PR #14247 are a glimpse into this process. Now, Matt talks about “running out of time” in the above reply. But what time is that exactly? If you think hard about this, this can only be a distrust in any of the informed parties that they’ll leak this secret prematurely and thus catch Bitcoin Core with their pants down, or as a worse assumption, be actually exploited by one of the informed parties against BTC. Bitcoin Unlimited was ferociously attacked, presumably by deranged BTC supporters from the wider ‘community’, when it had a bug. And it seems a bit like Core members assumed a payback by deranged BCH supporters in kind here (I am not doubting those supporters exist), given the hints in the original disclosure that this bug has actually been discovered by someone aligned with the Bitcoin Cash side of things. But not only that, Core seems to have assumed that members on the BCH side of things who have been informed are deranged or at least irresponsible enough to leak this info to the wrong parties! I like to applaud deadalnix and the ABC team for what I was thinking the Core team should have done here as well: Bury the fix in a bit more and unrelated refactoring code so as to fix it but also to buy some more time for an upgrade. Maybe Core wasn’t creative enough to see a way to hide the problem, but then they also had no reason to blare it out like they did here. This was very irresponsible, and, and this should reach any altcoin impacted by this, this is definitely solely Bitcoin Core’s responsibility. No one else said anything in public before Core published their PR. It should also be noted by the Core team that this creates a strong disincentive to keep them in the loop with initial disclosure for anyone finding a bug. Cory Fields has talked about the risks and dangers with regards to sitting on the knowledge of a 0-day on Bitcoin Cash, and this bug discussed herein is one that was worth at least 10x more in potential damage and thus also shorting value and angry deranged people (a.k.a. “31337 crypto trading bros”) capable of violence. If a party behaves this irresponsibly, it shouldn’t be surprised if it degrades itself to a lower position in the food chain with regards to vulnerability disclosures. I am not saying I won’t inform next time I might stumble upon something, but this is not a good way to create the necessary trust. The Discovery and Disclosure Sitting in my little van by the sea on Monday, I was working on getting the new CHECKDATASIG/-VERIFY opcodes that are about to activate for Bitcoin (Cash) in November implemented on the Bitcoin Unlimited client. I have been looking at a potentially neat use case for those and am motivated to get this done. Around noon, I noticed that there is a lot of divergence in the way that signature operations counting was done in ABC vs. how it was done in Bitcoin Unlimited (BU). I agreed earlier with the BU team that I would go and port most of the CDS/-V stuff over from ABC, but I felt overwhelmed. My thoughts were that: Ok, this is doable, but this needs a lot more analysis and also many more eyeballs for review. And will take a lot longer. Sigh. While doing so, I stumbled upon this comment in the ABC code base: Check for duplicate inputs — note that this check is slow so we skip it in CheckBlock My initial reaction was a slight “Eh, WTF is going on with that comment?”. And then I looked up uses of CheckRegularTransaction in ABC, which is the renamed variant of CheckTransaction in Core (but I didn’t know at that time). I dug through the code to try to understand the logic. I noticed that block validation skips this test as it is assumed to have already happen during mempool ingress. My next thought was a bit of a sinking feeling and a “Uh-oh, I really hope the folks from ABC have thought about the difference between the mempool and block transmission and that those are distinct ways into the system. There might be a problem here!”. And then I went and thought about a way to test this. I patched an ABC node to not relay transactions even when asked and connected one unpatched and one patched node together in -regtest mode and created a transaction with a duplicate input (which the above test was skipping). Wham! assert(), Aborted. Next thought was along the lines: “Oh fuck, this doesn’t look good, gotta notify deadalnix and the crew what is lurking in ABC, this doesn’t look good at all. [email protected]#%!!”. Being aware of the danger that this could maybe be further exploited towards an actual inflation and chain-splitting bug (but I didn’t further check the specifics of this, as a node crash bug with assert() failure was already enough to be worried about), I quickly and somewhat inaccurately noted to myself (and timestamped): BitcoinABC does not check for duplicate inputs when processing a block, only when inserting a transaction into the mempool. This is dangerous as blocks can be generated with duplicate transactions and then sent through e.g. compact block missing transactions and avoid hitting the mempool, creating money out of thin air. awemany [Footnote: I timestamped this message in the BU slack, adding an innocuous situational lie of ‘Ooops, wrong channel’ to it. I also tried timestamping my findings on on my usual go-to site originstamp.org but they only submit timestamps every 24h due to the fees on Bitcoin being too high to do more often… I guess I should maybe get into the habit of doing timestamping transactions myself..] Opening up a disclosure email to deadalnix, I started to have a thought of: “Ok, actually, where is this stuff coming from, when and where did they introduce it into the code, might we be lucky and this is not in a release yet?” And then I noticed that this stuff was coming from Core. Already having written a disclosure report, I rechecked whether Core was vulnerable as well. And, once again: Wham! assert(), Aborted. I started to get shivers up my spine. Uh oh! Core has a crash bug, potentially worse. Stuff in the code since 2016. NOT good. NOT good at all. I like to say here that I actually had a feeling of this is bad, not this is good because of Core vs. Cash or something like that. I (unfortunately) still own a (for my poor soul significant) amount of BTC and for that reason and others do not like having bugs in Core either. Being a responsible citizen in this space, I then wrote the encrypted disclosure email to Wladimir, sickpig and some others, attaching a variant of the ABC and the Core patch to exploit this problem to my disclosure. I also put in a BCH address for a bounty payment to myself into that email (disclosed as proof below), as I feel this should be something worth a little performance bonus 🙂 No money has been received at the time of this writing yet. If you want to change this, you can send me BCH here: bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5 (1NBKDco2EctDXvBv6r4hqJRPWfgX9jFpqs) I chose the handle beardnboobies as this is the first thing that came into my mind when I thought about this very discovery here. I thought: Ok, I am slowly becoming a pale nerd working on just code, with beard and manboobies. Oh well. I have noticed that this handle was — for whatever reason- taken out of the release notes that are checked into the main development branch of Bitcoin Core and is only available in the release branch / tag, being replaced with anonymous contributor on the main branch. I wonder: Do you Core guys feel this is too unprofessional to have this pseudonym appear in the main branch? Have some humor please! 🙂 By the way, a plea: I urge everyone in BCH as well as BTC (as well as impacted altcoins), to take a fine-toothed comb through the code with the goal of looking for similar issues! More specifically, I faintly remember (though might be wrong) from discussions back with Core devs on reddit in 2016 and before, that the idea that there’s a lot of “duplicate validation” between mempool and block validation was kind of en vogue back then. Potentially more code is vulnerable because it assumes that mempool validation can stand in for block validation. I suspect more, though maybe not as grave bugs, in this area. Reactions After I submitted it, I felt relief and then I started to watch the space from the back. A weird situation. Only then I also fully realized what Core contributor Cory Fields described with a bit of a different angle and on a smaller scale, the weirdness of having found a bug that you know is worth millions at least, massively impacting a $100 billion currency. The fact that I could have gone and rented hash power and shorted BTC and exploited this. But also the fact that I did not! Wladimir eventually wrote me an email that they’re preparing releases (and at that time or around it they published the PR), so I responded expressing my astonishment of the quite public handling of this serious issue. What I was amazed by in general was the long time it took for the bug to blow up to its full proportions, with the process seemingly even not over now. One thing is certainly others digging into this and realizing the full severity of this — as it turns out, yes it CAN be used to double-spend and inflate on BTC after all! — but also the time it takes from the initial PR being public, seemingly not noticed at all and the first media article being written. And then I noticed the usual spin. The “stupid BCashers can’t code and are irresponsible and what not” angle that is all too often repeated then by seemingly cerebrally insufficient Core supporters. I quote the below to gloat maybe. But also to show the world WHAT kind of bullshit the Bitcoin Cash side of things is facing here in a constant barrage. This is just from a few of the more prominent Core supporters and devs. There is, of course, a lot more folks foaming “btrash, bcash” at the mouth on reddit and twitter. Tone Vays and Jimmy Song Here we have Tone Vays, who likes to pose with the undercurrent of violence by wielding weapons on Twitter and apparently also on Youtube, discussing this bug with Jimmy Song in an unwillingly hilarious Youtube video:
Luke-Jr I like to say some words about this tweet of Luke-Jr, committing the sin of bearing false witness about us irresponsible “BCashers”…
I suspect Luke-Jr has been left in the dark about the background of this disclosure as well, not belonging to the innermost circles either. Careful observers might have noticed even more of this dynamic happening with other people. And note again: I have done everything that is necessary to make this a responsible disclosure. The initial, unobfuscated public disclosure happened by Bitcoin Core on their github! This is exactly the opposite situation compared to what Luke-Jr is describing. This is despicable.
From:Luke-Jr
Closing remarks Apart from pointing out the insane spin of some Core supporters in the preceding part, I simply want to take the opportunity now to urge caution for everyone here. Bugs lurk everywhere. Everyone is imperfect. Myself included, of course. I started to like Jihan Wu’s credo of “Don’t play hatred, don’t wish competing coins ill. Just wish and try to make BCH better” (from twitter) and see BCH and BTC in fierce but still civil competition. Civil competition obviously meaning no violence, including no violence like attacking each other’s nodes. I like to reiterate that, despite the gloating and strong words you might find in this article, I did everything to play fair. I also agree in general with Cory Fields from Core that it is not very easy to find the necessary disclosure addresses and information. He’s right about the lack of easily accessible GPG keys both on the BCH as well as — I like to add- on the BTC side of things. I didn’t find a non-retracted key of Pieter Wuille in time. I also like to note that a few things went finally completely out of the window here with this bug, for example Core’s idea of ‘the code being law’. If the code is law, does that mean that you have to accept inflation now? Or is it actually the Core devs steering the ship? Is an element of reasonableness entering the space? And yes, I sincerely believe, despite the current price ratio that BCH has a much brighter future than BTC, by being fundamentalist on the principles that matter and came along with the original white paper while not being fundamental on things that were created post-hoc — like the 1MB (now 4MW) limit in the Bitcoin Core implementation. As I also don’t think extended inflation is crucial for BTC’s operation. But anyone is free to buy or sell as they want. Let’s continue competing. Let’s civilly inform each other of bugs. May the best chain win. Finally, I like to thank Andrea Suisani, Andrew Stone and Peter Rizun for their review of this article and valuable input.
submitted by Cobi-communities to u/Cobi-communities [link] [comments]

A Guide To The BCH Fork on November 15th - Be Informed! (x-post from /r/btc)

original thread:
https://np.reddit.com/btc/comments/9wthuv/a_guide_to_the_bch_fork_on_november_15th_be/
BCH November 15th Forking Guide
Intro
As you may have heard, on 15th November 2018 the Bitcoin Cash Blockchain will fork into at least two separate chains. We felt it our duty to provide information to the community on the situation that we hope will offer some clarity on this rather complex situation.
What Is A Fork?
A fork occurs when at least one group of miners decide to follow a separate set of rules from the current consensus protocol. Due to the way bitcoin is designed, these miners will then operate on a separate network from the current network. This was in fact how Bitcoin Core and Bitcoin Cash was created from the original Bitcoin. Both changed the consensus rules in different ways that made them incompatible.
To make the current situation slightly more complex, there are to be two sets of miners that are changing the protocol rules away from the current protocol. It is not expected that the currently operating consensus rules will be in operation by any significant set of miners after November 15th. This means that after November 15th there will be two new sets of competing protocol rules. For simplicity these will be described as the BitcoinABC ruleset and the BitcoinSV ruleset (although other implementations such as Bitcoin Unlimited, bcash, bchd, BitcoinXT and bitprim all also have the ABC consensus ruleset).
This is quite a unique fork situation as one side (BitcoinSV) has indicated that they will be willing to attack their competition (BitcoinABC) using reorgs and doublespends to destabilise and reduce confidence in it.
BitcoinABC Fork Details
The main new features in the BitcoinABC that make it incompatible with the current protocol are CTOR and DSV.
To summarise:
CTOR (Canonical Transaction Ordering) is a technology that allows blocks to be transmitted in a much more efficient way. This means that as blocks become larger as the network gains more adoption, the hardware and bandwidth requirements on nodes is decreased. This reduces centralisation pressures and allows us to scale the network with fewer adverse effects. You can read more about CTOR in this excellent ARTICLE by u/markblundeberg.
DSV (CheckDataSigVerify) is a technology that allows oracles directly on the Bitcoin blockchain. This means that the transactions on the Bitcoin blockchain can be dependent on actions that happen in the real world. For example you could bet on the weather tomorrow, or if a specific candidate wins an election, all directly on the blockchain. You can read more about DSV at this excellent ARTICLE by u/mengerian.
BitcoinSV Fork Details
The main new features in the BitcoinSV that make it incompatible with the current protocol are an increase in the default block size limit to 128MB, increase of the 201 opcode limit within Bitcoin’s script system to a maximum of 500 opcodes, and a new set of opcodes including; OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT.
The increase in the default block size limit will in theory allow miners on the BitcoinSV ruleset to produce and propagate blocks up to 128MB in size. It may be the case that the current state of the network cannot handle, or at least sustain, 128MB blocks but this will allow miners to decide if they want to try and produce blocks over 32MB (the current protocol limit agreed upon by miners).
Increasing the opcode limit will allow miners to make transactions using scripts of larger lengths. This means that more complex scripts can be developed.
The new opcodes allow new operations to happen within the Bitcoin scripting system.
What Are Your Options?
When the fork happens your coins will become available on both chains. This is because both chains will share the same blockchain history up until the point the fork occurs. Things are unfortunately not quite as simple as that (when are they ever in cryptoland?). Transactions that would be valid on both chains will occur on both chains. Your transactions will be considered valid on both chains as long as you do not use any of the exclusive features from either ruleset, or use inputs from transactions that are considered invalid on one of the chains. You can alternatively split your coins so that you can control them exclusively on each chain.
So what should you do? We won’t recommend what you should do with your own money, and this is not financial advice, but here are some of your options.
Do Nothing and HODL
The simplest option is to keep your Bitcoin Cash in a wallet you control and wait for things to blow over. Make sure you have the private keys and or the seed written down in at least one place to be able to recover your funds if needed. As long as you do not move your funds they will be available on both chains after the fork.
Risks - Price volatility. Like always the price can go up and down any amount. Only risk what you can afford to lose.
Sell BCH for Fiat
Another simple option is to sell your BCH for fiat. This means moving your Bitcoin Cash to an exchange such as Bitstamp.net, Kraken.com or Coinbase, and then selling them for a fiat currency. You may also consider then withdrawing your funds to your bank account for extra security (exchanges have been known to implode with everyone’s funds every now and again).
Risks - If the BCH price increase while you hold fiat your BCH holdings will be less if and when you buy back. Exchanges and banks can confiscate your money if they like (that why love Bitcoin remember). By selling you may also be liable for taxes in your jurisdiction.
Split Your Coins and HODL
If you want to be ready for anything then you can split your coins after the fork occurs. This means that you will be able to control your coins exclusively on each chain. You will still need to make sure you have your wallet(s) backed up and have the private keys and seeds written down somewhere.
To split your coins you can use a tool developed on Electron Cash HERE. This is unfortunately not a simple tool to use right now. Make sure to read the tips and advice given in that thread.
Risks - This has the same risks as simply HODLing your BCH. You should also be aware that some services have decided to refuse to use split coins during the fork. This means that if you send them split coins they will not allow you to spend them. These services include: Yours.org, moneybutton, HandCash, CentBee and CoinText.
Split Your Coins and Sell Some
If you interested in gambling on which chain will be more successful you can split your coins using the method above, and can then send coins from either chain to an exchange that allows buying and selling of specific sides of the chain. Most exchanges have decided to close deposits and withdrawals of BCH and even trading of BCH until the outcome of the forks have become more clear. After the fork occurs exchanges will likely make announcements about whether which chain they will support (potentially both), and you will then be able to trade each fork as separate cryptocurrencies.
Risks - By selling your coins on one of the chains you will no longer be invested in that side of the fork. In the case that one side of the fork ceases to exist and you are only holding coins on that side, you will have lost that money. By selling you may also be liable for taxes in your jurisdiction.
Summary
It is unfortunate that Bitcoin Cash has to go through a fork without unanimous consensus on the new protocol rules. The unique situation with this fork, in particular, has presented some interesting new issues, and it is likely that we as a community will learn a lot from it.
We hope that in similar situations in the future that the major entities in the industry, including miners, developers, businesses and community leaders can come together to find compromise that keeps the ecosystem stable and focused on adoption.
If you have further questions about this or just want to discuss the fork in general, we encourage you to join our chat at bitcoincashers.org/chat and join the conversation.
I've been interested in this fork which is happening this Friday. This fork is unique and to my knowledge the only coin to hard fork where there are two different sets of changes, not one set of changes that the miners disagree / agree on like was the case with the original bitcoin cash fork.
What are your thoughts on Bitcoin ABC and Bitcoin SV? it seems the community is quite split on this. SV proponents claim that this is sticking to Satoshi's ethos for bitcoin, it is strictly for payment, brings back some old BTC opcodes increases the potential block size to 128mb. While ABC, along with CTOR, will allow a new opcode OP_CHECKDATASIG which will permit the validation of messages from outside the blockchain. This will enable uses such as the use of oracles and cross-chain atomic contracts. This new opcode appears to be the most contentious issue surrounding ABC (are there more?)
There is quite a lot of drama around this, it will be an interesting event https://cointelegraph.com/news/bitcoin-cash-drama-battle-lines-drawn-ahead-of-scheduled-hard-fork
edit: i copied the wrong post
submitted by Neophyte- to CryptoTechnology [link] [comments]

Glad to see my intuition being right (on Ethereum)

Soon after Ethereum was announced, on January 24, 2014 I've made a comment:
But there might be a problem with resource usage... Let's say I own a lot of bitcoins and I do not want Ethereum to exist.
So I'll run multiple high-performance, clustered nodes and use them to process transactions which will consume as much resources as possible. Soon running Ethereum nodes requires 1 TB of RAM.
People say: "What the fuck? Clearly making scripts Turing-complete was a bad idea". And Ethereum is abandoned as a broken project... (Few people can afford to run full nodes, so it is as good as centralized.)
This attack might costs many millions USD, but if that helps to protect my Bitcoin investment, it makes sense.
Note that this was written before any details on Ethereum were settled, just general thoughts based on Ethereum's idea of running "Turing-complete scripts".
So it looks like this kind of a scenario is unfolding now, 2.5 years after I've written then comment:
  1. September 18, 2016: All geth nodes crash due to an out of memory bug. A specially crafted block makes geth, the most popular Ethereum node software, to request huge amounts of RAM, and thus crash. According to some reports, 85% of all Ethereum nodes are running Geth at the time. All of them were crashing, services (and wallets) which relied on them couldn't function.
  2. September 22: "Today the network was attacked by a transaction spam attack that repeatedly called the EXTCODESIZE opcode (see trace sample here), thereby creating blocks that take up to ~20-60 seconds to validate due to the ~50,000 disk fetches needed to process the transaction. The result of this was a ~2-3x reduction in the rate of block creation while the attack was taking place; there was NO consensus failure". Ethereum blocks should normally appear each ~15 seconds, but they take ~20-60 seconds to validate. Thus a normal node just couldn't keep up with blocks. Thankfully, miners got slowed down too, so there was "NO consensus failure" this time.
  3. September 25: "attacker has changed strategy ... Basically, it's now a quadratic memory complexity attack but using CALL instead of EXTCODESIZE. However because the gas limit is only 1.5m, the effect is lower, so geth nodes are just running more slowly and not crashing outright. "
jtoomim shared some details on what it's like to run an Ethereum node:
On my nodes, I'm seeing up to 16 GiB of virtual memory being used. This crashed one of my nodes twice, since it only had 8 GiB of RAM and 2 GiB of swap. I added more swap space, and that seems to have helped the crashing. I also changed the db cache size according to the blog post recommendations, and I'm now making it through the attack blocks in about 5 seconds on that machine. My other server has 16 GiB of RAM and a 4.4 GHz quad-core CPU, and it makes it through the attack blocks in about 2-3 seconds. Both have SSDs and are running Parity 1.3.
With geth, some of these blocks take up to 2 minutes to verify.
So it seems like fairly decent server-class hardware is necessary to keep up with the Ethereum blockchain now. If you run the heavily optimized Ethereum implementation, Parity.
Ethereum devs try to mitigate the issue by recommending miners to increase transaction fees (gas price) and reduce block size (gas limit). This could hurt apps/users, if there were any.
Now, this attack isn't going to kill Ethereum, of course. It's more like a warning. The cost of the attack is estimated to be on the scale of $5000 per day, so it's not some kind of largescale attempt to kill Ethereum.
I think things could be much worse if an attacker also had an access to significant amounts of mining hashpower: this would have allowed him to mine huge blocks at zero cost.
Also Ethereum node hardware requirements might grow due to demands of legitimate applications.
submitted by killerstorm to Bitcoin [link] [comments]

The second time to start again, my blockchain startup road

My PPLive/PPTV startup experience
I am a person who is very eager to pursue technology and geek spirit. I always want to do things that change the world.
In 2004, when I was still in college, suddenly one day, Bill approached me and said that there was no way to watch NBA basketball games smoothly via the Internet on campus . Can we do a real-time live video software using P2P transmission technology together? This idea was similar to the popular BitTorrent download software at that time. When I looked at this idea, I could not only solve my own needs for watching NBA, but also the most important thing is that I could not resist the temptation of technical challenges, so I quickly agreed to Bill. In this way, we started our business together and the software soon became very popular in China. PPLive was later rebranded as PPTV. Bill became the Founder and CEO of PPTV and I became the Chief Architect of PPTV and began to focus on P2P transmission technology.
The first thing PPLive achieved was real-time streaming via peer to peer transmission technology. What is real-time streaming P2P transmission technology? It is simultaneous data upload and download at the same time, which makes live streaming possible. Simply put, I am for everyone, everyone is for me.
In the beginning, I led the team to build an live broadcast platform with P2P. Because the characteristics of live broadcast are that many people will share the same data, this way we can achieve a bandwidth saving ratio of more than 99.9% when we watch the most popular content at the same time. With only 10Mb of release bandwidth, it can support up to 10 million users to watch TV at the same time.In this case, we can achieve excellent QoS(Quality of Service): the average time to start playing is 1.2 seconds; the average count of interruption is 1.6 seconds per half an hour; the whole network latest delays from broadcast source is up to 90 seconds.
After the P2P live broadcast is completed and became sophisticated, we began to develop P2P VOD(video on demand) because the demand for VOD was getting bigger and bigger. P2P VOD on-demand and P2P live broadcast are different from each other. VOD is the need to use hard disk storage and memory cache, which is more difficult than the live broadcast. Besides, it is the difference between popular content and unpopular content in the VOD system, and the P2P effect of unpopular content is not as good as the popular content. However, our P2P VOD has achieved excellent QoS(Quality of Service) too: 90% bandwidth saving ratio; the average time to start playing is 1.5 seconds; the average count of interruption is 2.2 seconds per half an hour; the average time to play when seek position is 0.9 second.
Subsequently, I led the team to port the P2P kernel to the embedded system. We streamlined the P2P transmission protocol and made a number of optimizations in terms of performance. The hard disk in embedded device read and write is not used for regular mechanical hard disk, so we have done a good amount of protection measures, which enable the P2P core to run on embedded devices. Then we quickly launched an iOS client that supports P2P, an Android mobile phone client that supports P2P, and finally an Android set-top box client that supports P2P.
Soon after, amid the growing popularity of smartphones, video creation became easier than ever Smartphone users become more enthusiastic about producing their own content, which helped video content increased dramatically. I led the team to start the cloud broadcast service, giving each user a certain amount of free storage space. On this platform users can freely upload,download, and share video content, In fact, it is very similar to network hard drives such as Google Drive. The difficulty of network hard drive with share is similar to that of VOD, but the count of videos is far more than that of VOD. The content head effect is more obvious and a large amount of content is stored in the tail. We have put a great amount of work onto the optimization of this particular area.
In 2013, PPTV was sold it to a listed Chinese company, Suning Yunshang, for US$420 million. A year later, I waved goodbye to video and P2P technology, which I had been doing for over ten years. To pursue a bigger dream, I started a new path to another startup.
My startup experience in the JDO (https://www.jidouauto.com/en)
After the success of PPTV startup, I have been pursuing new technology and geek spirit, so I did not choose video and P2P fields again, instead, I devoted myself to intelligent hardware and artificial intelligence. In 2014, I founded JDO with Cloud Wong, a company which produces cars that implement AI technology and connected to the Internet. In the past four years, I have served as CTO in JDO, and have accumulated in-depth technical experience in intelligent hardware, embedded software, artificial intelligence, and machine learning.
The automotive industry is a very closed industry. We need a long business negotiation cycle for everything we do and the product development cycle is limited by the iteration cycle of cars. In this environment of only catering to businesses, I could not entirely follow my ideas to be innovative. JDO was doing very well in the automotive field, where they have received orders from many internationally renowned car manufacturers. However, in order to pursue a bigger dream and to change the world, I decided to leave JDO.
The thought of sharing storage
Because I am doing artificial intelligence every day, I have to do a lot of neural network training and I have established cooperation and communication with many other AI companies. To do neural network training, it requires high-end NVIDIA GPU graphics cards, such graphics cards are costly, and most of the time they are idle. I was ponder: Is there a chance to build a shared GPU graphics platform, which encourages everyone to rent out unused GPU resources? Meaning when I need it, I have to pay to use other people’s unused GPU resources to calculate; when others need it, they have to pay to use my remaining GPU resources to calculate; so for startups, you don’t need to buy so many GPUs at once. The cost will be reduced and companies that use less can make money.
I took the idea of sharing a GPU graphics platform, did a simple MVP(Minimum Viable Product) to verify my thoughts and let several cooperative AI companies to use this MVP. However, I found that they have not been used. After I learned about the situation, I realized that although AI companies like lower price with sharing GPU graphics platform, they are more concerned about the security of data than price. AI company’s data collection often requires high cost to collect enough data. If they put these data on shared computers, they are afraid of being stolen data by competitors. More importantly, the neural network does not have an excellent way to split into multiple computer calculations, encrypt the data in time, and the data must be decrypted before entering the neural network, which is easy to be stolen. Technically, there is currently the no good way to decentralize the neural network model and there is no good way to send cryptographic data directly into the neural network calculation. Due to this obstacle plus other reasons, I finally gave up on this idea.
At this time, P2P storage suddenly came to my mind. I used to work on P2P video for 10 years. If you do not share the GPU, but only the hard disk and bandwidth, could this be feasible? After careful consideration, as we are entering the Internet of Things era, a large number of households have idle computers which not fully used, a large number of households purchase bandwidth on a monthly basis but not fully used, and a large number of IoT devices have storage capabilities. If these vast amounts of idle resources can be fully utilized, this will be an excellent cause for human society.
More importantly, what was done in PPTV before was that users share content voluntarily without any incentives. What is needed now is to encourage users to share by giving them incentives. That is, some users use the service to pay for the fee, and some users provide services to earn income, thus establishing a sharing storage network, just like Uber and Airbnb, passengers and rentees use the service to pay the fee, the driver and the landlord provide services to earn income.
Therefore, I came up with this sharing storage idea. The few problems that can be solved are:
  1. The cost is lower because, For miners, this is the reuse of idle resources. It is a fairly zero cost regarding cost structure.;
  2. Faster, P2P can speed up the transmission, and PPTV’s success is the best proof. After the sharing storage, because the storage nodes are everywhere on the network, the data is stored on the nearest storage node, so it can also be the fastest transmission.
  3. Decentralized storage is more private. because big companies do not necessarily guarantee privacy. Almost all big companies have exposed data leakage incidents. Today’s big companies are very dependent on big data and they might use user data for AI training. Decentralized storage is to double-encrypt data through the user’s key and developer key, then slice it into multiple segments.In this way, different segments are stored on different computers. Moreover, the sharing platform itself does not store data, which completely prevents leakage risk. Only the user’s key can open the data and the sharing operator has no way. Also, for hackers, hacking into one computer is useless, because the data is stored across many different computers This significantly increases the difficulty for hackers to steal data.
Although shared storage can solve these problems, it also brings many challenges.
  1. How to guarantee the stability of miner nodes? Some nodes will go online soon and some will go offline, just like the users of PPTV before. How to make stable products based on unstable nodes is a challenge, but it is also a thing that P2P itself must do.
  2. The quality of the miner node: For example, the hard disk of some miner nodes may be old, and it is easy to break; for another example, the bandwidth quality of some miner nodes may be terrible; for another example, some place’s power is unstable, and there are power outages frequently.
  3. Cheating on evil miner nodes: Since there are gains, some people find ways to cheat. It is the weakness of human nature and it is inevitable.
Although these problems are challenging, for me who have done 10 years of international P2P projects, I believe that these problems can be solved very well in the end, because most of the problems have been encountered before in PPTV.
However, if it’s just shared storage, even if you do the above, why do you believe that your income distribution is fair? It is the value of the blockchain.
The fate of my blockchain, starting in 2010, I was exposed to Bitcoin, a P2P currency system. As a commercial P2P practitioner, I quickly read through Bitcoin’s code: block, block hash, nonce, and mining algorithms, which are quickly understood. However, at the time I only felt the greatness of Bitcoin’s technology. In business, I didn’t understand it so deeply.
Later, Ethereum was born. In my opinion, in addition to optimizing Bitcoin’s block performance and mining algorithm, Ethereum’s most significant improvement is that Bitcoin can only execute simple instructions OPCODE into complex logic code. Virtual machine code and can program in solidity high-level language. This blockchain can be used not only for digital currencies but also for writing a variety of smart contracts that work in many scenarios.
Later, after carefully studying the technical mechanism of the open source alliance chain fabric made by IBM, I finally found the value of the blockchain itself.
From a technical point of view, blockchain is essentially a distributed and fully synchronized database. Since the chain scattered on different computers, there is a need to resolve the dispute, and the consensus algorithm is used to resolve the dispute. From a sociological perspective, the decentralization and consensus of blockchains can generate enormous social value. This value is that blockchain can build real trust. The value is that the public blockchain can build true public trust.
In the sharing storage scenario, I think it is wrong to store the stored files on the chain. The function of the blockchain for shared storage does not aim at solving data storage problems, but to solve trust problems. The data stored in the chain should be trust-related data, such as user assets, storage contracts, proofs, rewards, and penalties.
My thinking is getting clearer
With blockchain technology, an effective third-party node certification mechanism can be established to supervise the cheating problem of evil nodes through consensus; the rules of sharing distribution cannot be changed thought of one’s will, and there are fairness and transparency.
Because of fairness and transparency, everyone can safely invest resources in the platform network. Because of fairness and transparency, everyone is willing to invest in funds and build a reliable and competitive and large service center to provide services for incentives. Because of fairness and transparency, there is a truly transparent market that drives everyone to look for better and affordable resources to provide users with better and affordable services.
Because of fairness and transparency, we can build an economic model that is implemented purely by computer programs. For evil miners, they must be severely punished until the collateral is forfeited to 0. For the miners who are unstable online and the service, it must be punished according to the amount and the collateral is forfeited. Thus, such method stimulates miners to provide stable service. For miners who occasionally fail, there must be a warning penalty to motivate the service provider to provide more stable hardware. Through an effective economic mechanism, as long as the miners are stable, the entire platform service will be stabilized and QoS will be guaranteed.
What needs to be done is to: use blockchain to create a sharing storage network; use incentives to stimulate sharing; use public blockchain to ensure fair and transparent incentives. The value is: affordability, speed, and privacy. This network is easy to use and is friendly to developers. Developers can write a variety of applications in various computer languages.
Eventually, I started the project PPIO
When I was doing PPTV back in the days, Bill approached me. However, this time I approached Bill and told him that I wanted to change the world again. Therefore, Bill and l once again launched this new project with the goal to change the world,which is PPIO.
PPIO — — A decentralized data storage and delivery platform for developers
that values speed, affordability, and privacy.
Article author:Wayne Wong
If you want to reprint, please indicate the source
If you have an exchange about blockchain learning, you can contact me in the following ways:Github: https://github.com/omnigeekerTelegram: @omnigeekerTwitter: @omnigeekerMedium: https://medium.com/@omnigeekerSteemit: https://steemit.com/@omnigeeker
submitted by omnigeeker to btc [link] [comments]

Had a quick (1,5 hours) look at Counterparty github code (master branch)

I spent 1,5 hours looking at their code on the github (master branch), and also read a bit of their documentation. Here is what I found:
So all in all, I do not see why there was such a fuss about Counterparty today - nothing major happened there. And, as mentioned before, having 10 mins block time for smart contracts could be quite inconvenient, and has a potential of reducing the applicability.
submitted by ledgerwatch to ethtrader [link] [comments]

DEVCON2 report: Day Three - Final day

previous days
Question: the 3 days of devcon are over. Are people interested in reports on the next 3 days of international Blockchain week (demo day + 2 days of global Blockchain summit) http://www.blockchainweek2016.org
`
Event update
The buzz during the day was around the "stick puzzle" that Bok Khoo was giving out to people. It is just a stick, with a loop of string. He gets you to turn away, he uses "the trick" to put it onto your bag and then you try to get it off.
The WeChat channel was just filled with everyone asking where they can get it, and the screaming that they can't figure it out. Only about 5 people reported they were able to solve it (I haven't yet)
http://imgur.com/mYfJQP4 http://imgur.com/4Euka1a
`
Sessions
I'm biased, but I thought the announcement from Microsoft with the update of cryptlets was a big deal. The morning sessions covered a few different oracle systems, the afternoon had lots of IPFS sessions.
Microsoft - A Lap around Cryptlets
https://azure.microsoft.com/en-us/blog/cryptletsdd/ https://azure.microsoft.com/en-us/documentation/templates/ethereum-consortium-blockchain-network/ https://azure.microsoft.com/en-us/blog/authomarleyg
Microsoft was a sponsor of Devcon1 & 2 Ethereum is a 1st class citizen Support for community & partners - Bizspark, Meetups, Workshops
Announcing: Bletchley v1 Distributed Ledger stack V1 is a private Ethrerum consortium, that you can spin up for your own enterprise / group
http://imgur.com/olwwd36
Cryptlets are being developed to help with security, identity, etc. How do you get trusted external data feeds injected into the Blockchain? Doing things on a specific interval (every 15 mins) When price of something hits a threshold (oil goes above $40/barrel) Secure IP protected algorithms, but still share with blockchain network. Use libraries for common platforms (.Net, Java, etc)
Cryptlets vs Oracle Cryptlets will have a marketplace on Azure that will allow you to purchase and utilise
Use case: Trigger on an event Wake up on 4pm, if market was open that day, then give me the price of gold for that day.Get signature of attested server, attested sender.
Use case: Control Using smart contract like a traditional DB. Declare data you are keeping track of, and the functions/"stored proc" to update that data. Cryptlet runs off chain, and can be scaled up.
http://imgur.com/ysgL8S2
Utility cryptlet. Use an attribute in solidity contract with cryptlet details Developer references at design time the cryptlet they want the contract to call Contract cryptlet, deploy the cryptlet at same time as contract.
Why would you want Azure to do this? SGX allows you to create "secure enclaves", can have complete isolation on the hardware chip where it is not modifable. Provides a secure enclave at the CPU level. Can give full attestation right down to the silicon. Will be provided as a enclave container on Azure. Will be released for .NET core CLR first, then other languages. Can create cryptlet libraries that you can scale and put into the Azure marketplace. An ecosystem for developers & ISVs to consume and publish.
Bletchley v1 released today will let you spin up a private consortium. Before today, it took a long time to try and deploy a private consortium (can take weeks to read doco, Now takes 5 minutes to deploy! Creates a private consortium, puts each member in its own separate subnet
http://imgur.com/w4yUsqE
Mist Vision and Demo I was too busy sharing the release posts of Microsoft project bletchey v1, missed this talk. It did look interesting, I will watch this one later. Idea: Reward for bandwidth. Providing connection could replace mining as entrance point for desktop computers. Allow you to have a trickle so you can trigger smart contracts. Standardised backends, so that you can swap out the underlying node between geth, blockapps, etc.
Web3.js
https://github.com/ethereum/web3.js Etehereum JS API Smart conracts are EVM opcodes, Helps translates calls to JSON RPC calls. Helps do the ABI encoding when sending data from JS to EVM It kept on growing, many different utility functions being thrown in. Is time to clean it up and be refactored.
They are now building a NEW web3.js The communication will be socket based, will enable subscriptions. Everything will be based on promises to subscribe to events, like log events. Bunch of other newer cleaner methods and ways to do things like deploying contracts.
Smart contract security
Was a very good postmorteum of The DAO and things that could be done to mitigate it in the future.
An issue with The DAO was trying to do a massive jump from centralisation all the way to full decentralisation. Meant no one could step up and make a decision on how to save it. We need to make smaller steps towards full decentralisation as we learn as a community how to do this. Same security patterns as yesterday's talks: check invarients, beware 1024 call stack depth, reentry exploit (update state BEFORE executing calls), timestamps are manipulatable. Updateable contracts. Who can update it? Community multisig? We need better rools: formal verification, compiler warnings, improved IDEs, trusted libraries, excape hatches
Conclusion: It is still very early days in this space, be careful.
A Provably Honest Oracle Model: Auditable Offchain Data Gathering & Computations
Oracalize is the most widely used oracle (until everyone starts using Microsoft Azure cryptlets ;-) ) Contract calls Oracalize contract with the data they want, off chain they see this get the data, Oracalise then trigger their contract externally, which does a callback to your contract with the data. Can use external notary servers. Can get proof from multiple external services to get a higher level of confidence about data (e.g. stock price from a few feeds). Off-chain (auditable_ computation) AWS sandbox 2.0. Put the execution package onto IPFS, AWS gets it and executes it, signs it.
iEx.ec: Fully Distributed Cloud Thanks to the Ethereum Blockchain
http://iex.ec/ Provides blockchain based execution environments Global market for computing resources. Idea is to do what we did before with "grid computing" use the idle capacity of computers. But this time do a trickle of micropayments. Allows people to harness this global power to execute their tasks in a global "distributed cloud".
The Final frontier: The company smart conract
http://otonomos.com/ Helping companies to incorporate on the blockchain.
Smart oracles
https://github.com/smartoracles Connecting to external resources is difficult. Hard to try and use external currencies (like a bank account / fiat money) to make transactions. Could hook in paypal, HSBC, wells fargo, etc. Can provide your own payment services as an API to a smart oracle for smart contracts to consume. Do off chain data storage by calling smart oracle API Roadmap: more data sources & more payment methods
IPFS & Ethereum: Updates
https://Ipfs.io IPFS is AMAZING, seriously go watch the full 1 hour talks Juan has given in previous years.
Current web has current issues. Centralisation, etc. IPFS is a new hypermedia transfer protocol Content can be retrieved not from specific servers, but instead via it's hash so that it can come from anywhere in the network (maybe from the person next to you who has cached it). It is highly modular, all of the transfer protocals, routing, naming, etc. are all swapable Is available as GO-IPFS & now JS-IPFS Means now you can run IPFS in the browser IPFS was great for static content, but not so great for dynamic content. Low latency pub/sub protocol will help with dynamic data. Created a distributed peer to peer chat app using this new dynamic content protocol. IPLD a common link-tree hash format Will be able to use IPFS to retrieve ethereum blockchain blocks DIRECTLY Can use IPFS as a package manager to retrieve them in a distributed manner.
Many projects are using Ethereum & IPFS Uport, Digix, Infura, Ujo, Eris, Blockfreight. Filecoin was created as a way to try and incentivize nodes to keep files longer time. People rent out hdd space to earn filecoin. Exchange bitcoin/filecoin. Use filecoin to store files in network. Filecoin is going to be built on top of the public Ethereum blockchain, as a virtual blockchain / token.
IPFS Libp2p & Ethereum networking
Network connectivity between any 2 nodes can be difficult. Censorship, bandwidth, network issues, etc. Having to deal with different networking topologies and access. Libp2p & Devp2p is different. Devp2p is for Ethereum. LIbp2p is modular, can swap out components to change network access, encryption methods, etc. Can build up a MEGA mesh network, by utilising traditional wired internet, radio, bluetooth between some nodes. Web browser using web socket, to a node, which routes across network, to zigbee to a IoT device. Libp2p & Devp2p could merge and augment each other. Could create the libp2p components to replace the devp2p bits Any 2 nodes that speak the same protocol can communicate and be a part of the network chain. Experiment. They took the browser based version of EVM. Then used Libp2p to talk to the Ethereum network. Had a complete ethereum node running in a browser.
Uport
https://uport.me/ Universal identity platform Current challenges: key management. Ux for average person. Dapps via mobile. Identity and data ownership. How do you keep a consistent identity, even if you lose a key. Have some multisig contracts that you can use to keep track. Social recovery, use your friends to attest it is really you. Keep private key on mobile, do transactions on the desktop, scan a QR code to sign the transaction on your phone and send it off.
A Deep Dive into the Colony Foundation Protocol
It is an open source governance protocol built on Ethereum Problem with voting is how to prevent Sybil attacks. Votes are weighted by a reputation score. Reputation is non-transferable that can only be earned. Total weighted voting helps mitigate this.
Chain orchestration tooling & smart contract package management
Eris is tooling for developers. Package manager to build your own blockchain. Can compose a chain, e.g. geth + tendermint consensus. Init, install, do. Can easily install on Mac/bew, linux/apt-get, Windows/choco
The Golem Project: Ethereum-based market for computing power
http://www.golemproject.net/ Anyone can make an offer to sell computing power. e.g. Distributed rendering Want to create a standard framework that anyone can use to submit and process jobs.
Status: Integrating Ethereum Into Our Daily Lives
https://status.im Want to get ethereum everywhere. "Mist for Mobile" Everyone is using their mobile phones for everything, but mostly using instant messaging. What would Ethereum in a IM window look? Created a IM mobile app that has a local geth node. tart up, it asks you to create a password, it generates a pub/private pair. Then can send messages via whisper, and the messages are signed with your public key. Can load Dapps up in the local webview and interact with them. Allows you to create "chat Dapps", that you interact with via text. Like chatbots
Maker Ecosystem Overview
www.Makerdao.com Dai: seeking stability on blockchain. Stablecoin engine: smart contract that holds collateral reserves and controls the Dai lifecycle. MKR: open source community managing risk of the system In the last year, investing in a solid technical core. More slow and audit things. Moving into the next phase of stablecoin development. Their latest project is the "Simplecoin project" Meeting Thereum community's need for stability. An independent platform for creating centrally administered simple stablecoins. Issues create their own rule sets: Collateral types, participant whitelists, security parameters. Example: Shrutebucks. The only people who own it are Dwight, Jim & Pam. They backed it with 1/3 ETH 1/3 DGX 1/3 DUSD.
Orbit. A distributed peer to peer app on IPFS
https://github.com/haadcode Created a full distributed chat room, itself distributed through IPFS. It is integrated with uPort for identification Using uPort allows you to verify that you are talking to the correct person in the chat channel. All their messages are signed with their public keys He also created a full distribited twitter clone, using uport for the identity as well. Orbit-db key value store DB that stores its data on IPFS. Eventually consistent Appends data to the DB, an event is sent to those subscribed on pub/sub so they can see the latest root hash. Based on CRDT Ethereum + Pubsub + CRDTs + IPFS = super power primatives to build dynamic distributed apps
Development considerations with distributed apps. Need to ensure that apps work offline. No centralised servers. No data silos. Provide integration path.
Future work: could you use uPort for ACL like permissions? Mobile use cases, how to make it work nicely on mobiles
Building scalable React Dapp architecture
https://github.com/SilentCicero/react-dapp-boilerplate React + Ethereum He has a configured boilerplate template. Has contract scaffolding. Enforced contract Linting/testing. Wallet generation/identity. Preconfigured web3 instance. UI: Mature react arhitecture "react boilerplate". Prices listed in USD with ETH/btc via kraken api. A basic multi-contract example Dapp. Offline first, dapp runs without internet. Uses Redux. State models in UI & blockchains work well. PostCSS, CSS Modules, sanitize.cs. Redux, immutableJS, reslect, redux-saga, i18n, redux-router. Web3, ethdeploy, dapple, solium, eth-lightwallet, chaithereum, ethereumjs0-testrpc Enforced contract testing in 2 languages.
Ethereum for Enterprise (BlockApps Strato)
Trying to make sure that Ethereum stays relevent to enterprise development. Why do you need a blockchain WITHIN an org, shouldn't they trust each other? Well different departments may not, they may reconcile differently, and can help automate/orchestrate between them. Blockchain is the "killer app" for cloud financial services. Legacy infrastructure, batch prossing, etc are all restricting fintech from progressing. Blockchain can happen in real time, can replace legacy. Ethereum is very flexible and programmable, works well. There are others based on Bitcoin (like Hyperledger). Ethereum + Blockapps = Extreme productivity + Proven Technology. Blockapps is extending Ethereum for Enterprise. Runs very well on Azure Enterprises don't want all their data exposed on public chain. Blockapps helps solve data privacy and scaling with multichain fabrics.
submitted by DavidBurela to ethereum [link] [comments]

Deep Analysis Of Qtum's Account Abstraction Layer (Qtum AAL)

Analysis of Qtum Account Abstraction Layer (AAL) Implementation
https://mp.weixin.qq.com/s?__biz=MzI2MzM2NDQ2NA==&mid=2247485993&idx=1&sn=57ad353fd13b10ab85b62d693f86b1f5&chksm=eabc4036ddcbc9208ea766274defc543a9238967c5d2c541e615906a25a2962d75c4c6bd2c2b&scene=21#wechat_redirect
Qtum is designed with a bitcoin UTXO-based account model and implements a smart contract that supports the EVM specification, which is done through the Account Abstract Layer (ALA). AAL adapts the UTXO account to the EVM contract account, so that the AAL can use the UTXO transaction output to create a smart contract on the chain, send the transaction to the contract account to trigger the execution of the contract, and the AAL will eventually execute after the execution. The results were processed and adapted to UTXO. Thanks to the AAL, contract developers don't need to care about the UTXO transformation details related to contract operations, they can use the features of EVM to develop and are compatible with existing Ethereum smart contracts. This paper first analyzes the working process of AAL by interpreting the implementation code from UTXO transaction to smart contract execution.
 
1. UTMO transaction added script opcode
Qtum has added three opcodes OP_CREATE, OP_CALL and OP_SPEND for UTXO trading scripts to provide operational support for conversion between UTXO and EVM account models. These opcodes are defined in the opcodetype enumeration type:
 
Enum opcodetype{
......
OP_CREATE = 0xc1,
OP_CALL = 0xc2,
OP_SPEND= 0xc3,
......
}
 
These three opcodes have the following effects:
OP_CREATE is used to create smart contracts;
OP_CALL is used for the execution of the contract;
OP_SPEND is used for the cost of the contract balance.
In order to identify and process the transactions controlled by these opcodes during the block generation process, the HasCreateOrCall() and HasOpSpend() functions are added to the class CTransaction for UTXO model transactions for use in the mempool in the new block. The transaction is processed and the corresponding processing is added to the EvalScript() function of the script opcode parsing.
 
2. Conversion of UTXO transactions to EVM model transactions
When generating new blocks, in addition to regular parameter legality, consensus rules, DDOS attack checks, etc. for UTXO transactions, it is also necessary to use the opcode check function HasCreateOrCall() to determine whether the transaction output contains OP_CREATE or OP_CALL, which respectively correspond to EVM needs to perform contract creation or contract calls. This section has the following processing:
 
2.1 Performing account parameter extraction for EVM model
The contract uses the data, gasPrice, gasLimit, and VM version parameters in the execution of the EVM. These parameters are sent by the RPC call sendtocontract. The sendtocontract generates a UTXO transaction and uses the OP_CALL opcode in the transaction output. Will be broadcast to the blockchain network. The adaptation from UTXO to EVM in AAL is implemented by the QtumTxConverter class, in which the member functions extractQtumTransactions() and parseEthTXParams() of the class complete the parameter extraction for all such UTXO transaction output. The code fragment is as follows:
 
Dev::Address receiveAddress;
Valtype vecAddr;
If (opcode == OP_CALL)
{
vecAddr = stack.back();
Stack.pop_back();
receiveAddress = dev::Address(vecAddr);
}
Valtype code(stack.back());
Stack.pop_back();
Uint64_t gasPrice = CScriptNum::vch_to_uint64(stack.back());
Stack.pop_back();
Uint64_t gasLimit = CScriptNum::vch_to_uint64(stack.back());
Stack.pop_back();
VersionVM version(CScriptNum::vch_to_uint64(stack.back()));
Stack.pop_back();
Return EthTransactionParams{version, dev::u256(gasLimit), dev::u256(gasPrice), code,
receiveAddress }
 
The above code first judges that if the opcode is OP_CALL, the contract with the address vecAddr has been created, so it is directly converted into the address of the EVM format receiveAddress, otherwise it is OP_CREATE, the corresponding contract is created, there is no such field, so no extraction is done. Next, the data, gasPrice, gasLimit, and VM version are extracted in turn, which are all essential parameters for the EVM to execute bytecode.
 
2.2 Transaction conversion of the EVM account model
Transaction conversion is done through the function createEthTX() of the QtumTxConverter class. The QtumTransaction type transaction is created using the parameters extracted in the previous step and the UTXO transaction output vout. Since QtumTransaction is derived from the dev::eth::Transaction class in EVM, the QtumTransaction class is supported by operations related to EVM execution.
 
QtumTransaction txEth;
If ( etp.receiveAddress == dev::Address() ) {
txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *
Etp.gasPrice),
Etp.code, dev::u256(0));
}
Else{
txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *
Etp.gasPrice),
etp.receiveAddress, etp.code, dev::u256(0));
}
Dev::Address sender(GetSenderAddress(txBit, view));
txEth.forceSender(sender);
txEth.setHashWith(uintToh256(txBit.GetHash()));
txEth.setNVout(nOut);
 
First, the code etp.receiveAddress == dev::Address() determines whether the contract is not in the EVM state and needs to be newly created or the contract already included in the EVM state. The only difference is the contract address. Then, the QtumTransaction() constructor completes some of the transaction parameter constructs, the next statement extracts the sender of the transaction, and then sets the transaction HASH. A UTXO transaction supports multiple inputs and outputs. Qtum's AAL design takes this into account, so AAL supports a transaction output containing UTXO accounts and contract accounts. The last set nOut indicates that the nOut output of the transaction is sent to the smart contract. , so this output will trigger contract execution. In this way, the transaction conversion is completed according to the EVM account model.
 
3. Contract execution and UTXO conversion of execution results
The execution of the contract changes state (managed by the QtumState class's instantiated object globalState). For the contract state, Qtum follows the EVM definition, so it is compatible with all EVM-compliant smart contracts. But the transfer of the account amount, Qtum made a UTXO conversion, which means that the smart contract and the ordinary UTXO model account can complete the interaction, which is an important part of AAL to achieve UTXO support smart contract. The following is a brief introduction to the conversion process of contract execution and status results.
 
3.1 Contract execution environment construction and contract execution
The execution of the contract is a critical step in the processing of the contract, directly affecting the state of the contract. The implementation of the EVM to the contract bytecode is implemented by the ByteCodeExec class. The main function is performByteCode(). The main process of this step is to use the transaction parameters extracted above to build the virtual machine execution environment, and then complete the execution of the contract, the code is as follows:
 
For(QtumTransaction& tx : txs){
Dev::eth::EnvInfo envInfo(BuildEVMEnvironment());
Std::unique_ptr
Se(dev::eth::ChainParams(dev::eth::genesisInfo(dev::eth::Network::HomesteadTest)).
createSealEngine());
If(!tx.isCreation() && !globalState->addressInUse(tx.receiveAddress())){
Dev::eth::ExecutionResult execRes;
execRes.excepted = dev::eth::TransactionException::Unknown;
Result.push_back(ResultExecute{execRes, dev::eth::TransactionReceipt(dev::h256(),
Dev::u256(), dev::eth::LogEntries()), CTransaction()});
Continue;
}
Result.push_back(globalState->execute(envInfo, *se.get(), tx, type, OnOpFunc()));
}
 
The first is to build a contract execution environment, which is done by BuildEVMEnvironment(). It can be seen that this execution environment is carried out for each independent transaction, so as to minimize the contract execution process of different transactions and avoid the cross-effects in the contract execution process. Then build a new sealEngine class, which is the EVM execution engine, which is done by the createSealEngine() function. In the middle, the possible state exceptions that occur are checked, and then globalState->execute() completes the execution of the contract. Here, the execution environment envInfo and the EVM execution engine se are used.
 
3.2 UTXO conversion of contract execution results
After the completion of the contract execution, the result is stored in vector result. The vector vector records the transfer relationship between EVM accounts generated by each contract execution. AAL completes the transfer from EVM account model to UTXO model by converting these transfers into UTXO transactions. Conversion of the transaction. This processing is implemented by the processingResults() function. The following is a code snippet.
 
ByteCodeExecResult resultBCE;
For(size_t i = 0; i < result.size(); i++){
If(result[i].execRes.excepted != dev::eth::TransactionException::None){
If(txs[i].value() > 0){
CMutableTransaction tx;
Tx.vin.push_back(CTxIn(h256Touint(txs[i].getHashWith()), txs[i].getNVout(), CScript() <<
OP_SPEND));
CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<
OP_EQUALVERIFY << OP_CHECKSIG);
Tx.vout.push_back(CTxOut(CAmount(txs[i].value()), script));
resultBCE.valueTransfers.push_back(CTransaction(tx));
}
} else {
resultBCE.usedFee += CAmount(result[i].execRes.gasUsed);
CAmount ref((txs[i].gas() - result[i].execRes.gasUsed) * txs[i].gasPrice());
If(ref > 0){
CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<
OP_EQUALVERIFY << OP_CHECKSIG);
resultBCE.refundOutputs.push_back(CTxOut(ref, script));
resultBCE.refundSender += ref;
}
} if(result[i].tx != CTransaction()){
resultBCE.valueTransfers.push_back(result[i].tx);
}}
 
First, the resultBCE variable of type ByteCodeExecResult is defined to save the result of the conversion. Use the opcode OP_SPEND to implement the transaction cost, because the UTXO of Bitcoin uses the private key signature to realize the balance after the transaction input is unlocked, and the EVM implementation involves the transfer between different accounts, so these need to be implemented by OP_SPEND Transfer to UTXO model trading conversion. If execRes.excepted is not None, ie the contract execution exception, the balance is returned to the contract caller. Otherwise, if there is no abnormality, the remaining gas after deducting the consumed gas is returned to the caller of the contract. For the transfer that occurs during contract execution, its UTXO transaction is stored in result[i].tx. Therefore, transactions between different UTXO accounts generated by this process of contract execution are stored in the valueTransfers vector, and eventually these transactions are included in the new block. At this point, the AAL module completes the conversion from EVM transactions to UTXO.
 
4. Summary
AAL assists in the creation, execution, and cost of contracts through the addition of UTXO script opcodes. Before the contract is created and executed, the conversion of the UTXO transaction to the EVM model transaction is required, and then the executed EVM execution environment and engine are used to complete the execution of the contract. AAL finally processed the results of the contract and adapted it from EVM to UTXO, thus implementing a UTXO-based smart contract. AAL makes Qtum compatible with EVM-compliant smart contracts, providing Dapp with a new base platform, while UTXO's advantages allow for advantages such as parallel processing and privacy.
 
Huaming
He is currently a Qtum core developer and researcher. He graduated from Huazhong University of Science and Technology and has a graduate degree from the Chinese Academy of Sciences. Prior to joining Qtum, he has been engaged in the development of algorithms and protocol stacks for many years of wireless networks (including 4G LTE and wireless ad hoc networks); since 2015, he has been in contact with blockchain technology and has participated in the first hackathon competition organized by Wanxiang Blockchain. .
submitted by thisthingismud to Qtum [link] [comments]

Bitcoin Explained: Why The Bitcoin Price MATTERS - YouTube BITCOIN PRICE ***what is happening in the crypto space ... Bitcoin Price Today - YouTube Bitcoin වල Price අහස උසට නැගීමට නියමීතයි - YouTube Building on Bitcoin - Working with scripts with logical opcodes

Back in 2018, several opcodes that are disabled in Bitcoin were re-enabled on the Bitcoin Cash chain, while some entirely new ones were also added. This difference gives Bitcoin Cash enhanced smart contract functionality over Bitcoin. Bitcoin Cash can also be considered more centralized than Bitcoin. Right now, a single pool controls more than a quarter of the Bitcoin Cash hash rate, whereas ... However, since Bitcoin is decentralized, the community may not always agree on some upgrades, and sometimes they decide to part ways, making one blockchain being split into two, and both continue to be used by the opposing camps of the community. Such an event is called a hard fork. Further Reading: Bitcoin Price 2017 vs Bitcoin 2019 Prediction Bitcoin SV was created with an even larger block size, 128MB, all while restoring 4 original opcodes (OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT) which were actually taken out of the original codebase. For those who don’t know, an opcode or operational code is simply an instruction that specifies a rule or function to be performed and can be used in low-level protocols like Bitcoin, which are ... Bitcoin Cash forked from Bitcoin at block 478559 since it breaks out of Bitcoin's consensus rules, making transactions are incompatible. Bitcoin Cash shares Bitcoin's genesis block and entire blockchain history up to block 478559. Bitcoin Cash's fork initially increased block sizes from 1 MB to 8 MB and later to 32 MB. To date, Bitcoin Cash has 6 competing node implementations: BitcoinABC ... The Bitcoin ABC project, which operates the main client of Bitcoin Cash, has laid out a rodmap for two hardforks, one this summer and another during autumn. Neither has been finalized, but some of the potential improvements include a change of the block size consensus rule towards an adaptive blocksize limit. That suggests the network […]

[index] [13038] [11653] [11114] [36077] [14712] [50130] [37783] [33792] [31754] [18504]

Bitcoin Explained: Why The Bitcoin Price MATTERS - YouTube

I’m going to ask what many people may consider to be the dumbest question ever. Why is the Bitcoin price important? Before you ridicule me and call me the la... #Btc #price #pump #news BTC (බිට් coin ) මිලදී ගැනීම සදහා . මෙය ඔබේ දහස මිලියනය කරන අවසත්වයි https ... For more details: MyFinanceTeacher.org FB: https://www.facebook.com/groups/328846917550793 Twitter: [at] MyFinanceTeache Bitcoin price increased a lot in the... Bitcoin price has been reaching closer to all time highs. In this video we discuss current events as well as where the price of bitcoin and ethereum may go b... Bitcoin Cash Development video meeting January 3 2018 - 8am UTC Participants: Amaury Séchet, Andrea Suisani, Antony Zegers, Jason B. Cox, Chris Pacia, Emil Oldenberg, Mark Lundeberg, Host: David ...

#