Transaction - Bitcoin Wiki

Does RPC gettransaction work with pruning activated? /r/Bitcoin

Does RPC gettransaction work with pruning activated? /Bitcoin submitted by cryptoanalyticabot to cryptoall [link] [comments]

Does RPC gettransaction work with pruning activated? /r/Bitcoin

Does RPC gettransaction work with pruning activated? /Bitcoin submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

Gridcoin "Fern" Release
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.



Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.


Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.


The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog



Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.







As a reminder:









Detailed Changelog

[] 2020-09-03, mandatory, "Fern"





submitted by jamescowens to gridcoin [link] [comments]

Connecting Eclair to Bitcoin Core | Code: -5 error

I am having trouble getting eclair to connect to my full node.
im running eclair 0.3.4 and bitcoin core 0.19.1 (i was running 0.19.01 but updated when i saw the "Current number of transactions" said N/A in the information window)
I launch eclair-node-gui while bitcoin core is running (core is synced and has been running for an hour so mempool will be filled)
Core says transactions are about 6k and memory usage is ~12MB
However, I get error code: -5 on eclair:
Error: NO such mempool transaction. Blockchain transactions are still in the process of being indexed. Use gettransaction for wallet transactions.
I have txindex=1 in the conf of core. ( can show my configs if it helps, i got them right from the gethub)
I entered gettransaction into the core Console but im not sure if it really does anything
Im not a coder by any means, so bear with me. Also when i updated Bitcoin Core from 0.19.01 to 0.19.1, i ran the setup exe downloaded from and it recognized and is using the blocks destination folder that 0.19.01 was running off of, if that makes a difference.
I also posted this in lightningnetwork
submitted by wumbis to Bitcoin [link] [comments]

#Reddcoin ($RDD) Core Wallet Release 3.0.1 - PosV v2 SuperMajority Consensus Upgrade at 45.6% - Required Upgrade

Reddcoin (RDD) Core Wallet v3.0.1 - January 09, 2020
Version 3.0.1 is the official release version of Reddcoin Core. It is available for download at Reddcoin Core's Github repository here:
This release features PoSV v2.supermajority activation and new staking ruleset (and minor misc fixes). v3.0.1 is still not yet MacOS Catalina compatible. We are still working and should have that fix issued very soon. Sincere apologies to our Mac-using ReddHeads.
It is particularly important that all users upgrade, as once PoSV v2 is enforced, version 4 blocks will be rejected from the network entirely.
Therefore v3.0.1 is a "strongly recommended" update for all users. Note: If you have already installed v3.0.0, this upgrade is not required. If you have not yet upgraded from v2.0.x or earlier, this is a REQUIRED upgrade. Please install the newest version v3.0.1 to avoid losing functionality during supermajority activation of PoSV v2.
Reddcoin Core version 3.0.1 is now available from: Release Notes are available here and replicated below in this announcement:
This is a new major version release of Reddcoin.
Previously, the original and subsequent versions of Reddcoin were taken from a fork of the Litecoin code base.
With the release of Reddcoin V2.0.0, the code was based directly from a fork of Bitcoin. This allows for better source control and feature implementation from upstream changes into the future
With the release of Reddcoin V3.0.0, the PoSV stake reward has been improved to allow for a target 5% network growth, in process re-incentivizing individual network stakers and providing for integrated dev support.
Upgrading to this release is strongly recommended and required for continued operation. Once a supermajority of 90% is reached, old wallets will no longer accept the new v5 blocks.
Please report bugs using the issue tracker at github:
How to Upgrade
If you are running an older version of Reddcoin, shut it down. Wait until it has completely shut down (which may take a few minutes for older versions). Run the installer (on Windows) or just copy over /Applications/Reddcoin-Qt (on Mac) or reddcoind/reddcoin-qt (on Linux).
Start wallet. All done!
Reddcoin v3.0.0 introduced an updated PoSV method to better distribute staking rewards and target a overall 5% network growth. Staking and relay policy enhancements 
To implement PoSV v2, Reddcoin Core's block templates are now for version 5 blocks only. When PoSV v2 consensus (Supermajority 9000/10000) is reached, only v5 blocks will be accepted by the network.This equates to approximately 90% of blocks being generated over 1 week period. Status at any time may be viewed in node debug.log
Blockchain Download:
Blockchain data for both testnet and mainnet along with instructions can be downloaded from github.
3.0.1 changelog
*83e212838 - John Nash, 2020-01-09 : really delete these files *3a1458ecd - Oliver Webb, 2020-01-08 : Added missing dependency libminiupnpc-dev for Jessie *d21915431 - Tiago Peralta, 2019-06-21 : Add vout to listtransactions/gettransaction *8d58ea7cf - Oliver Webb, 2020-01-08 : Script for downloading pre compiled binaries for Raspbian Jessie, Stretch or Buster *d4eced1bc - Oliver Webb, 2020-01-08 : Delete *c5e9f91cf - Oliver Webb, 2020-01-08 : Delete *5d5771b00 - Oliver Webb, 2020-01-08 : Delete *75c6ae91b - Oliver Webb, 2020-01-05 : add reddcoin-qt and remove starting daemon process *54c501787 - Oliver Webb, 2020-01-05 : add reddcoin-qt and remove starting daemon process *acb30a2b6 - Oliver Webb, 2020-01-05 : script files for Raspbian Jessie (also Stakebox) *cfddbe594 - John Nash, 2020-01-05 : Update copyright year and version *e46e5e7de - John Nash, 2020-01-05 : download script for pre compiled wallet *37386790a - John Nash, 2020-01-05 : change libssl deb packages links to github *9dbc772e6 - Oliver Webb, 2020-01-03 : download script for pre compiled wallet *857d697fd - Oliver Webb, 2020-01-03 : change libssl deb packages links to github *2cb74b9a8 - John Nash, 2019-12-31 : update copyright year *c641a1ab3 - Oliver Webb, 2019-12-30 : Raspberry Pi build script files for v3 wallet *a3f21a4a4 - John Nash, 2019-12-30 : add install script for building db4 update instructions for unix, osx, arm building using the db4 install script *5f6299b2a - John Nash, 2019-12-28 : docs: Update build notes for arm processors *465716c01 - John Nash, 2019-12-28 : test for arm devices *3fec3a535 - John Nash, 2018-02-02 : build: update source paths *5f6031ab4 - John Nash, 2019-12-28 : Scrypt n=1024 Pow hash based upon Colin Percival's Tarnsnap (2009) Modified by Artforz, coblee, pooler, wtogami, Nikolay Belikov, reddink *2fd4d91a0 - John Nash, 2019-12-24 : update copyright year *326828b36 - John Nash, 2019-12-24 : set release state true *8ebede0a6 - John Nash, 2019-12-24 : release notes *36df6fdfb - John Nash, 2019-12-23 : add check explictly for v5 blocks or greater *874dc1f0c - John Nash, 2019-12-17 : remove hardcoded global variable rearrange debug log output *763b25db8 - John Nash, 2019-12-17 : move copyright to new line *536baf635 - John Nash, 2019-12-17 : update version and set release state to false *cde9009f3 - John Nash, 2019-12-17 : update copyright year *ae41b7ed3 - John Nash, 2019-12-17 : set isSuperMajority to 90% for mainnet *e43e1c8ed - John Nash, 2019-12-10 : additional logging to verify isSuperMajority in the debug.log output *e31783cac - John Nash, 2019-12-05 : add/update public key for mainnet *405c6f002 - John Nash, 2019-12-05 : add log output for current inflation rate *9cc43c3f7 - John Nash, 2019-12-02 : determine calculated stake based on posv version *7baa3bf75 - John Nash, 2019-11-25 : check the posv transaction for correct pubkey *9ffa7ca38 - John Nash, 2019-11-21 : check for posv v1 or posv v2 blocks when calculating stake reward *39f7aad68 - John Nash, 2019-11-14 : add logging *0e283e6c3 - John Nash, 2019-11-13 : correct maths *74cbdeffd - John Nash, 2019-11-11 : use new posv v2 functions addidtional logging *35d7413b5 - John Nash, 2019-11-11 : add new proofofstakereward *3d917216c - John Nash, 2019-11-11 : get inflation adjustment *f63d17443 - John Nash, 2019-11-08 : add the developer output split fund output *ca263c9c9 - John Nash, 2019-11-05 : add dev key to chainparams *df6996ab0 - John Nash, 2019-11-05 : add block version checking *14b663479 - John Nash, 2019-11-05 : increase block version
Thanks to everyone who contributed to coding, testing and feedback for this release, notably:
@cryptognasher @techadept @chris @cryptobuze @harmonyq @mindredder @paxtech @Tiago Peralta 
Stake on!!
-Reddcoin (RDD) Core Development Team
submitted by TechAdept to reddCoin [link] [comments]

Connecting Eclair to Bitcoin Core | Code: -5 error

I am having trouble getting eclair to connect to my full node.
im running eclair 0.3.4 and bitcoin core 0.19.1 (i was running 0.19.01 but updated when i saw the "Current number of transactions" said N/A in the information window)
I launch eclair-node-gui while bitcoin core is running (core is synced and has been running for an hour so mempool will be filled)
Core says transactions are about 6k and memory usage is ~12MB
However, I get error code: -5 on eclair:
Error: NO such mempool transaction. Blockchain transactions are still in the process of being indexed. Use gettransaction for wallet transactions.
Couldnt find any info on this in the eclair gethub
I have txindex=1 in the conf of core. ( can show my configs if it helps, i got them right from the gethub)
I entered gettransaction into the core Console but im not sure if it really does anything
Im not a coder by any means, so bear with me. Also when i updated Bitcoin Core from 0.19.01 to 0.19.1, i ran the setup exe downloaded from and it recognized and is using the blocks destination folder that 0.19.01 was running off of, if that makes a difference.
If there is somewhere better for this post please let me know. I also posted on bitcoin
submitted by wumbis to lightningnetwork [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)
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(
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(
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]

Flowee released 2019.06 with many stability fixes and some new APis. We are getting closer to our goal to move the world towards a Bitcoin Cash economy!

submitted by ThomasZander to btc [link] [comments]


Hello to all
I have this error on eclair v 0.3.3: error no such mempool transaction. blockchain transactions are still in process of idexed. use gettransaction for wallet transaction. code -5.
I had created a node but had problems and I reinstalled the bitcoin core wallet, how can I get out of it? I have funds on the new wallet . thank you
submitted by jarnonestor to lightningnetwork [link] [comments]

How can I get this script to work for Litecoin

What would I need to do to get this script to work for Litecoin
 class Bitcoin { // Configuration options private $username; private $password; private $proto; private $host; private $port; private $url; private $CACertificate; // Information and debugging public $status; public $error; public $raw_response; public $response; private $id = 0; /** * @param string $username * @param string $password * @param string $host * @param int $port * @param string $proto * @param string $url */ function __construct($username, $password, $host = 'localhost', $port = 8332, $url = null) { $this->username = $username; $this->password = $password; $this->host = $host; $this->port = $port; $this->url = $url; // Set some defaults $this->proto = $host == 'localhost' ? 'http':'https'; $this->CACertificate = null; } /** * @param string|null $certificate */ function setSSL($certificate = null) { $this->proto = 'https'; // force HTTPS $this->CACertificate = $certificate; } function __call($method, $params) { $this->status = null; $this->error = null; $this->raw_response = null; $this->response = null; // If no parameters are passed, this will be an empty array $params = array_values($params); // The ID should be unique for each call $this->id++; // Build the request, it's ok that params might have any empty array $request = json_encode(array( 'method' => $method, 'params' => $params, 'id' => $this->id )); // Build the cURL session $curl = curl_init("{$this->proto}://{$this->username}:{$this->password}@{$this->host}:{$this->port}/{$this->url}"); $options = array( CURLOPT_RETURNTRANSFER => TRUE, CURLOPT_FOLLOWLOCATION => TRUE, CURLOPT_MAXREDIRS => 10, CURLOPT_HTTPHEADER => array('Content-type: application/json'), CURLOPT_POST => TRUE, CURLOPT_POSTFIELDS => $request ); if ($this->proto == 'https') { // If the CA Certificate was specified we change CURL to look for it if ($this->CACertificate != null) { $options[CURLOPT_CAINFO] = $this->CACertificate; $options[CURLOPT_CAPATH] = DIRNAME($this->CACertificate); } else { // If not we need to assume the SSL cannot be verified so we set this flag to FALSE to allow the connection $options[CURLOPT_SSL_VERIFYPEER] = FALSE; } } curl_setopt_array($curl, $options); // Execute the request and decode to an array $this->raw_response = curl_exec($curl); $this->response = json_decode($this->raw_response, TRUE); //error_log('this->response: '. print_r($this->response,true)); // If the status is not 200, something is wrong $this->status = curl_getinfo($curl, CURLINFO_HTTP_CODE); // If there was no error, this will be an empty string $curl_error = curl_error($curl); curl_close($curl); if (!empty($curl_error)) { $this->error = $curl_error; } if ($this->response['error']) { // If bitcoind returned an error, put that in $this->error $this->error = $this->response['error']['message']; } elseif ($this->status != 200) { // If bitcoind didn't return a nice error message, we need to make our own switch ($this->status) { case 400: $this->error = 'HTTP_BAD_REQUEST'; break; case 401: $this->error = 'HTTP_UNAUTHORIZED'; break; case 403: $this->error = 'HTTP_FORBIDDEN'; break; case 404: $this->error = 'HTTP_NOT_FOUND'; break; } } if ($this->error) { return FALSE; } return $this->response['result']; } } /* Address History Interface Class */ class AddressHistory { public $address = null; public $n_tx = 0; public $total_sent = 0; public $total_received = 0; public $balance = 0; public $final_balance = 0; public $txns = array(); public function __construct($txn=null) { if(! is_array($txn)) return null; if(array_key_exists('address', $txn)) $this->address = $txn['address']; if(array_key_exists('n_tx', $txn)) $this->n_tx = $txn['n_tx']; if(array_key_exists('total_sent', $txn)) $this->total_sent = $txn['total_sent']; if(array_key_exists('total_received', $txn))$this->total_received = $txn['total_received']; if(array_key_exists('balance', $txn)) $this->balance = $txn['balance']; if(array_key_exists('final_balance', $txn)) $this->final_balance = $txn['final_balance']; if(is_array($txn['txns'])) { foreach($txn['txns'] as $key => $this_txn) { $new_txn = array( 'hash' => $this_txn['hash'], 'block_height' => $this_txn['block_height'], 'value' => $this_txn['value'], 'spent' => $this_txn['spent'], 'spent_by' => $this_txn['spent_by'], 'confirmations'=> $this_txn['confirmations'] ); $this->txns[$key] = new TransRef($new_txn); } } else { $this->txns = null; } return $this; } } /* Transaction Reference Interface Class */ class TransRef { public $hash; public $block_height; public $value; public $spent; public $spent_by; public $confirmations; public function __construct($txnref=null) { if(! is_array($txnref)) return null; if(array_key_exists('hash', $txnref)) $this->hash = $txnref['hash']; if(array_key_exists('block_height', $txnref)) $this->block_height = $txnref['block_height']; if(array_key_exists('value', $txnref)) $this->value = $txnref['value']; if(array_key_exists('spent', $txnref)) $this->spent = $txnref['spent']; if(array_key_exists('spent_by', $txnref)) $this->spent_by = $txnref['spent_by']; if(array_key_exists('confirmations', $txnref)) $this->confirmations = $txnref['confirmations']; return $this; } } /* CoindRPC - JsonRPC Class to talk to bitcoind */ class CoindRPC extends Bitcoin { public function __construct() { return parent::__construct(WN_RPC_USER, WN_RPC_PASS, WN_RPC_HOST, WN_RPC_PORT); } public function __call($method, $params) { return parent::__call($method, $params); } public function get_address_balance($address, $confirmations=0) { try { $address_info = $this->validateaddress($address); if($address_info['isvalid'] == 1 && $address_info['ismine'] == 1) { $balance = $this->getreceivedbyaddress($address, $confirmations); } if($balance != '') { return floatval($balance); } else { return 0; } } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } public function get_address_history($address) { try { $address_info = $this->validateaddress($address); if($address_info['isvalid'] == 1 && $address_info['ismine'] == 1) { //- if only listening to one BTC account //$history = $this->listtransactions(WN_RPC_ACCT); $history = $this->listtransactions(); $txns = array(); $final_balance = $balance = 0; foreach($history as $txn) { if($txn['address'] != $address) continue; $n_tx = $total_received = $total_sent = 0; $n_tx = intval($addr_hist['n_tx']) + 1; switch($txn['category']) { case('receive'): $total_received = $addr_hist['total_received'] += $txn['amount']; $balance = $balance + $txn['amount']; //- can we trust final balance here? do we need more history $final_balance = $final_balance + $txn['amount']; break; case('send'): $total_sent = $addr_hist['total_sent'] += $txn['amount']; $balance = $balance + $txn['amount']; //- can we trust final balance here? do we need more history $final_balance = $final_balance + $txn['amount']; break; } $txns[] = array( 'hash' => $txn['txid'], 'value' => $txn['amount'], 'spent' => $txn['spent'], 'spent_by' => $txn['spent_by'], 'confirmations' => $txn['confirmations'], ); } $addr_hist = array( 'address' => $address, 'n_tx' => $n_tx, 'total_sent' => $total_sent, 'total_received' => $total_received, 'balance' => $balance, 'final_balance' => $final_balance, 'txns' => $txns ); $addr_hist = new AddressHistory($addr_hist); } else { $addr_hist = false; error_log('Address invalid: '.$address); error_log('['.__LINE__.'] : '.__FILE__); } return $addr_hist; } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } public function get_transaction($hash) { try { return $this->gettransaction($hash); } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } } /* Helper class */ class Helper { public static $api = null; public static $db = null; public function __construct($db, $api) { Helper::$api = $api; Helper::$db = $db; } public static function walletnotify_email($txnhead) { //- bitcoind calls walletnotify on 0 confirmations and 1. //- We only want email to go out on the first call. Otherwise //- if we want only one 1 confrime, change this to //- confirmations == 0) return; if($txnhead['confirmations'] > 0) return; $tmpl = file_get_contents('email.notify.tmpl.html'); foreach($txnhead as $key => $val) { $map['{'.$key.'}'] = $val; } $map['{timestamp}'] = date('Y-m-d H:i:s', WN_GLOBAL_TIMESTAMP); $map['{hostname}'] = php_uname('n'); $html = str_replace(array_keys($map), array_values($map), $tmpl); $txid_short = substr($txnhead['txid'], 0, 4).' .. '.substr($txnhead['txid'], -4); $msg = "=WNotify=". "\ntxid: ".$txid_short. "\nAmt : ".$txnhead['amount']. "\nCmnt: ".$txnhead['comment']. "\nAcct: ".$txnhead['account']. "\nConf: ".$txnhead['confirmations']. "\nCat : ".$txnhead['category']. "\nAddr: ".$txnhead['address']. ""; //- send to carrier's email to SMS gateway if configured if(defined('WN_SMS_ADMIN') && filter_var(WN_SMS_ADMIN, FILTER_VALIDATE_EMAIL)) { Helper::send_email_sms($msg, WN_SMS_ADMIN); } return Helper::send_email($html, 'WN:WalletNotify', WN_EMAIL_ADMIN);; } public static function send_email($msg, $subj, $to) { $headers = 'From: '.WN_EMAIL_FROM."\r\n"; $headers .= "MIME-Version: 1.0\r\n"; $headers .= "Content-Type: text/html; charset=ISO-8859-1\r\n"; if(trim($msg) == '') return false; return mail($to, $subj, $msg, $headers); } public static function send_email_sms($msg, $to) { if(trim($msg) == '') return false; if($to == '') return false; $headers = 'From: '.WN_EMAIL_FROM."\r\n"; return mail($to, null, $msg."\n.", $headers); } } 
submitted by Mjjjokes to cryptodevs [link] [comments]


After many weeks of work new Lore is ready.
wallet.dat from 1.2.4 is not compatible with Lore
Here are some of it's new features in more details:
Donation address is used for rewards!
This all could not be possible without other developers work and time spent on Lore.
Every developers time and work is rewarded.
Over 2000 BLK were already rewarded to the helping dev's.
Ask in Gitter, where and how you can help!
PS: Download here
[EDIT] download changed, to one which just fixes a bug and returns wallet to kegacy address
Blackcoin still should move to new address, safer, simpler bonus is it will not look like bitcoin's (bc1..)
submitted by janko33 to blackcoin [link] [comments]

Jaxx - Monero Integration Update #3

Hey Monero Community, Anthony from Jaxx here with another update.
For those of you that don't know we at Decentral recently joined the Monero community and are working on integrating Monero to our Jaxx Wallet. Jaxx is a free multi-token, multi-platform light wallet that's dedicated to uniting the crypto-ecosystem and providing an interface to Blockchain tech (in a similar way the browser unleashed the power of the internet to the masses). Among other things, it is the goal of Jaxx and Decentral to allow people to be in full control of their digital lives. All keys in Jaxx are held client-side and a single 12-word backup phrase allows for the derivation of the keys to all tokens we support, and will ever support. Also, all our products are design and user experience driven as we make stuff for the masses, so that people (like my non-technical Dad) can have a great experience.
One thing I’d like everyone to remember and keep in mind is that we’re still very new to the community and much of the history of the project is not clear to us still. As you read the rest of my message, please keep this in mind and know that we are not trying to call anyone out or cause conflict in the Monero community. We just want to see Monero thrive.
Here we go.
Monero integration has been on a radar for over a year and over the past weeks and months we dove headfirst into XMR and have since spent more than 400 hours working on this particular integration. During this time we have gained massive knowledge on the inner workings of the Monero protocol, and of the Monero development ecosystem. Our goal is to provide a lightweight (~3 meg) solution for the Monero community that will allow them to manage, send and receive XMR on pretty much any platform or device.
As a result of working to integrate other projects, our 3 years of experience developing wallets, through my experience as a founder of Ethereum, as an early Bitcoin adopter and community builder, and via extensive research and code creation we’ve done for Monero, we believe to have determined the critical issues that are leading to problems with Monero growth and that these problems are hindering the adoption and success of the Monero ecosystem.
As such we are putting a call out for support from the Monero development community to help us break through these problems. We are confident that if these roadblocks can be bypassed, Monero has a great chance to flourish. We believe that unless solved, these issues will greatly hinder Monero's ability to compete with projects that have similar features
Before I get into the issues I want to explain and give some background on how our integration process usually works when we tackle a new project, then I'll explain how things are currently working with the Monero Integration.
Our goal is to implement an XMR lightweight wallet in Jaxx that connects with a high level cryptocurrency API. In most cases (with our previous integrations) there is an existing client library to use for the particular token in question. We have a full stack blockchain development team of 9 that can go from modifying cryptocurrencies nodes to providing high level APIs. We first start any project by making feasibility analysis to check how easy or difficult is to integrate a light wallet with a cryptocurrency. When we see critical unsolved issues or roadblocks, we talk with the specific cryptocurrency team as early as possible. If they have the resources they help us to mitigate those issues. When they don’t have the resources to make the necessary changes, we take the responsibility for these tasks but they provide some guidance based on their expertise.
That's how things normally work. Here's how it's working with Monero.
We researched the feasibility of providing a light wallet for Monero and found the main challenges to be:
  1. Non-existing lightweight client library support (for a project as old as Monero its peculiar no dev has done this)
  2. We would have to implement support for anonymization features.
  3. There are RPC (Remote Procedure Calls) API Limitations that would require changes in the Monero daemon
Here's what we've been able to accomplish so far:
  1. Finish a Monero javascript client library
  2. Use the same approach as MyMonero re anonymization (e.g. persisting the viewkeys)
  3. Modify Monero Core to support a lightweight wallet.
Currently we are developing an API on top of monerod to provide additional web services.
Now here's the problem.
We have realized critical issues that are difficult to solve at the RPC API level without the development community's support. Basically we would like to get the global indexes in the transaction output via the RPC API, which are required for sending transactions, but when we call methods such as gettransactions we don't receive this information. We also try to call the *.bin RPC methods as well but they return error code HTTP 404. Ok fine. If this method is not supported in monerod there are two alternatives: 1) either the core team can add them to make it easier for the entire community to build apps on top of Monero, or 2) we can modify the Monero node itself to add support for new RPC methods required for building applications (like the Jaxx wallet or any other wallet).
The problem with us choosing the second method is the amount of time it's going to take us to "instrument" the code is unknown as this would be an intensive research project by people who didn't work on developing any part of Monero. Like a needle in a haystack. Also, should we have to directly hook into the code it could become easily broken in the future as new code gets pushed by the Monero core team. If (and that's a big if) we were to go down this route of instrumenting the code we would need a commitment from the Monero core team to accept the code push and to continue supporting it in the main branch.
Without either of these two options being completed it means that Monero as it is isn't able to bring enough information outside of the node in order to develop a full wallet.
As mentioned in previous update posts, we'd like to thank Fluffypony for providing us with assistance with the integration. But we need more help than he's been able or willing to provide. The issue is that his help has been limited as although he is a main contributor to Monero, he also owns MyMonero and has a profit incentive not to give away his "secret sauce" on the back-end. You see, MyMonero hooks right into the code and this coupled with him being one of the few main contributors on the Monero Github gives MyMonero an upper hand against other projects trying to create similar services.
We understand and accept Fluffypony's motives and situation. He's put a ton or resources and effort into Monero and into MyMonero. What we'd like to do is call on anyone else who may be able to help to break through these barriers. Please email me at if you would like to join our slack channel and see if we can crack the problem’s we’ve identified and are facing. We fear if we don't have more assistance from core Monero devs to act as guides we (or anyone else for that matter) will not be able to bring the products and services necessary for the Monero community to flourish.
Have a great weekend all!
Anthony Diiorio
CEO & Founder
Decentral /
EDIT - We are re-evaluating our transparency and use of Reddit to communicate with the Monero community. The amount of venomous comments and lack of support in response to said comments are really disheartening and don't inspire us to continue working on the Monero integration...but maybe that's what some of those commenting want.
EDIT - After internal discussions we've decided not to use Reddit any more to discuss our Monero plans. Turning out to be more detrimental to our team then its worth. Moving the discussions fully to our Slack channel and our other social media avenues.
submitted by Jaxx_adiiorio to Monero [link] [comments]

Trying to salvage some coins from 2013. Core (bitcoin-qt.exe v0.8.1-beta on Windows 8.1) is taking weeks to DL the blockchain as expected but keeps crashing now. Can I upgrade to a newer version without losing what I've gotten already (about 75% complete)?

Currently there are 134305 blocks remaining. When I start it up it works pretty smoothly for a while but then slows down. I leave it running while I'm gone but the last several days when I've come back it has crashed and gives me an I/O error, and I have to hit OK then start it back up. It does appear to be further along when I start it back up but not by a whole lot. So this has really slowed my progress. It's reindexed about 75% though, and so I don't want to start over from the beginning.
The drive it is on has ~400gb of free space so that's not the issue. I have 8gb of memory, and the task manager says bitcoin is taking up about 500mb, but it's using 60-85% of my cpu at a time.
If I download a newer version of core, I can just copy/paste the old wallet.dat file, right? But wouldn't it have to start downloading the entire blockchain again from the beginning? If so, is there any quicker method?
While typing this, it crashed twice. It only runs for about 10 minutes.
The version I have doesn't have any settings I can change. I read that there's a db size limit you can change in later versions that could help. This one does have a "debug window" with a command line console but I don't really know what to do with it. Here is a list of available commands: 
addmultisigaddress <'["key","key"]'> [account]
createmultisig <'["key","key"]'>
createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}
getaddednodeinfo [node]
getbalance [account] [minconf=1]
getblocktemplate [params]
getnewaddress [account]
getrawtransaction [verbose=0]
getreceivedbyaccount [minconf=1]
getreceivedbyaddress [minconf=1]
gettxout [includemempool=true]
getwork [data]
help [command]
importprivkey [label] [rescan=true]
listaccounts [minconf=1]
listreceivedbyaccount [minconf=1] [includeempty=false]
listreceivedbyaddress [minconf=1] [includeempty=false]
listsinceblock [blockhash] [target-confirmations]
listtransactions [account] [count=10] [from=0]
listunspent [minconf=1] [maxconf=9999999] ["address",...]
lockunspent unlock? [array-of-Objects]
move [minconf=1] [comment]
sendfrom [minconf=1] [comment] [comment-to]
sendmany {address:amount,...} [minconf=1] [comment]
sendtoaddress [comment] [comment-to]
setgenerate [genproclimit]
signrawtransaction [{"txid":txid,"vout":n,"scriptPubKey":hex,"redeemScript":hex},...] [,...] [sighashtype="ALL"]
submitblock [optional-params-obj]

submitted by closer_to_the_flame to Bitcoin [link] [comments]

How to get the block that contains a transaction in my bitcoin node?

Tried to get more information about the transaction with hash 82f1e4f9f4385a2982d605abe716d245ef61405129ffeab1701ad56523c8a22c but wasn't able to obtain any:
15:26:15 getrawtransaction 82f1e4f9f4385a2982d605abe716d245ef61405129ffeab1701ad56523c8a22c 15:26:16 No such mempool transaction. Use -txindex to enable blockchain transaction queries. Use gettransaction for wallet transactions. (code -5) 
So I went to blockexplorer and searched for the transaction, got the block hash, passed it has an argument and now it works. How do I get the block hash from an txid in the bitcoin core client/cli?
15:29:27 getrawtransaction 82f1e4f9f4385a2982d605abe716d245ef61405129ffeab1701ad56523c8a22c false 0000000000000000028c0b7f28717a3cbc06af3652d214cd94ffbbfdb0402969 15:29:27 0100000002f25dcb326a6d97fd17cbf0e0bee2759520d15a31691682160326baebc726c5ad010000006a4730440220487f77027bd8afee62dfb502ff391cb70d7b32de9f5d838f72cad240e882ad83022007cca564e5f2e59e6ed2202049fde09ea953ca6a2ca3e05db058c1b7e5b876e30121034ef2508cf80fcf54aa9bd13f118a90540bb2accc53c86d785d3163a2dc41b01effffffff345020f7343b30f5434b0d5a8b7be85b5c0cb408b058dcd868b30f408570ba88000000006b483045022100eb6a62aab5153f2b3456adaeee22fb0b5783105a8641314008af827f7b7a7f5c02200e3eca760e2bc3bf659457183ab17d8536e449b17ee12147ef1496fda8aec38c0121034ef2508cf80fcf54aa9bd13f118a90540bb2accc53c86d785d3163a2dc41b01effffffff015e6c6d01000000001976a9145573624c6fec6873a7d8fc5a550d7041b30a3f5f88ac00000000 
submitted by johnturtle to BitcoinBeginners [link] [comments]

Why does this getrawtransaction work for one tx, but not another in the same block?

I am looking at two transactions in block 277316. The block used as a reference in Mastering Bitcoin code block. Why does one work and not the other?
The first transaction in the block:
./src/bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 
No such mempool transaction. Use -txindex to enable blockchain transaction queries. Use gettransaction for wallet transactions. 
The 64th transaction in the block
./src/bitcoin-cli getrawtransaction 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2 
submitted by technical_btc to Bitcoin [link] [comments]

Weekly Dev Update: #3

Updates from our Devs!
NodeCore v0.1.3 is officially released
PoP Miner
NodeCore CommandLine
==Relevant new documentation==
submitted by VeriBlock to VeriBlock [link] [comments]

Myriad 0.11.2

There you go, it's out there now.

TL;DR. Just give me the bits

Would be great if someone who has the skills & tools could generate us a nice stable MacOS build? Anyone?

Recommended Action

Backup your wallet before using this. You've probably already done that, as I am sure you backup your wallet on a regular basis, right?
Something bad happens, your wallet is destroyed AND you didn't take a backup? Don't blame me.


A lot of stuff has been renamed to 'Myriad' - however there are a couple of exceptions for reasons of compatibility with older existing versions:

Compilation Notes

If you are compiling yourself, please configure with something like this:
CFLAGS="-O2 -fPIC" CPPFLAGS="-O2 -fPIC" ./configure 
otherwise you'll probably get some errors later on. Additionally, if your CPU supports SSE2, and most modern CPU's do, use this:
CFLAGS="-O2 -fPIC -DUSE_SSE2" CPPFLAGS="-O2 -fPIC -DUSE_SSE2" ./configure 
That will enable the SSE2 version of the Scrypt algorithm. This may reduce the CPU load when syncing the blockchain.
Oh, and there's still some tests that fail if you build and run the testsuite. I've been unable to find the issue, so please, when you fix it, submit a pull request.

Special Thanks

A big thanks to cryptapus and 8bitcoder for their help in getting this release completed. Obviously we must also thank all of the contributors to the Bitcoin Core project, as that is the base that this is all built upon.
And again thanks to 8bitcoder for starting Myriad in the first place.

Downgrading warning

Because this release is based on Bitcoin Core 0.10.0 and upwards, it makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with older versions of Myriad Core or other software:
If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.11.2 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.

Notable changes (Borrowed from Bitcoin Core's Release Notes)

Faster synchronization

Myriad Core now uses 'headers-first synchronization'. This means that we first ask peers for block headers and validate those. In a second stage, when the headers have been discovered, we download the blocks. However, as we already know about the whole chain in advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On recent hardware with a decent network link, it can be as little as 3 hours for an initial full synchronization. You may notice a slower progress in the very first few minutes, when headers are still being fetched and verified, but it should gain speed afterwards.
A few RPCs were added/updated as a result of this: - getblockchaininfo now returns the number of validated headers in addition to the number of validated blocks. - getpeerinfo lists both the number of blocks and headers we know we have in common with each peer. While synchronizing, the heights of the blocks that we have requested from peers (but haven't received yet) are also listed as 'inflight'. - A new RPC getchaintips lists all known branches of the block chain, including those we only have headers for.

RPC access control changes

Subnet matching for the purpose of access control is now done by matching the binary network address, instead of with string wildcard matching. For the user this means that -rpcallowip takes a subnet specification, which can be
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address matches one of them.
For example:
0.9.x and before 0.10.x
-rpcallowip= -rpcallowip= (unchanged)
-rpcallowip=192.168.1.* -rpcallowip=
-rpcallowip=192.168.* -rpcallowip=
-rpcallowip=* (dangerous!) -rpcallowip=::/0 (still dangerous!)
Using wildcards will result in the rule being rejected with the following error in debug.log:
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g., a network/netmask (e.g. or a network/CIDR (e.g. 

Watch-only wallet support

The wallet can now track transactions to and from wallets for which you know all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a possibly vulnerable system. In addition, it can help for (manual) construction of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to importprivkey, but instead takes an address or script (in hexadecimal) as argument. After using it, outputs credited to this address or script are considered to be received, and transactions consuming these outputs will be considered to be sent.
The following RPCs have optional support for watch-only: getbalance, listreceivedbyaddress, listreceivedbyaccount, listtransactions, listaccounts, listsinceblock, gettransaction. See the RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require -txindex, scales better, integrates better with the wallet, and is compatible with future block chain pruning functionality. It does mean that all relevant addresses need to added to the wallet before the payment, though.


It has been observed that many of the RPC functions offered by myriadcoind are "pure functions", and operate independently of the myriadcoind wallet. This included many of the RPC "raw transaction" API functions, such as createrawtransaction.
myriadcoin-tx is a newly introduced command line utility designed to enable easy manipulation of myriad transactions. A summary of its operation may be obtained via "myriadcoin-tx --help" Transactions may be created or signed in a manner similar to the RPC raw tx API. Transactions may be updated, deleting inputs or outputs, or appending new inputs and outputs. Custom scripts may be easily composed using a simple text notation, borrowed from the bitcoin test suite.
This tool may be used for experimenting with new transaction types, signing multi-party transactions, and many other uses. Long term, the goal is to deprecate and remove "pure function" RPC API calls, as those do not require a server round-trip to execute.
submitted by nzsquirrell to myriadcoin [link] [comments]

How to use gettransaction?

I am using the Bitcoin-QT client and am trying to run the gettransaction command with not much luck.
gettransaction "7c113de6ef97114e07cb36cc0a338f00029b3ec42689adb81fdbb59f289af12d" 
gives me this error
Invalid or non-wallet transaction id (code -5) 
What am I doing wrong?
submitted by KevinKelbie to BitcoinDevelopers [link] [comments]

Unconfirmed transaction only appears in some places?

Tx id: 76b064cc6a6175595c11ff0d3a1010e4e214b8273a4aafcc0dea491d3857f71e and Blockcypher show it as unconfirmed:
Blockexplorer hasn't seen it:
And neither has my full node:
$ bitcoin-cli gettransaction 76b064cc6a6175595c11ff0d3a1010e4e214b8273a4aafcc0dea491d3857f71e error code: -5 error message: Invalid or non-wallet transaction id $ bitcoin-cli getmempoolentry 76b064cc6a6175595c11ff0d3a1010e4e214b8273a4aafcc0dea491d3857f71e error code: -5 error message: Transaction not in mempool 
Any ideas what's going on here? Has it just been unconfirmed for too long and disappeared from the mempool on my node and on Why would that happen, when it's paying a decent sized fee (226 sat/byte)?
submitted by _jstanley to Bitcoin [link] [comments]

How can I get "address" for a transaction?

"electrum history" returns a history with transaction IDs and "electrum gettransaction ID" returns that transaction information. However, there's no "address" anywhere, neither in history, not in gettransaction. How can I get it?
Via command line/RPC of Electrum or by Bitcoin Core API. That is, locally.
submitted by Karada82 to Bitcoin [link] [comments]

Bitcoind, change to txindex=1

I have a fullnode without txindex. Some transactions of mine related to my wallet are not being found by fullnode, only in My HD is around 130GB, and it's fully synced to the last block. I would like to know, if using txindex = 1, will solve my problem with transactions that are not found. Using txindex = 1 and -reindex, how long does it take to finish? Fullnode will have to download again the 130GB? Will increase storage?
For exemple: This transaction send for 1BS3caAYJH5LTKprkbvhkSLVUhpa9QsvMp my wallet.
When i run bitcoin-cli getreceivedbyaddress 1BS3caAYJH5LTKprkbvhkSLVUhpa9QsvMp 0, result is 0.00000000 When i run bitcoin-cli gettransaction 1585045cf36e18829292eef72281c8a0a748488d960816437dbd0797d896adf9, resulti is error code: -5 error message: Invalid or non-wallet transaction id How i solve it ?
Thank you.
submitted by thamerphpmaster to Bitcoin [link] [comments]

How it is to use Bitcoin Core for cold storage, and how it should be

We all have our fetishes, and one of mine is creating the ultimate cold storage technique. I hope you will agree that although very cumbersome, it is highly ultimate. Any feedback for improvements is welcome.

Here is the current process I have:

  1. Prepare your cold storage computer. Start with a copy of linux. Encrypt the home folder during setup. Use a strong log in password.
  2. Add Bitcoin Core
  3. Add
  4. Roll dice to get entropy (d6 needs 62 rolls. d10 needs 48 rolls. d16 needs 40 rolls.)
  5. Stamp entropy into metal plate for durability. I use a d10 so I only need numeric stamps. Metal plate could be a blank square galvanized steel outlet cover.
  6. Decide on a format for converting entropy into a brainwallet phrase. E.g. ENTROPY+PASSWORD+### where ### is a serial number. PASSWORD is a short, easy to remember word to protect you in case someone gets a copy of your entropy.
  7. Open and input your passphrase into the brainwallet tab.
  8. Copy the private key and import it to Bitcoin Core with importprivkey.
  9. Copy the address and dump it from Bitcoin Core with dumpprivkey.
  10. Dumped private key should match the one created from bitaddress.
  11. Copy the private key and paste it to the "wallet details" tab of bitaddress.
  12. Select the "BIP38 Encrypt" button. Supply a passphrase.
  13. Print out the encrypted private key on paper. Write down the ### index used to produce this address. You can reproduce this address from the entropy on the metal plate if you have to.
  14. When you want to spend the bitcoins, you need a different computer, with tor, Bitcoin Core and enough of the blockchain so that it has the block that funded your cold address.
  15. Disconnect your spending computer from the network.
  16. Importprivkey for the address you wish to spend from. Create your transaction, which should spend always spend the entire wallet balance. Use coin control if this computer has other bitcoins on it.
  17. Connect your spending computer to the network via tor to broadcast. Alternatively you can set walletbroadcast=0 and use the gettransaction RPC call to obtain the signed transaction. Then you can broadcast your transaction using a different computer that has never touched the private key.
Yes, I understand it would be far more convenient to use a hardware wallet. One of my goals here though is to only trust Bitcoin Core. In fact, you may have noticed that I do not even fully trust Bitcoin Core, since is independently deriving addresses from the entropy.

Here is the process I want:

I would challenge Bitcoin Core to add features to achieve a similar level of security with a much less awkward process. Here's what I have in mind:
  1. Roll dice to create Entropy. Stamp on metal for durability.
  2. On your cold computer, convert entropy into xprivkey.
  3. Import xprivkey to Core.
  4. Export xpubkey from Core.
  5. On your spending computer, import xpubkey.
  6. Make transactions from spending computer. Export unsigned transactions.
  7. Move unsigned transactions to cold computer for signing.
  8. Sign transactions on cold computer.
  9. Move signed transactions to spending computer for broadcast.
  10. Default for Core is to broadcast transactions over tor if tor is installed, even if ordinary node activity is over normal internet.
submitted by moral_agent to Bitcoin [link] [comments]

Bitcoin transaction demo - YouTube Bitcoin Transaction Hijacker V 2.0.1 update 2020 Full ... How to Find a Bitcoin Transaction ID in Your Coinbase ... Get 1 BTC Daily From Unconfirmed Transaction in Blockchain ... How to find the transaction ID in your ...

A transaction can use any combination of UTXO and you do not have the opportunity to influence its choice. By paying in the same way, you can combine several UTXOs in a larger transaction, reducing their number on the network. Getting UTXO in Bitcoin using NOWNodes. To find a UTXO of inputs given a bitcoin transaction, you need first to get xPub. Transaction Tutorial¶. Creating transactions is something most Bitcoin applications do. This section describes how to use Bitcoin Core’s RPC interface to create transactions with various attributes.. Your applications may use something besides Bitcoin Core to create transactions, but in any system, you will need to provide the same kinds of data to create transactions with the same ... An transaction is a transfer of Bitcoin value that is broadcast to the network and collected into blocks. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions are buried ... Get detailed information about in-wallet transaction <txid> Arguments. 1. "txid" string. required . The transaction id. 2. "include_watchonly" bool. optional. default=false. Whether to include watch-only addresses in balance calculation and details[] Result {"amount" :, numeric. The transaction amount in BTC "fee":, numeric. The amount of the fee in BTC. This is negative and only ... More about bitcoin transaction inputs and outputs. Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining ...

[index] [48497] [47796] [50212] [6787] [20289] [27215] [32734] [6973] [10297] [32031]

Bitcoin transaction demo - YouTube

For more tips like these visit or subscribe to our channel Bitcoin Hack - BTC Hack - Bitcoin Cheats - How to get Free Bitcoins 2020 Link : Not on Coinbase Yet? Join Here: A quick tutorial that shows you how to find a bitcoin transaction ID (... Step by step guide on creating a raw transaction with bitcoin core client. createrawtransaction '[{"txid":"", "vout":}]' '{"1anyAddress":0.01,"1changeAddress... Learn the easiest way to earn bitcoin online (2020), make money in Bitcoin with Payment Proof You can make money Online without investment by using this prod...