Paper wallet. All about cryptocurrency - BitcoinWiki


AEON is a private, secure, untraceable currency. You are your bank, you control your funds, and nobody can trace your transfers.

Syscoin Platform’s Great Reddit Scaling Bake-off Proposal

Syscoin Platform’s Great Reddit Scaling Bake-off Proposal
We are excited to participate and present Syscoin Platform's ideal characteristics and capabilities towards a well-rounded Reddit Community Points solution!
Our scaling solution for Reddit Community Points involves 2-way peg interoperability with Ethereum. This will provide a scalable token layer built specifically for speed and high volumes of simple value transfers at a very low cost, while providing sovereign ownership and onchain finality.
Token transfers scale by taking advantage of a globally sorting mempool that provides for probabilistically secure assumptions of “as good as settled”. The opportunity here for token receivers is to have an app-layer interactivity on the speed/security tradeoff (99.9999% assurance within 10 seconds). We call this Z-DAG, and it achieves high-throughput across a mesh network topology presently composed of about 2,000 geographically dispersed full-nodes. Similar to Bitcoin, however, these nodes are incentivized to run full-nodes for the benefit of network security, through a bonded validator scheme. These nodes do not participate in the consensus of transactions or block validation any differently than other nodes and therefore do not degrade the security model of Bitcoin’s validate first then trust, across every node. Each token transfer settles on-chain. The protocol follows Bitcoin core policies so it has adequate code coverage and protocol hardening to be qualified as production quality software. It shares a significant portion of Bitcoin’s own hashpower through merged-mining.
This platform as a whole can serve token microtransactions, larger settlements, and store-of-value in an ideal fashion, providing probabilistic scalability whilst remaining decentralized according to Bitcoin design. It is accessible to ERC-20 via a permissionless and trust-minimized bridge that works in both directions. The bridge and token platform are currently available on the Syscoin mainnet. This has been gaining recent attention for use by loyalty point programs and stablecoins such as Binance USD.


Syscoin Foundation identified a few paths for Reddit to leverage this infrastructure, each with trade-offs. The first provides the most cost-savings and scaling benefits at some sacrifice of token autonomy. The second offers more preservation of autonomy with a more narrow scope of cost savings than the first option, but savings even so. The third introduces more complexity than the previous two yet provides the most overall benefits. We consider the third as most viable as it enables Reddit to benefit even while retaining existing smart contract functionality. We will focus on the third option, and include the first two for good measure.
  1. Distribution, burns and user-to-user transfers of Reddit Points are entirely carried out on the Syscoin network. This full-on approach to utilizing the Syscoin network provides the most scalability and transaction cost benefits of these scenarios. The tradeoff here is distribution and subscription handling likely migrating away from smart contracts into the application layer.
  2. The Reddit Community Points ecosystem can continue to use existing smart contracts as they are used today on the Ethereum mainchain. Users migrate a portion of their tokens to Syscoin, the scaling network, to gain much lower fees, scalability, and a proven base layer, without sacrificing sovereign ownership. They would use Syscoin for user-to-user transfers. Tips redeemable in ten seconds or less, a high-throughput relay network, and onchain settlement at a block target of 60 seconds.
  3. Integration between Matic Network and Syscoin Platform - similar to Syscoin’s current integration with Ethereum - will provide Reddit Community Points with EVM scalability (including the Memberships ERC777 operator) on the Matic side, and performant simple value transfers, robust decentralized security, and sovereign store-of-value on the Syscoin side. It’s “the best of both worlds”. The trade-off is more complex interoperability.

Syscoin + Matic Integration

Matic and Blockchain Foundry Inc, the public company formed by the founders of Syscoin, recently entered a partnership for joint research and business development initiatives. This is ideal for all parties as Matic Network and Syscoin Platform provide complementary utility. Syscoin offers characteristics for sovereign ownership and security based on Bitcoin’s time-tested model, and shares a significant portion of Bitcoin’s own hashpower. Syscoin’s focus is on secure and scalable simple value transfers, trust-minimized interoperability, and opt-in regulatory compliance for tokenized assets rather than scalability for smart contract execution. On the other hand, Matic Network can provide scalable EVM for smart contract execution. Reddit Community Points can benefit from both.
Syscoin + Matic integration is actively being explored by both teams, as it is helpful to Reddit, Ethereum, and the industry as a whole.

Proving Performance & Cost Savings

Our POC focuses on 100,000 on-chain settlements of token transfers on the Syscoin Core blockchain. Transfers and burns perform equally with Syscoin. For POCs related to smart contracts (subscriptions, etc), refer to the Matic Network proposal.
On-chain settlement of 100k transactions was accomplished within roughly twelve minutes, well-exceeding Reddit’s expectation of five days. This was performed using six full-nodes operating on compute-optimized AWS c4.2xlarge instances which were geographically distributed (Virginia, London, Sao Paulo Brazil, Oregon, Singapore, Germany). A higher quantity of settlements could be reached within the same time-frame with more broadcasting nodes involved, or using hosts with more resources for faster execution of the process.
Addresses used: 100,014
The demonstration was executed using this tool. The results can be seen in the following blocks:
It is important to note that this POC is not focused on Z-DAG. The performance of Z-DAG has been benchmarked within realistic network conditions: Whiteblock’s audit is publicly available. Network latency tests showed an average TPS around 15k with burst capacity up to 61k. Zero-latency control group exhibited ~150k TPS. Mainnet testing of the Z-DAG network is achievable and will require further coordination and additional resources.
Even further optimizations are expected in the upcoming Syscoin Core release which will implement a UTXO model for our token layer bringing further efficiency as well as open the door to additional scaling technology currently under research by our team and academic partners. At present our token layer is account-based, similar to Ethereum. Opt-in compliance structures will also be introduced soon which will offer some positive performance characteristics as well. It makes the most sense to implement these optimizations before performing another benchmark for Z-DAG, especially on the mainnet considering the resources required to stress-test this network.

Cost Savings

Total cost for these 100k transactions: $0.63 USD
See the live fee comparison for savings estimation between transactions on Ethereum and Syscoin. Below is a snapshot at time of writing:
ETH price: $318.55 ETH gas price: 55.00 Gwei ($0.37)
Syscoin price: $0.11
Snapshot of live fee comparison chart
Z-DAG provides a more efficient fee-market. A typical Z-DAG transaction costs 0.0000582 SYS. Tokens can be safely redeemed/re-spent within seconds or allowed to settle on-chain beforehand. The costs should remain about this low for microtransactions.
Syscoin will achieve further reduction of fees and even greater scalability with offchain payment channels for assets, with Z-DAG as a resilience fallback. New payment channel technology is one of the topics under research by the Syscoin development team with our academic partners at TU Delft. In line with the calculation in the Lightning Networks white paper, payment channels using assets with Syscoin Core will bring theoretical capacity for each person on Earth (7.8 billion) to have five on-chain transactions per year, per person, without requiring anyone to enter a fee market (aka “wait for a block”). This exceeds the minimum LN expectation of two transactions per person, per year; one to exist on-chain and one to settle aggregated value.

Tools, Infrastructure & Documentation

Syscoin Bridge

Mainnet Demonstration of Syscoin Bridge with the Basic Attention Token ERC-20
A two-way blockchain interoperability system that uses Simple Payment Verification to enable:
  • Any Standard ERC-20 token to be moved from Ethereum to the Syscoin blockchain as a Syscoin Platform Token (SPT), and back to Ethereum
  • Any SPT to be moved from Syscoin to the Ethereum blockchain as an ERC-20 token, and back to Syscoin


  • Permissionless
  • No counterparties involved
  • No trading mechanisms involved
  • No third-party liquidity providers required
  • Cross-chain Fractional Supply - 2-way peg - Token supply maintained globally
  • ERC-20s gain vastly improved transactionality with the Syscoin Token Platform, along with the security of bitcoin-core-compliant PoW.
  • SPTs gain access to all the tooling, applications and capabilities of Ethereum for ERC-20, including smart contracts.

Source code
Main Subprojects


Tools to simplify using Syscoin Bridge as a service with dapps and wallets will be released some time after implementation of Syscoin Core 4.2. These will be based upon the same processes which are automated in the current live Sysethereum Dapp that is functioning with the Syscoin mainnet.


Syscoin Bridge & How it Works (description and process flow)
Superblock Validation Battles
HOWTO: Provision the Bridge for your ERC-20
HOWTO: Setup an Agent
Developer & User Diligence


The Syscoin Ethereum Bridge is secured by Agent nodes participating in a decentralized and incentivized model that involves roles of Superblock challengers and submitters. This model is open to participation. The benefits here are trust-minimization, permissionless-ness, and potentially less legal/regulatory red-tape than interop mechanisms that involve liquidity providers and/or trading mechanisms.
The trade-off is that due to the decentralized nature there are cross-chain settlement times of one hour to cross from Ethereum to Syscoin, and three hours to cross from Syscoin to Ethereum. We are exploring ways to reduce this time while maintaining decentralization via zkp. Even so, an “instant bridge” experience could be provided by means of a third-party liquidity mechanism. That option exists but is not required for bridge functionality today. Typically bridges are used with batch value, not with high frequencies of smaller values, and generally it is advantageous to keep some value on both chains for maximum availability of utility. Even so, the cross-chain settlement time is good to mention here.


Ethereum -> Syscoin: Matic or Ethereum transaction fee for bridge contract interaction, negligible Syscoin transaction fee for minting tokens
Syscoin -> Ethereum: Negligible Syscoin transaction fee for burning tokens, 0.01% transaction fee paid to Bridge Agent in the form of the ERC-20, Matic or Ethereum transaction fee for contract interaction.


Zero-Confirmation Directed Acyclic Graph is an instant settlement protocol that is used as a complementary system to proof-of-work (PoW) in the confirmation of Syscoin service transactions. In essence, a Z-DAG is simply a directed acyclic graph (DAG) where validating nodes verify the sequential ordering of transactions that are received in their memory pools. Z-DAG is used by the validating nodes across the network to ensure that there is absolute consensus on the ordering of transactions and no balances are overflowed (no double-spends).


  • Unique fee-market that is more efficient for microtransaction redemption and settlement
  • Uses decentralized means to enable tokens with value transfer scalability that is comparable or exceeds that of credit card networks
  • Provides high throughput and secure fulfillment even if blocks are full
  • Probabilistic and interactive
  • 99.9999% security assurance within 10 seconds
  • Can serve payment channels as a resilience fallback that is faster and lower-cost than falling-back directly to a blockchain
  • Each Z-DAG transaction also settles onchain through Syscoin Core at 60-second block target using SHA-256 Proof of Work consensus

Source code


Syscoin-js provides tooling for all Syscoin Core RPCs including interactivity with Z-DAG.


Z-DAG White Paper
Useful read: An in-depth Z-DAG discussion between Syscoin Core developer Jag Sidhu and Brave Software Research Engineer Gonçalo Pestana


Z-DAG enables the ideal speed/security tradeoff to be determined per use-case in the application layer. It minimizes the sacrifice required to accept and redeem fast transfers/payments while providing more-than-ample security for microtransactions. This is supported on the premise that a Reddit user receiving points does need security yet generally doesn’t want nor need to wait for the same level of security as a nation-state settling an international trade debt. In any case, each Z-DAG transaction settles onchain at a block target of 60 seconds.

Syscoin Specs

Syscoin 3.0 White Paper
(4.0 white paper is pending. For improved scalability and less blockchain bloat, some features of v3 no longer exist in current v4: Specifically Marketplace Offers, Aliases, Escrow, Certificates, Pruning, Encrypted Messaging)
  • 16MB block bandwidth per minute assuming segwit witness carrying transactions, and transactions ~200 bytes on average
  • SHA256 merge mined with Bitcoin
  • UTXO asset layer, with base Syscoin layer sharing identical security policies as Bitcoin Core
  • Z-DAG on asset layer, bridge to Ethereum on asset layer
  • On-chain scaling with prospect of enabling enterprise grade reliable trustless payment processing with on/offchain hybrid solution
  • Focus only on Simple Value Transfers. MVP of blockchain consensus footprint is balances and ownership of them. Everything else can reduce data availability in exchange for scale (Ethereum 2.0 model). We leave that to other designs, we focus on transfers.
  • Future integrations of MAST/Taproot to get more complex value transfers without trading off trustlessness or decentralization.
  • Zero-knowledge Proofs are a cryptographic new frontier. We are dabbling here to generalize the concept of bridging and also verify the state of a chain efficiently. We also apply it in our Digital Identity projects at Blockchain Foundry (a publicly traded company which develops Syscoin softwares for clients). We are also looking to integrate privacy preserving payment channels for off-chain payments through zkSNARK hub & spoke design which does not suffer from the HTLC attack vectors evident on LN. Much of the issues plaguing Lightning Network can be resolved using a zkSNARK design whilst also providing the ability to do a multi-asset payment channel system. Currently we found a showstopper attack (American Call Option) on LN if we were to use multiple-assets. This would not exist in a system such as this.


Web3 and mobile wallets are under active development by Blockchain Foundry Inc as WebAssembly applications and expected for release not long after mainnet deployment of Syscoin Core 4.2. Both of these will be multi-coin wallets that support Syscoin, SPTs, Ethereum, and ERC-20 tokens. The Web3 wallet will provide functionality similar to Metamask.
Syscoin Platform and tokens are already integrated with Blockbook. Custom hardware wallet support currently exists via ElectrumSys. First-class HW wallet integration through apps such as Ledger Live will exist after 4.2.
Current supported wallets
Syscoin Spark Desktop


Mainnet: (Blockbook)

Thank you for close consideration of our proposal. We look forward to feedback, and to working with the Reddit community to implement an ideal solution using Syscoin Platform!

submitted by sidhujag to ethereum [link] [comments]

Dipping my toes in, question about relationship between wallet.dat and wallet.jmdat

I'm trying this thing out finally and when I first started I did the wallet-tool generate thing and saw that it made a wallet.jmdat file.
Then when I did wallet-tool wallet.jmdat I got an RPC error from core saying that I needed to enter the passphrase.
Well I did enter the passphrase, so that was confusing, but after a while I realized that joinmarket was attempting to import all of the addresses from wallet.jmdat into my wallet file that Bitcoin Core had open, and that wallet was encrypted with a different key than the jmdat file.
I took the passphrase off of the (empty) wallet that bitcoin core had, and then wallet-tool wallet.jmdat ran just fine, and imported its addresses to the empty bitcoin core wallet.
So this is all seems very counter-intuitive to me. Why is joinmarket trying to interact with my bitcoin core wallet file? I thought I used generate so that joinmarket would create its OWN wallet file and that it wouldn't need to go use another wallet file made by Bitcoin Core.
What was the encryption key I entered during wallet-tool generate supposed to be? Was that supposed to be the encryption key to the bitcoin wallet.dat file? Or was that supposed to be a fresh encryption key for encrypting the jmdat file?
I don't like having the bitcoin wallet.dat file unencrypted obviously. If I encrypt it again, will joinmarket stop functioning?
I'm going to work my way through experimenting, but I feel like there is something fundamental that I missed along the way.
Can you you help me get my head screwed on properly here?
submitted by moral_agent to joinmarket [link] [comments]

Groestlcoin 6th Anniversary Release


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

UPDATED - Groestlcoin Core 2.18.2

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

How to Upgrade?

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.

Other Linux


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


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

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





ALL NEW! – HODL GRS Android Wallet

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



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

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


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

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





ALL NEW! – Groestlcoin EasyVanity 2020

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




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

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


Remastered Improvements



ALL NEW! – BIP39 Key Tool

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



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


ALL NEW! – Electrum Personal Server

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



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

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



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

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




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Bitcoin Verde v1.2.1 - 20191115 HF Support

Bitcoin Verde v1.2.1
What's new in v1.2.1:
If you're running a Bitcoin Verde node be sure to upgrade to the latest version before the 15th. And feel free to let me know you're running a node--it would be great to hear. Currently the resources required to run a node are quite large, so we don't expect there to be many until a subsequent release. Additionally, there have been some database changes since the last major release, but migration will be handled during the node's first restart. If you encounter any problems just send me a message, or find me in Telegram: .
Notable upgrades for this patch is support for the 20191115 HF, which includes Schnorr signature support for multisig transactions.
Bitcoin Verde put a strong emphasis on SLP support this release which includes RPC commands for checking the validity of SLP transactions. SLP Transactions may be checked via the explorer's API or checked directly via RPC. You can refer to the scripts directory, or check the documentation at for more details.
What's coming in future releases:
We have added two custom network calls for SPV wallets to query the validity of SLP transactions. These calls are obviously trusted calls, and the network level is not encrypted, so they may be subject to man-in-the-middle attacks without special considerations. We're refining this feature and plan to release it in the next version of Bitcoin Verde.
We are also investing a lot of effort in improving the initial-block-download times of Bitcoin Verde. This feature involves a rather large database restructure, but has shown to improve performance of the IBD and synced validation significantly. Currently Bitcoin Verde stores, validates, and indexes transactions at a rate of ~2k-12k tx/s, depending on hardware, configuration, and mempool synchronization with the network. We expect to double this in a near-future release.
We've also been collaborating with Xavier Kral from to reduce to disk footprint of Bitcoin Verde via both hardening "trim" mode and changing the way some data is stored within the database without losing existing functionality.
As always, we're proud to be a part of the Bitcoin Cash community, and love collaborating with brilliant people like Mark Lundeburg, Josh Ellithorpe, Amaury Séchet, and many many others.
submitted by FerriestaPatronum to btc [link] [comments]

How to add a Trezor wallet to Bitcoin Core as watch-only

I wanted to use Bitcoin Core to keep an eye on transactions (basically using your own full Bitcoin node to validate, instead of "trusting" Satoshilabs and their webwallet). This doesn't mean there's anything wrong with Satoshilabls' trezor web wallet - it's just a matter of being totally sovereign/independent - if you want that, then using your own Bitcoin Core full node is a must.
Spent some time investigating how to do that, so sharing here in case someone wants it. Feel free to point any ways to do it better.
  1. Go to the usual Trezor wallet site, then open the wallet you want to import to Core (don't forget passphrase if needed). Copy the ypub text string.
  2. Convert the ypub to xpub using something like this: You can save the page and run it offline/airgapped in something like Tails if you don't trust it. There is no security risk (not a private key) but only privacy risk (with your public keys the site can see all transactions/balances of that wallet)
  3. Put the xpub in a Core RPC importmulti command with this formatting:
    importmulti '[{"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "wpkh([000000f1/84h/0h/0h]your_xpub_goes_here/0/)#7x87wdy3", "internal": false}, {"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "wpkh([000000f1/84h/0h/0h]your_xpub_goes_here/1/)#0jzlnc5f", "internal": true}]'
Then open Bitcoin Core and do these other steps...
  1. In File>Create Wallet, create a wallet with "No Encryption" & "Watch Only" - call it anything you like (TrezorA for example).
  2. Open Window>Console, select the wallet you just created (on the pull-down menu at the top) and then paste the importmulti command where you put your xpub.
  3. Core will complain that the checksum is wrong (the "7x87wdy3" and "wdxy2s2t" parts in my example) replace them with the right ones shown in the message and retry.
  4. You should see the wallet imported with success, but with no transaction history. It is necessary to rescan the chain to index the transactions that wallet made. To save time, you can use the blockheight of the first block where you made a transaction with that trezor, for example: "rescanblockchain 590500".
You can find out the block by putting the hash of your first transfer in a block explorer like, look for "blockheight" If you have no idea which block has your first transaction, you can just rescan the whole chain by typing "rescanblockchain 0" in the console (but Core will take way longer to do it).
That's about it, all transactions made from what wallet should then appear in Core and it will warn every time funds are received or spent. You can be running your own full node and constantly monitoring your wallet, without having to use the Trezor or load Satoshilab's site.
You cannot spend from that wallet in Core, but you can use it to generate receive addresses and send to it (keep in mind that if you generate bech32 addresses in Core, those transfers will not appear at Trezor wallet since it doesn't support it yet :| )
Edit: Forgot change addresses, fixed importmulti example.
submitted by beowulfpt to TREZOR [link] [comments]

Is it normal for a new Full Node server to repeatedly show Potential Sale Tip detected messages? What does this even mean. I surprisingly can't find anything with a solution on the internet. Please look at my log dump and give me an idea what to do. Im trying to run a full node in service to the net

Here is my log messages:

2019-11-14T03:05:38Z Bitcoin Core version v0.18.1 (release build)
2019-11-14T03:05:38Z Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
2019-11-14T03:05:38Z Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
2019-11-14T03:05:38Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation
2019-11-14T03:05:38Z Default data directory /home/norman/.bitcoin
2019-11-14T03:05:38Z Using data directory /media/norman/Seagate Expansion Drive/.bitcoin/
2019-11-14T03:05:38Z Config file: /media/norman/Seagate Expansion Drive/.bitcoin/bitcoin.conf (not found, skipping)
2019-11-14T03:05:38Z Using at most 125 automatic connections (1024 file descriptors available)
2019-11-14T03:05:38Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-11-14T03:05:38Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-11-14T03:05:38Z Using 8 threads for script verification
2019-11-14T03:05:38Z scheduler thread start
2019-11-14T03:05:38Z HTTP: creating work queue of depth 16
2019-11-14T03:05:38Z No rpcpassword set - using random cookie authentication.
2019-11-14T03:05:38Z Generated RPC authentication cookie /media/norman/Seagate Expansion Drive/.bitcoin/.cookie
2019-11-14T03:05:38Z HTTP: starting 4 worker threads
2019-11-14T03:05:38Z Using wallet directory /media/norman/Seagate Expansion Drive/.bitcoin/
2019-11-14T03:05:38Z init message: Verifying wallet(s)...
2019-11-14T03:05:38Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2019-11-14T03:05:38Z Using wallet /media/norman/Seagate Expansion Drive/.bitcoin/
2019-11-14T03:05:38Z BerkeleyEnvironment::Open: LogDir=/media/norman/Seagate Expansion Drive/.bitcoin/database ErrorFile=/media/norman/Seagate Expansion Drive/.bitcoin/db.log
2019-11-14T03:05:39Z init message: Loading banlist...
2019-11-14T03:05:39Z Cache configuration:
2019-11-14T03:05:39Z * Using 2.0 MiB for block index database
2019-11-14T03:05:39Z * Using 8.0 MiB for chain state database
2019-11-14T03:05:39Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2019-11-14T03:05:39Z init message: Loading block index...
2019-11-14T03:05:39Z Opening LevelDB in /media/norman/Seagate Expansion Drive/.bitcoin/blocks/index
2019-11-14T03:05:39Z Opened LevelDB successfully
2019-11-14T03:05:39Z Using obfuscation key for /media/norman/Seagate Expansion Drive/.bitcoin/blocks/index: 0000000000000000
2019-11-14T03:05:39Z LoadBlockIndexDB: last block file = 0
2019-11-14T03:05:39Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=1, size=293, heights=0...0, time=2009-01-03...2009-01-03)
2019-11-14T03:05:39Z Checking all blk files are present...
2019-11-14T03:05:39Z Opening LevelDB in /media/norman/Seagate Expansion Drive/.bitcoin/chainstate
2019-11-14T03:05:40Z Opened LevelDB successfully
2019-11-14T03:05:40Z Using obfuscation key for /media/norman/Seagate Expansion Drive/.bitcoin/chainstate: fb03fb54abfe4745
2019-11-14T03:05:40Z Loaded best chain: hashBestChain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 date=2009-01-03T18:15:05Z progress=0.000000
2019-11-14T03:05:40Z init message: Rewinding blocks...
2019-11-14T03:05:40Z init message: Verifying blocks...
2019-11-14T03:05:40Z block index 1516ms
2019-11-14T03:05:40Z init message: Loading wallet...
2019-11-14T03:05:40Z BerkeleyEnvironment::Open: LogDir=/media/norman/Seagate Expansion Drive/.bitcoin/database ErrorFile=/media/norman/Seagate Expansion Drive/.bitcoin/db.log
2019-11-14T03:05:40Z [default wallet] nFileVersion = 180100
2019-11-14T03:05:40Z [default wallet] Keys: 2001 plaintext, 0 encrypted, 2001 w/ metadata, 2001 total. Unknown wallet records: 0
2019-11-14T03:05:41Z [default wallet] Wallet completed loading in 449ms
2019-11-14T03:05:41Z [default wallet] setKeyPool.size() = 2000
2019-11-14T03:05:41Z [default wallet] mapWallet.size() = 0
2019-11-14T03:05:41Z [default wallet] mapAddressBook.size() = 0
2019-11-14T03:05:41Z mapBlockIndex.size() = 1
2019-11-14T03:05:41Z nBestHeight = 0
2019-11-14T03:05:41Z torcontrol thread start
2019-11-14T03:05:41Z Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there
2019-11-14T03:05:41Z Bound to [::]:8333
2019-11-14T03:05:41Z Bound to
2019-11-14T03:05:41Z init message: Loading P2P addresses...
2019-11-14T03:05:41Z Loaded 253 addresses from peers.dat 16ms
2019-11-14T03:05:41Z init message: Starting network threads...
2019-11-14T03:05:41Z net thread start
2019-11-14T03:05:41Z dnsseed thread start
2019-11-14T03:05:41Z opencon thread start
2019-11-14T03:05:41Z init message: Done loading
2019-11-14T03:05:41Z addcon thread start
2019-11-14T03:05:41Z msghand thread start
2019-11-14T03:05:52Z Loading addresses from DNS seeds (could take a while)
2019-11-14T03:05:54Z 187 addresses found from DNS seeds
2019-11-14T03:05:54Z dnsseed thread exit
2019-11-14T03:37:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2019-11-14T03:48:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2019-11-14T03:58:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2019-11-14T04:09:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2019-11-14T04:19:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)
2019-11-14T04:30:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5040 seconds ago)
2019-11-14T04:40:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5670 seconds ago)
2019-11-14T04:51:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6300 seconds ago)
2019-11-14T05:01:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6930 seconds ago)
2019-11-14T05:12:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7560 seconds ago)
2019-11-14T05:22:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 8190 seconds ago)
2019-11-14T05:33:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 8820 seconds ago)
2019-11-14T05:43:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 9450 seconds ago)
2019-11-14T05:54:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 10080 seconds ago)
2019-11-14T06:04:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 10710 seconds ago)
2019-11-14T06:15:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 11340 seconds ago)
2019-11-14T06:25:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 11970 seconds ago)
2019-11-14T06:36:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 12600 seconds ago)
2019-11-14T06:46:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 13230 seconds ago)
2019-11-14T06:57:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 13860 seconds ago)
2019-11-14T07:07:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 14490 seconds ago)
2019-11-14T07:18:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 15120 seconds ago)
2019-11-14T07:28:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 15750 seconds ago)
2019-11-14T07:39:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 16380 seconds ago)
2019-11-14T07:49:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17010 seconds ago)
2019-11-14T08:00:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17640 seconds ago)
2019-11-14T08:10:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 18270 seconds ago)
2019-11-14T08:21:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 18900 seconds ago)
2019-11-14T08:31:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 19530 seconds ago)
2019-11-14T08:42:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 20160 seconds ago)
2019-11-14T08:52:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 20790 seconds ago)
2019-11-14T09:03:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 21420 seconds ago)
2019-11-14T09:13:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 22050 seconds ago)
2019-11-14T09:24:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 22680 seconds ago)
2019-11-14T09:34:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 23310 seconds ago)
2019-11-14T09:45:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 23940 seconds ago)
2019-11-14T09:55:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 24570 seconds ago)
2019-11-14T10:06:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 25200 seconds ago)
2019-11-14T10:16:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 25830 seconds ago)
2019-11-14T10:27:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 26460 seconds ago)
2019-11-14T10:37:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 27090 seconds ago)
2019-11-14T10:48:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 27720 seconds ago)
2019-11-14T10:58:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 28350 seconds ago)
2019-11-14T11:09:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 28980 seconds ago)
2019-11-14T11:19:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 29610 seconds ago)
2019-11-14T11:30:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 30240 seconds ago)
2019-11-14T11:40:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 30870 seconds ago)
2019-11-14T11:51:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 31500 seconds ago)
2019-11-14T12:01:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 32130 seconds ago)
2019-11-14T12:12:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 32760 seconds ago)
2019-11-14T12:22:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 33390 seconds ago)
2019-11-14T12:33:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 34020 seconds ago)
2019-11-14T12:43:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 34650 seconds ago)
2019-11-14T12:54:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 35280 seconds ago)
2019-11-14T13:04:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 35910 seconds ago)
2019-11-14T13:15:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 36540 seconds ago)
2019-11-14T13:25:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 37170 seconds ago)
2019-11-14T13:36:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 37800 seconds ago)
2019-11-14T13:46:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 38430 seconds ago)
2019-11-14T13:57:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 39060 seconds ago)
2019-11-14T14:07:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 39690 seconds ago)
2019-11-14T14:18:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 40320 seconds ago)
2019-11-14T14:28:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 40950 seconds ago)
2019-11-14T14:39:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 41580 seconds ago)
2019-11-14T14:49:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 42210 seconds ago)
2019-11-14T15:00:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 42840 seconds ago)
2019-11-14T15:10:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 43470 seconds ago)
2019-11-14T15:21:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 44100 seconds ago)
2019-11-14T15:31:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 44730 seconds ago)
2019-11-14T15:42:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 45360 seconds ago)
2019-11-14T15:52:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 45990 seconds ago)
2019-11-14T16:03:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 46620 seconds ago)
2019-11-14T16:13:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 47250 seconds ago)
2019-11-14T16:24:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 47880 seconds ago)
2019-11-14T16:34:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 48510 seconds ago)
2019-11-14T16:45:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 49140 seconds ago)
2019-11-14T16:55:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 49770 seconds ago)
2019-11-14T17:06:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 50400 seconds ago)
2019-11-14T17:16:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 51030 seconds ago)
2019-11-14T17:27:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 51660 seconds ago)
2019-11-14T17:37:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 52290 seconds ago)
2019-11-14T17:48:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 52920 seconds ago)
2019-11-14T17:58:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 53550 seconds ago)
2019-11-14T18:09:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 54180 seconds ago)
2019-11-14T18:19:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 54810 seconds ago)
2019-11-14T18:30:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 55440 seconds ago)
2019-11-14T18:40:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 56070 seconds ago)
2019-11-14T18:51:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 56700 seconds ago)
2019-11-14T19:01:54Z Potential stale tip detected, will try using extra outbound peer (last tip update: 57330 seconds ago)

this goes on until I decided just to shut down server after 24 hours and the .dat blockchain file was stuck at 16MB in size. Seemed like going nowhere.
submitted by Alchemy333 to Bitcoin [link] [comments]

MarcoPoloProtocol #2 #AMA Summary: #AMAwithKenny - How Marcopolo Protocol Designs a New P2P E-cash System?

MarcoPoloProtocol #2 #AMA Summary: #AMAwithKenny - How Marcopolo Protocol Designs a New P2P E-cash System?
On February 21, MarcoPolo Protocol hosted the second online AMA on MarcoPolo Protocol English Telegram group ( and they invited MarcoPolo Protocol Core Developer Kenny as our guest to answer questions from the community.
Here are the highlights from the AMA event.
#AMAwithKenny Question 1: Please introduce yourself to everyone, also, could you tell us what is MarcoPolo Protocol?
Hello everybody, I’m Kenny. I got into the field of blockchain at the end of 2016, mainly working on the research and development of public chain consensus protocols. At the moment, I’m a core developer of MarcoPolo Protocol.
MarcoPolo Protocol is an open-source blockchain protocol strategically invested by Softbank. It is a new peer-to-peer electronic cash system infrastructure and aims to achieve shared resources and intelligent inter-chain scheduling and contribute to decentralized applications with better scalability and lower transaction fees among the global blockchain networks.
#AMAwithKenny Question 2: Please describe the progress of your project in the past year.
From the perspective of funding and partnership, Marcopolo protocol was caught sight by Softbank last year and got Softbank investment, followed by being listed on the renowned exchange Kucoin. Its partners range from the global international electronic payment company Ksher , as well as a strategic partnership from several chains including fundamental developer forces and industrial resources.
According to the first step of the road map, gravity has been implemented. It is a central component, and currently supports the resource sharing of truechain and Ethereum
Based on gravity, DAPP Marcopay and POB community governance DAPP are implemented.
Building a technology community and interacting with developers through online AMA, discord, and riot has attracted many developers' attention to map.
At the beginning of the development of POC-1, the consensus, output block and RPC module of POC-1 are constructed based on the rule language.
In terms of product and applications, MarcoPolo protocol has already implemented a wallet application called MarcoPay, which is used widely in the community. Roughly 70,000 users and community members at the moment. And it's growing rapidly.
We have cooperated with a company named Ksher, a global electronic payment company. At present, payment in some stores has been implemented in Thailand.
We have developed communities of over 70000 people, covering South Korea, Nigeria, India, Vietnam, Indonesia, Turkey, Brazil, Australia, Russia. Also,our token has been listed on CoinMarketCap and Coingecko.
#AMAwithKenny Question 3: Compared to Polkadot and Cosmos, what are the distinct and innovative parts of MarcoPolo Protocol? Is it still necessary to develop other public chains?
Polkadot empowers blockchain networks to work together under the protection of shared security; Cosmos is a decentralized network of independent parallel blockchains and powered by BFT consensus algorithms like Tendermint consensus.
Similar to the other two projects, MarcoPolo Protocol could improve the scalability and interoperability of the blockchain network.
The main differences are the properties of shared resources and intelligent inter-chain scheduling. This is MarcoPolo Protocol’s innovation.After Satoshi Nakamoto proposed the p2p e-cash system, various public chains proposed a variety of solutions in order to accomplish the p2p payment without a third party. With the future popularity of digital encrypted currency payment and exchange, increasing TPS is highly demanded. Relying only on a single chain to process transactions would not significantly improve the processing speed. Therefore, more chains are needed to perform collectively in order to achieve TPS sharing.
MarcoPolo Protocol intends to provide a convenient and economical way of p2p payment while fully utilizing resources from different blockchains.
#AMAwithKenny Question 4: Why do you join MarcoPolo Protocol? What attracts you the most?
MarcoPolo Protocol is an open-source community, which is formed by a large number of blockchain open source technology enthusiasts and professionals. People applied their expertise and innovative ideas in many perspectives such as theoretical research, promotion, coding, system engineering, etc.MarcoPolo Protocol is committed to creating a new peer-to-peer electronic cash system that truly fulfills the vision of Nakamoto.
#AMAwithKenny Question 5: Can you tell us more about how MarcoPolo Protocol achieves resource sharing among chains? What is the mechanism to accomplish intelligent inter-chain scheduling?
Good questions, let me answer them together.
In terms of sharing resources across chains, in MarcoPolo Protocol, we select the appropriate synerchain as the target isomorphic chain to process transactions and then realize the TPS sharing of synerchains through the MTP protocol;
MarcoPolo Protocol selects a secure, efficient, and low-cost third-party public chain as the target heterogeneous chain, and then uses the computing power of the target chain to deal with transactions. The process requires the related interact-chain to interact with the target chain through BRPC and then moving applications and transactions to the target chain in order to finish the transactions. Therefore, the target chain is considered as Layer 2 and processes the transactions in MarcoPolo Protocol. In this way, the TPS capacity of the whole MarcoPolo Protocol network can be expanded by stacking multiple target chains.
Intelligent scheduling across chains is the core of MarcoPolo Protocol. We wish to build interactions across chains through MTP+BRPC, so as to solve the problem of inter-chain interoperability.
**#AMAwithKenny Question 6: As most people know, the ecosystem determines the future of public chains. How does MarcoPolo Protocol think about its ecological construction?**First of all, I highly agree with the significance of the ecosystem for public chains. We believe that there is a natural demand for payment, exchange, and borrowing of digital cryptocurrencies in the future.
MarcoPolo Protocol primarily targets three application scenarios: Dpayment, DEX, and Defi. We are building an E-cash system infrastructure that will serve the whole blockchain ecosystem.
In the electronic cash system, DEX and Defi are two important applications. Currently, DEX and Defi are structured in a single chain or ecosystem. We wish that DAPPs built on MarcoPolo Protocol could share DEX and Defi achievements of other ecosystems.
#AMAwithKenny Question 7: How many people in the MarcoPolo Protocol team?
Now the team has more than 30 people, more than 20 developers, 5 marketing staff, 7 operating staff, and distributed offices in many countries. They come from Singapore, Thailand, South Korea, China, Australia, Brazil, Indonesia, Turkey, and other countries.
#AMAwithKenny Question 8: What does the technical roadmap look like and what more is coming from MarcoPolo Protocol? At which development stage is it in right now?
MarcoPolo Protocol Road Map:The First Phase 2019.Q1Gravity: the interoperability module Gravity has been developed, which realized useable interoperability between third-generation public chain and high consensus digital currency such as BTC and ETH, will share computing power and performance gradually expand to more high-performance public chain through interoperability.The Second Phase 2019.Q3 Electromagnet: Online retail payment application - MarcoPay POB Community Governance DAPP.The Third Phase 2020.Q4Interaction: Independently developed MarcoPolo main Network StandardChain will be launched, achieving APoS, On-chain governance, Architecture design of InteractChain.The Fourth Phase 2022.Q2Grand Unification: The realization of heterogeneous cross-chain operability, resource sharing between chains. At present, core team members concentrate on the research and design the protocol. StandardChain is still in its early-stage proof of concept.
Also, during this stage, we launched MarcoPay DAPP. You can download it here and use it:
In addition, we are having an Airdrop activity right now (, you can join it and win MAPC and swap your MAPC to MAP on MarcoPay APP
#AMAwithKenny Question 9: MarcoPolo Protocol technical community has attracted developers from Bitcoin and Cosmos. Could you please talk about how to participate in the technical community?
MarcoPolo Protocol technical community encourages researchers, technology evangelists, and developers to participate. After the protocol passed through the PoC phase and was able to be implemented in modules, we definitely need more developers to join the community. After sorting out the research topics, we will share with everyone on the Discord and Riot channels in our technical community.Click the link below to join the community to know the up-to-date progress and take part in the discussion.Discord:
**#AMAwithKenny Question 10: Developers are essential to the development of the technical community. Could you please tell us what are the incentives of MarcoPolo protocol in this regard?**Regarding the motivation mechanism, as far as I know, MarcoPolo has set up a pool of 9% of MAP for incentives to the technical community. The incentives are mainly used in two aspects: technology and community.
Technology has three parts: research, technical promotion, and development;
Community includes online AMA, Meet-ups, Workshops, etc. MarcoPolo Protocol has been actively exploring ways to motivate great and talented people to get involved in this open-source project through different levels.
#AMAwithKenny Question 11: What’s the advantage of MarcoPolo Protocol’s APoS consensus? What are the advantages and disadvantages compared with PoS? And what problems APoS has solved?
APoS is an Assets Proof of Stake consensus algorithm. There are three advantages:
  1. It supports multiple digital cryptocurrency staking, more people can participate in the ecosystem
  2. it can protect assets, people are still keeping their original BTC or ETH, they just staked into APoS system
  3. It solves the problem of easy centralization in the traditional PoS/DPoS consensus mechanism
#AMAwithKenny Question 12: Are there any new products coming out soon?
Good questions, there is an exciting product coming up soon
We are launching a new build-in product Milione in 5 days.
I can share some of its features:
  1. You can deposit MAP to earn USDT
  2. The yield rate is higher than most of the products on the market
  3. No lock-up, you can withdraw your asset anytime you want
  4. Profitable referral mechanism, you can invite your friends and earn money with them together.
Besides products, there are many more partnerships coming up, we have reached many other famous companies and exchanges. Please stay tuned, once it is confirmed, we will announce it in this group and our twitter.
#AMAwithKenny Bonus Question 1: Is there anything you want to say on the MAP piece?
Let's wait and see
#AMAwithKenny Bonus Question 2: What payment scenario do you have so far? Where can I use it?
We have launched MacroPay DAPP, you can download it here:
This DAPP can manage digital assets on multiple chains simultaneously, providing a "safe, professional, decentralized" solution for global online and offline product payments. You can use MarcoPay to shop in some stores in Thailand, and more shops will support MarcoPay in Southeast Asia, South America, Africa, Europe, and other countries.
#AMAwithKenny Bonus Question 3: What payment scenario do you have so far? Where can I use it? What is Kenny’s opinion on the future for MacoPolo Protocol Token and what are the most difficult challenges he encountered during the development of MarcoPolo Protocol?
MAP is planning to open more than 1000 retailer shops to do peer to peer payment transactions in 2020 across Brazil, Turkey, Indonesia, Korea, and Thailand. MAP has a strong technical team including developers and researchers around the world to make sure the project will be delivered in high quality and in time.
#AMAwithKenny Bonus Question 4: What’s the business model of MAP? Is building another public chain? Or you want to charge fees for the applications hosting on the chain? How do you make the business sustainable and profitable in the long run? How much return you expect to be able to get in 2-3 years of time frame?
Marcopolo protocol p2p electronic cash infrastructure will enable Defi, Dpayment, Dex applications. Successful applications will help to boost the on-chain ecosystem under MAP infrastructure. And applications who make profits will feedback to the community in the means of MAP token only. We will make sure the community and application developers win-win together then we can achieve a long term success.
MAP since listed in Kucoin 3 months ago has already gained 4 folds. We are pretty sure the token price will go up further according to the current strategy.
Recent Activity:
Airdrop, join it on Telegram at
💰Per Participant: 200 MAPC
💰Each Invite: 50 MAPC
💰You can withdraw MAPC to your wallet instantly and swap MAPC to MAP on MarcoPay
⬇️Start Receiving Airdrops:
⬇️Download MarcoPay:
submitted by SamJia to MarcoPoloProtocol [link] [comments]

node information on explorers

I'm trying to set my first c-lightning node with docker-compose using image from currently, my node can connect and open channel with other nodes (and I can open a channel to the node just fine), but it's still not updated (ie. has no information) on most explorers.
the following is result of getinfo and listconfigs
getinfo { "id": "03db40337c2de299a8fa454fdf89d311615d50a27129d43286696d9e497b2b027a", "alias": "TestName", "color": "fff000", "num_peers": 3, "num_pending_channels": 0, "num_active_channels": 3, "num_inactive_channels": 0, "address": [ { "type": "ipv4", "address": "", "port": 9735 } ], "binding": [ { "type": "ipv4", "address": "", "port": 9735 } ], "version": "v0.7.1-906-gf657146", "blockheight": 601917, "network": "bitcoin", "msatoshi_fees_collected": 0, "fees_collected_msat": "0msat" } listconfigs { "# version": "v0.7.1-906-gf657146", "lightning-dir": "/root/.lightning", "wallet": "sqlite3:///root/.lightning/lightningd.sqlite3", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/pay", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/autoclean", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/fundchannel", "network": "bitcoin", "allow-deprecated-apis": true, "always-use-proxy": false, "daemon": "false", "rpc-file": "lightning-rpc", "rgb": "fff000", "alias": "HubTest", "bitcoin-rpcuser": [redacted], "bitcoin-rpcpassword": [redacted], "bitcoin-rpcconnect": "bitcoind", "bitcoin-retry-timeout": 60, "pid-file": "", "ignore-fee-limits": false, "watchtime-blocks": 144, "max-locktime-blocks": 2016, "funding-confirms": 3, "commit-fee-min": 200, "commit-fee-max": 2000, "commit-fee": 500, "cltv-delta": 14, "cltv-final": 10, "commit-time": 10, "fee-base": 0, "rescan": 15, "fee-per-satoshi": 1, "max-concurrent-htlcs": 30, "min-capacity-sat": 10000, "bind-addr": "", "announce-addr": "", "offline": "false", "autolisten": true, "disable-dns": "false", "enable-autotor-v2-mode": "false", "encrypted-hsm": false, "log-level": "DEBUG", "log-prefix": "lightningd(7):" } 
is there something wrong with this configuration? or is it another issue?
I understand that explorers update their node list irregularly, and as far as the node can open channels (and can be connected), everything is fine. but this thing has bugging me for weeks.
thank you~
submitted by 17hubest to lightningnetwork [link] [comments]

Logs of yesterday's dev meeting

 Dev meeting?  Would say so, yes  The people are still exhausted from the payment ID meeting :)  Guess we could ping some people  vtnerd, moneromooo, hyc, gingeropolous, TheCharlatan, sarang, suraeNoether, jtgrassie  Anyone up for a meeting?  Yep I'm here  Here  o/  Perhaps we should just start and people will eventually hop in?   oof   sorry guys, I'm working on the new FFS and I forgot all about this. Got a couple of new volunteers.   This literally might be able to launch tomorrow.  I know that. It's called "flow" :)  I could run if you're out of time?   go for it dEBRUYNE   you guys are going to like this new FFS. We're like 99% done.  Hi  rehrar: someone else do the milestone thing already?  All right, jtgrassie, perhaps you'd to start w/ briefly describing your most recent PR?   oneiric, xiphon did everything   like....everything  As far as I can see, it allows the user to push his transaction over I2P, thereby masking the origin IP of the sendeuser  great  And it hooks into vtnerd's PR right?  Sure. It basically just builds on vtnerds Tor stuff.  sorry dEBRUYNE  Really not much added.  I have it running and tested.  From the perspective of the user, what needs to be configured exactly?  Nice  Assuming the PR is included in the release binaries  I'm using knacccs i2p-zero duirng testing but will of course work with any i2p setup   sorry dEBRUYNE <= Np  Looks a little like dams breaking, now that we have some dark clouds over Kovri and people take matters into their own hands ...  User needs to run i2p, expose a socks service and and inbound tunnel.  Basically same as Tor  Okay, so should be reasonable as long as we write proper documentation for it (e.g. an elaborate guide)  rbrunner, yes, knaccc credit for jumping on i2p-zero really  dEBRUYNE: documentation monero side is kindof done. i2p side is very much implementation specific.  I suppose we could write some guides for the most popular implementations?  e.g. i2p-zero aims to be zero conf, but i2pd or Kovri would be differnet.  I see, great  vtnerd___: Do you want to add anything?  could amend the current kovri guide for monero use from --exclusive-peer to the new proxy support  Now I have i2p-zero running and tested with the #5091, I plan to jump back over to helping knaccc on getting that polished.  I added support for socks proxy in the basic wallets  ^ excellent  Yes vtnerd___ I havent tested it yet but looks sweet.  So connections to `monerod` over Toi2p are possible within wallet cli and wallet rpc  Awesome  This also implies auth+encryption even if ssl is not in use (when using an onion or i2p address)  All right  moneromooo: are you here? If so, could you perhaps share what you've been working on?  I am.  I revived the SSL PR, more stuff on multi sender txes, an implementation of ArticMine's new block size algorithm.  I presume a multi sender tx works similar to multisig insofar as the senders have to exchange data before the transaction can be performed right?  Yes.  There are 2 SSL PRs. What's the diff?  Theoretically this would also allow the sender to provide an output right? Which would be kind of similar to Bitcoin's P2EP  The second one adds some things like selecting a cert by fingerprint.  Yes.  (for the first sentence)  All right, awesome  For anyone reading, this breaks the assumption of the inputs belonging to a single sender, which makes analysis more difficult  Nice side-effect.  Much work coming for the various wallets to support that  rbrunner: Anything you'd like to share in the meeting btw?  Yes, just a little info  I have started to seriously investigate what it would mean to integrate Monero into OpenBazaar  I have already talked with 2 of their devs, was very interesting  In maybe 2 or 3 weeks I intend to write a report  Too early to tell much more :)  Soon^tm I guess :)  Yep  Currently wrestling with Go debugging  whole new world  moneromooo: Has pony recently shared any insights regarding the upcoming 0.14 release btw?  No.  All right  I would love to see the tor & i2p PR's merged sooner rather than later so we can get more testing done.  ^ +1  Isn't that famous early code freeze already on the horizon?  fluffypony, luigi1111 ^  I suppose I could provide a little update regarding the GUI btw  As always, lots of bug fixes and improvements :-P  selsta has recently added a feature to support multi accounts  dsc_ has revamped the wizard and will now start working on implementing the different modes and a white theme  dsc_ is working fulltime on the GUI already?  yes  :)   dsc_ is bae  In light of the recent payment ID discussion, we've also, by default, disabled the option to add a payment ID unless the user explicitely activates the option on the settings page  rehrar ^  nice   I spoke about this yesterday at the coffee chat, this is not a good decision.  How does it handle integrated addresses? The same way?  rehrar ?   For the next many months, we are still stuck with PAyment IDs in the ecosystem. Making it harder for people to access them will make Monero suck so hard to use for the average person for many months.  i agree with rehrar   Remove the option of Payment IDs when we remove Payment IDs  rehrar: The new GUI release won't be live until probably mid march though  Which is a few weeks in advance of the scheduled protocol upgrade   Payment ID removal comes in October   right, but Payment IDs are not removed in March  Did we not have loose consensus on removing the old, unencrypted payment IDs in march?   they are removed in October  We had discussed a deprecation in March  and a ban in October   ok, then if we are going to do that, we have to commit to it and contact the exchanges like Binance that use them and get rid of them in the next few months  (of unencrypted)   Binance is huge, and if they still use them, then people will be very upset that they can't deposit or use Payment IDs easily   I'm just speaking from a UX perspective.  I thought it was unencrypted in April and possibly encrypted in October  Yes I do agree  Timeline and notes:  impossible to remove them for march, many exchanges still use them  We can defer it to the 0.15 release if needed  Well, that wasn't the impression for them log that I just read today  This was all discussed in the earlier meeting linked above   We have to force the ecosystem off of Payment IDs before we remove them from the UI, is all I'm saying  Remove != make difficult to use  ... or make them more difficult there, right?  ping sgp_   sarang, I understand, and I agreed with you during that meeting. But then I started thinking of it as a UX person, which I am.   And that huge massive problem leapt out at me  i think making them difficult to generate is a good idea but making them difficult to consume and use is a bad idea  well, maybe not a good idea, but a better idea   ^  If we defer the decision to depriciate long payment IDs to october, won't we have the same issue then?  The UI can gave an expandable payment ID field like MyMonero and we can still call it deprecated   It is foolhardy to remove an option that the ecosystem uses. So I suggest we keep the Payment ID in the UI until October when they are completely banned.   no dEBRYUNE, because they will be banned via consensus  sgp_ imo it may be a misdirection of dev resources to add that since things are proceeding in the short term rather than long term  but this is a relatively minor point  Nothing matters til exchanges change  All right   The issue is that consensus will still have them in April, and exchanges won't upgrade because they are still allowed. Thus they must still be in the UI.  endogenic these changes are already merged in the GUI to hide it like you do  ok   But when they are banned, exchanges are forced to upgrade or stop using Monero, so we can remove them safely because they won't be in use  rehrar: that's a strong assumption   sarang that they will upgrade?  yes   if they don't, then they can't use Monero  If exchanges require pid, users need a way to set a pid. Making it hard for the user in the interim is just going to be a nightmare.   we have decided to take our "stand" in October  A way that is not too hard, then  To be clear, we still intend to deprecate long encrypted payment IDs in April right? But no enforcement until October   the term "deprecated" doesn't mean much if it's still allowed, and used in popular places   yes, as far as I understand it   jtgrassie, exactly  True I suppose  dEBRUYNE: we need to be more specific when talking about deprecation   the person who suffers is the user  There are two proposals for GUI deprecation:  1. Hide it in the send screen with a simple option to expand (currently merged iirc)  2. Hide it completely in the send screen unless users enable the field in advanced settings (PR'd but not merged yet iirc)  What are the arguments for 2?   Both are poor options, but 1 is better than 2 by a long shot   Well the people who need to be made to "suffer" are the exchanges. And I don't see a way to make exchanges "suffer" other than by having their suffering customers complain to them constantly that they need to update.  ^  CLI has something similar where users need to set a manual payment ID transfer mode. Not sure if it's merged yet   the way to make the exchanges suffer is when we ban PIDs. They either upgrade or don't use Monero.  exact;y  Agree with rerahr here  have exchanges been provided with clear, practical, sufficient technical upgrade plans for supporting what they're doing with PIDs but with subaddrs?    Both are poor options, but 1 is better than 2 by a long shot <= I wouldn't call 1. a poor option. Have you actually checked how it looks?  Because it states "Payment ID" and a user has to click on the + to expand the field  endogenic: yes the email when out. Blog post coming soon, but contains the same info as the email  also the exhcnages' users are often using wallets that don't support subaddresses  ok great   as well, it should be noted that the timeline for exchanges to upgrade is September, not October when the fork is.  Which wallets are that?  Rehrar: I don't see option 1. causing any issues/confusion  i guess it doesnt matter too much if withdrawing as a personal user the main address should suffice   Because September is when the new versions will be coming out without PIDs in the UI  If there's opposition to 2, 1 is fine. We can still call it deprecated which is the optics we need anyway   exchange users are often just using other exchanges lol. No wallets involved.   dsc_ dEBRUYNE, ok, I trust you guys here then  rbrunner: i was thinking mymonero last i heard  Ok  pigeons: rbrunner yes receiving on subaddresses won't be supported yet  sending to them has been possible though  and yes as learnandlurkin says often they withdraw to other systems like exhcnages that also dont yet support subaddresses  I really can't come up with any good argument for 2. right now  endogenic: seems not much of an issue then. Exchanges will typically support withdrawals to both subaddresses and plain addresses (especially if we are going to force them to use subaddresses)  For deposits, MyMonero works properly if the user sends to a subaddress  Actually the second solution was already merged:  Maybe not enough eyes watching :)   The important thing is to have done something to justify having a big "DEPRECATED IN APRIL" stamp on PIDs to spook exchanges in the interim  This was for solution 1:   The Monero Community Workgroup will start making noise everywhere we can to exchanges, and everywhere else that will listen. Try to get on those garbage news sites also.   So everyone knows that deprecated in April, and banned in September  Hey, for solution 1, write "Payment ID (optional, deprecated)" or similar there  rbrunner: noted  rehrar: probably wait until the blog post, but it should only be a few days   Maybe a Reddit sticky post would be useful?   With the blog post   If people are over freaking out about the hashrate  or terabyte blockchain :)  sigh  Any questions for the MRL side?  Is someone checking ArticMine's block size changes for weird behaviour in some cases etc ?  How would such testing work? Private blockchain?  I'm waiting on cost information from ArticMine to complete the model  Or just simulations?  Also, smooth suggested a mean rather than median for the 100000 block op. It would indeed be much nicer if it doesn't make the change worse.  You mean computationally or what?  Nicer ? Yes.  no sorting needed for mean  I'll add a separate sim for that  Well, just nicer. Forger the much.  Forger the Much sounds like the formal name of a Lord of the Rings character  :)  To close the payment ID discussion, in essence, we agree that we shouldn't make it difficult for the user to add a payment ID right (until 0.15 is released)  ?  I don't. I did make it harder.  In the CLI, somewhat other story, I would say  than the GUI  People there are used to juggle with options and CL parameters  rehrar: I recommend opening another issue to reverse 1866 and we can gather feedback on it there  Sounds good, to me at least   Dudes, if I do a Jitsi stream right now to show the new FFS in action, would you guys be interested in watching it?  I'd watch it, if the meeting is formally done  sure  yeah, can I start one and record it?   I'll give it in like fifteen minutes   I'll let you all know, stand by  I have a question on tx_extra if no one else has anything to talk about  People have said you can put arbitrary data in there in whatever format you want as long as you're willing to pay for it. However, do you need to mine the transaction for it to be included? I didn't think nodes would block transactions with arbitrary tx_extra data  It'll be in nodes' txpool when you relay it. A wallet could see it before it's mined.  moneromooo: will it be mined though?  by others  Is it valid ?  assume it's otherwise valid  Does it have a high enough fee ?  assume it does yes  I ran into conflicting information here:  Then it will probably be mined.  I once had the idea to put "my" MMS messages in there, looked at the code, and found no hard blocks for tx_extra data  That answer looks incorrect.  It is incorrect  If it will be mined, then that meets my assumption. There seems to be some misconception that people will not mine transactions with arbitrary tx_extra. I can add some comments there  And please don't spam it, and don't put fingerprintable stuff in it. It's meant to be here for *useful* stuff that's "uniform" enough.  It will be mined, whether a wallet *displays* the tx_extra is a different question.  I don't think any wallet currently displays that  it soes if its a pid  I think  Yeah, of course :)  Great, that answers my question 
submitted by dEBRUYNE_1 to Monero [link] [comments]

[DEVELOPMENT] Bitcoind IPV4 testnet port (18332) is failing to bind

[SOLVED] Thanks for everyone that have helped!

Hello everyone, this is a development problem that I'm currently having. Since the BTC Development sub is kind of inactive and I couldn't find any rule contraty to posting about BTC Development, I'll try my luck in here as I'm hopeless already. I've posted on BTC Stack Exchange but no answers also. Please, don't get me wrong, I'm trying to solve this problem for many days now, I've looked up everywhere for this.
I'm new to Bitcoin development and I'm currently having difficulties trying to make RPC calls from a Docker Container to a Bitcoin-Core daemon running in a SSH server. I suppose that the problem may be with Firewall or closed ports, but I also do not know much about Network settings.
I'm using nbobtc/bitcoind-php package to make the RPC calls with HTTP requests, and it is running in a Docker container. I'm sure the container is functional and is not the problem.
So here's what happening: when I run bitcoind in root user (but normal also won't work) in my SSH server, the IPV4 testnet port seems to be not opened. This message goes up when I run bitcoind:
Binding RPC on address port 18332 failed.
Here's what my bitcoin.conf looks like (I want to use testnet in here). I'm using Bitcoin-Core "subversion": "Satoshi:0.17.1".
server=1 debug=net txindex=1 testnet=1 rpcuser=userb rpcpassword=test test.rpcport=18332 # I've already tried allowing the IP these 3 ways: # rpcallowip=192.168.xx.xx # My machine's IP # rpcallowip=172.19.x.x/xx # Docker's NBOBTC container IP # rpcallowip= # Allowing all IP datadir=/home/bitcoin-dev/.bitcoin debuglogfile=/home/bitcoin-dev/.bitcoin/debug.log 
Here's what appears in debug.log right after I run Bitcoind:
2019-05-06T14:43:10Z Bitcoin Core version v0.17.1 (release build) 2019-05-06T14:43:10Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1 2019-05-06T14:43:10Z Assuming ancestors of block 0000000000000037a8cd3e06cd5edbfe9dd1dbcc5dacab279376ef7cfc2b4c75 have valid signatures. 2019-05-06T14:43:10Z Setting nMinimumChainWork=00000000000000000000000000000000000000000000007dbe94253893cbd463 2019-05-06T14:43:10Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation 2019-05-06T14:43:10Z Default data directory /root/.bitcoin 2019-05-06T14:43:10Z Using data directory /home/bitcoin-dev/.bitcoin/testnet3 2019-05-06T14:43:10Z Using config file /home/bitcoin-dev/.bitcoin/bitcoin.conf 2019-05-06T14:43:10Z Using at most 125 automatic connections (1024 file descriptors available) 2019-05-06T14:43:10Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements 2019-05-06T14:43:10Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements 2019-05-06T14:43:10Z Using 4 threads for script verification 2019-05-06T14:43:10Z scheduler thread start 2019-05-06T14:43:10Z Binding RPC on address port 18332 failed. 2019-05-06T14:43:10Z HTTP: creating work queue of depth 16 2019-05-06T14:43:10Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation. 2019-05-06T14:43:10Z HTTP: starting 4 worker threads 2019-05-06T14:43:10Z Using wallet directory /home/bitcoin-dev/.bitcoin/testnet3/wallets 2019-05-06T14:43:10Z init message: Verifying wallet(s)... 2019-05-06T14:43:10Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010) 2019-05-06T14:43:10Z Using wallet wallet.dat 2019-05-06T14:43:10Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin-dev/.bitcoin/testnet3/wallets/database ErrorFile=/home/bitcoin-dev/.bitcoin/testnet3/wallets/db.log 2019-05-06T14:43:10Z net: setting try another outbound peer=false 2019-05-06T14:43:10Z Cache configuration: 2019-05-06T14:43:10Z * Using 2.0MiB for block index database 2019-05-06T14:43:10Z * Using 56.0MiB for transaction index database 2019-05-06T14:43:10Z * Using 8.0MiB for chain state database 2019-05-06T14:43:10Z * Using 384.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space) 2019-05-06T14:43:10Z init message: Loading block index... 2019-05-06T14:43:10Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/blocks/index 2019-05-06T14:43:10Z Opened LevelDB successfully 2019-05-06T14:43:10Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/blocks/index: 0000000000000000 2019-05-06T14:43:19Z LoadBlockIndexDB: last block file = 161 2019-05-06T14:43:19Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=755, size=30875345, heights=1513309...1514061, time=2019-04-29...2019-05-03) 2019-05-06T14:43:19Z Checking all blk files are present... 2019-05-06T14:43:20Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/chainstate 2019-05-06T14:43:20Z Opened LevelDB successfully 2019-05-06T14:43:20Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/chainstate: 2686d59caeb1917c 2019-05-06T14:43:20Z Loaded best chain: hashBestChain=00000000b3b6a5db140b6058b7abe5cb00d8af61afd2a237ae3468cd36e387fa height=927391 date=2016-09-08T15:04:00Z progress=0.311180 2019-05-06T14:43:20Z init message: Rewinding blocks... 2019-05-06T14:43:29Z init message: Verifying blocks... 2019-05-06T14:43:29Z Verifying last 6 blocks at level 3 2019-05-06T14:43:29Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE]. 2019-05-06T14:43:29Z No coin database inconsistencies in last 6 blocks (500 transactions) 2019-05-06T14:43:29Z block index 19450ms 2019-05-06T14:43:29Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/indexes/txindex 2019-05-06T14:43:30Z Opened LevelDB successfully 2019-05-06T14:43:30Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/indexes/txindex: 0000000000000000 2019-05-06T14:43:30Z init message: Loading wallet... 2019-05-06T14:43:30Z txindex thread start 2019-05-06T14:43:30Z [default wallet] nFileVersion = 170100 2019-05-06T14:43:30Z [default wallet] Keys: 2005 plaintext, 0 encrypted, 2005 w/ metadata, 2005 total. Unknown wallet records: 1 2019-05-06T14:43:30Z Syncing txindex with block chain from height 694205 2019-05-06T14:43:30Z [default wallet] Wallet completed loading in 123ms 2019-05-06T14:43:30Z [default wallet] setKeyPool.size() = 2000 2019-05-06T14:43:30Z [default wallet] mapWallet.size() = 7 2019-05-06T14:43:30Z [default wallet] mapAddressBook.size() = 4 2019-05-06T14:43:30Z mapBlockIndex.size() = 1515581 2019-05-06T14:43:30Z nBestHeight = 927391 2019-05-06T14:43:30Z torcontrol thread start 2019-05-06T14:43:30Z Bound to [::]:18333 2019-05-06T14:43:30Z Bound to 2019-05-06T14:43:30Z init message: Loading P2P addresses... 2019-05-06T14:43:30Z Loaded 10420 addresses from peers.dat 36ms 2019-05-06T14:43:30Z init message: Loading banlist... 2019-05-06T14:43:30Z Loaded 0 banned node ips/subnets from banlist.dat 29ms 2019-05-06T14:43:30Z init message: Starting network threads... 2019-05-06T14:43:30Z net thread start 2019-05-06T14:43:30Z dnsseed thread start 2019-05-06T14:43:30Z addcon thread start 2019-05-06T14:43:30Z msghand thread start 2019-05-06T14:43:30Z init message: Done loading 2019-05-06T14:43:30Z opencon thread start 
After all that appears above, there are just "UpdateTip", "Requesting block", "received block" and "getdata" messages. (so the P2P port, 18333, works).

And here is when I netstat:

sudo netstat -nap|grep bitcoin|grep LISTEN
tcp 0 0* LISTEN 31185/bitcoind tcp6 0 0 :::18332 :::* LISTEN 31185/bitcoind tcp6 0 0 :::18333 :::* LISTEN 31185/bitcoind 
Thank you in advance!

PS: A few days ago I could make it work when running bitcoind with root user, but now even that won't solve the problem.
submitted by VicPietro to Bitcoin [link] [comments]

Groestlcoin September 2019 Development Release/Update!

For a more interactive view of changes, click here
In our current world; bordering on financial chaos, with tariff wars, Brexit and hyperinflation rife, you can count on Groestlcoin to consistently produce innovation that strikes to take the power away from the few and into the many, even after a full five and a half years of solid development.
Here is what the team has already announced in the last 3 months since the last development update:

What's Being Released Today?

Groestl Nodes

What am I?

Groestl Nodes aims to map out and compare the status of the Groestlcoin mainnet and testnet networks. Even though these networks share the same protocol, there is currently no way to directly compare these coins in a single location. These statistics are essential to evaluate the relative health of both networks.


Source - Website

Groestlcoin Transaction Tool

What am I?

This is a tool for creating unsigned raw Groestlcoin transactions and also to verify existing transactions by entering in the transaction hex and converting this to a human-readable format to verify that a transaction is correct before it is signed.



Groestlcoin AGCore

What am I?

AGCore is an Android app designed to make it easier to run a Groestlcoin Core node on always-on Android appliances such as set-top boxes, Android TVs and repurposed tablets/phones. If you are a non-technical user of Groestlcoin and want an Android app that makes it easy to run a Groestlcoin Core node by acting as a wrapper, then AG Core is the right choice for you.

What's Changed?

Source - Download

Groestlcoin Electrum

What's Changed?

Android Electrum-Specific

OSXWindowsWindows StandaloneWindows PortableLinux - Android
Server SourceServer Installer SourceClient SourceIcon SourceLocale Source

Android Wallet – Including Android Wallet Testnet

What am I?

Android Wallet is a BIP-0032 compatible hierarchial deterministic Groestlcoin Wallet, allowing you to send and receive Groestlcoin via QR codes and URI links.

V7.11.1 Changes

Groestlcoin Java Library SourceSource - DownloadTestnet Download


What am I?

Groestlwallet is designed to protect you from malware, browser security holes, even physical theft. With AES hardware encryption, app sandboxing, keychain and code signatures, groestlwallet represents a significant security advance over web and desktop wallets, and other mobile platforms.
Simplicity is groestlwallet's core design principle. Because groestlwallet is "deterministic", your balance and entire transaction history can be restored from just your recovery phrase.

iOS 0.7.3 Changes

Android v89 Changes

iOS SourceAndroid Source - Android DownloadiOS Download

Groestlcoinomi Released

What am I?

Groestlcoinomi is a lightweight thin-client Groestlcoin wallet based on a client-server protocol.

Groestlcoinomi v1.1 Desktop Changes

Groestlcoinomi Android v1.6 Changes

Groestlcoin Java Library SourceAndroid Source
Android DownloadWindows DownloadMac OS DownloadLinux Download

Groestlcoin BIP39 Tool

What's Changed?

Source - Download
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

A tour of the Gridcoin wallet

Hey guys, I thought I would put together an in-depth tour of the Gridcoin wallet software for all of our recent newcomers. Here I'll be outlining all the features and functions the windows GUI wallet has to offer, along with some basic RPC command usage. I'll be using the windows wallet as an example, but both linux and macOS should be rather similar. I'll be including as many pictures as I can as embedded hyperlinks.
Edit: Note that since I originally made this there has been a UI update, so your client will be different colors but all the button locations are in the same place.
This is my first post like this, so please forgive me if this appears a little scatter-brained.
This will not cover the mining setup process for pool or solo miners.
When you launch the wallet software for the first time you should be greeted with this screen.


After that prompt, you should be left sitting on the main overview tab with several fields on it.
From top to bottom:


Now onto the other tabs on the left side. Currently we're on the Overview tab, lets move down to the Send tab. This tab it pretty self-explanatory, you use it if you want to send coins, but I'll go over the fields here:
  • Pay To: Enter a valid gridcoin address to send coins too. Gridcoin addresses always start with an S or and R.
  • Label: Enter a label here and it will put that address in your "address book" under that label for later use. You can leave it blank if you don't want it in your address book.
  • Message: Enter a message here if you want it attached to your transaction.
  • Amount: How many coins you want to send.
  • Add Attachment: Leave this alone, it is broken.
  • Track Coins: This doesn't do anything.


Now down to the Receive tab. Here you should have a single address listed. If you double click on the label field, you can edit it's label.
  • New: Generate a new address.
If you click on an address, the rest of the options should be clickable.
  • Copy: Copy the selected address to your clipboard.
  • Show QR Code: Show a scan-able QR code for the selected address.
  • Sign Message: Cryptographically sign a message using the selected address.


The Transactions tab is pretty boring considering we have no transactions yet. But as you can see there are some sorting tools at the top for when you do have transactions listed.


The Address Book is where all the addresses you've labeled (that aren't yours) will show up.
  • Verify Message: Verifies a message was signed by the selected address.
The rest of the functions are similar to the functions on the Receive tab.


Onto the Voting tab. There wont be any polls because we aren't in sync yet.
  • Reload Polls: Pretty self-explanatory, I've never had to use this.
  • Load History: By default, the wallet will only display active polls. If you want to view past polls you can use this.
  • Create Poll: You can create a network-wide poll. You must have 100,000 coins as a requirement to make a poll. (Creating a poll does not consume the coins)
Here's what the Voting tab will look like once you're in sync


Now onto the context bar menus on the top.
Under File you have:
  • Backup Wallet/Config: This lets you backup your wallet configuration file just in case.
  • Export: You can export your Transactions tab or Address Book in CSV format.
  • Sign message: Does the same thing as on the Receive tab.
  • Verify message: Does the same thing as on the Address Book tab.
  • Exit: Close the wallet.
Under Settings you have:
  • Encrypt Wallet: Encrypts your wallet with a password. (we'll come back to this)
  • Change Passphrase: Allows you to change your encryption password.
  • Options: Opens the options menu. (We'll come back to this)
Under Community you have:
Under Advanced you have:
  • Advanced Configuration: Opens the Advanced Configuration menu. (Not so advanced if you ask me)
  • Neural Network: Allows you to view solo miners project statistics. It will be largely blank if you're not in sync yet.
  • FAQ: Don't touch this, It is broken.
  • Foundation: Don't touch this, It is broken.
  • Rebuild Block Chain: Starts the client syncing from 0. Don't worry, using this will not make you lose coins.
  • Download Blocks: Downloads the latest official snapshot, can help speed up syncing. The download progress tends to sit at 99.99% for a long time, don't worry, it's working.
Under Help you have:
  • Debug window: Opens the debug window. (We'll come back to this)
  • Diagnostics: Don't touch this, it is broken. This has since been fixed. You can use this to see if there is anything wrong with your setup.
  • About Gridcoin: Opens the About Dialog. This gives you your client version and other information.


Now back to the options menu under Settings > Options.
Here we have the options menu main tab:
  • Pay transaction fee: The transaction fee that will be automatically paid when you make a transaction.
  • Reserve: You can reserve an amount so that it will always be available for spending.
  • Start Gridcoin on system login: Pretty self-explanatory
  • Detach databases at shutdown: Speeds up shutdown, but causes your blockchain file to no longer be portable.
On the Network tab:
  • Map port using UPnP: Attempts to connect to nodes through UPnP.
  • Connect through SOCKS proxy: Allows you to connect through a proxy.
The window tab is pretty self-explanatory.
The Display tab is also pretty self-explanatory, with the exception of:
  • Display coin control features (experts only!): This allows you to have a great deal of control over the coins in your wallet, check this for now and I'll explain how to use it further down. Don't forget to click "Apply".


Now that all of that is out of the way. The first thing you'll want to do is encrypt your wallet. This prevents anybody with access to your computer from sending coins. This is something I would recommend everyone do.
Go to Settings > Encrypt Wallet and create a password. YOU CANNOT RECOVER YOUR COINS IF YOU FORGET YOUR PASSWORD.
Your wallet will close and you will have to start it up again. This time when it opens up, you should have a new button in the bottom left. Now if you want to stake you will have to unlock your wallet. Notice the "For staking only" box that is checked by default. If you want to send a beacon for solo mining or vote, you will need to uncheck this box.


Before we continue, Let's wait until we're in sync. Depending on your internet speeds, this could take from several hours to over a day or 2. This can be sped up by using Advanced > Download Blocks, but this can still take several hours.
This is what an in-sync client should look like. Notice the green check to the right of the Receive tab. All of these icons give you information when you hover your mouse over them.
The lock
The arrow tells you if you're staking. If you aren't staking, it will tell you why you're not staking. If you are staking it will give you an estimated staking time. Staking is a very random process and this is only an estimate, not a countdown.
The connection bars tell you how many connections to the network you have.
The check tells you if you're in sync.


Now I've said "stake" about a million times so far and haven't explained it. Gridcoin is a Proof of Stake (PoS) coin.
Unlike bitcoins Proof of Work (PoW), PoS uses little system resources, so you can use those resources for scientific work. PoS works by users "Staking" with their balance. The higher the balance, the higher the chance to create, or "stake" a block. This means you need to have a positive balance in order to stake. Theoretically, you can stake with any amount over 0.0125 coins, but in practice it's recommended to have at least 2000 coins to reliably stake.
Staking is important for solo miners, because they get paid when they stake. Pool miners don't need to stake in order to get paid however. So if you want to solo mine, you'll need to buy some coins from an exchange or start in the pool first and move to solo when you have enough coins.
In addition to Research Rewards for miners, anyone who holds coins (solo miners, pool miners, and investors) gets 1.5% interest annually on top of your coins. So it can be beneficial for pool miners to stake as well.
Here is a snippet of what a research rewards transaction looks like from my personal wallet. I have a label on that address of "Payout address" as you can see here.


At this point you'll need some coins. You can use one of our faucets like this one or this one to test coin control out.
First let me explain what a UTXO is. UTXO stands for Unspent Transaction Output. Say you have an address with 0 coins in it, and someone sends you 10 coins like I've done here. Those 10 coins are added to that address in the form of a UTXO, so we have an address with one 10 coin UTXO in it.
Now we receive another 5 coins at the same address, like so. Now we have an address with one 10 coin UTXO and one 5 coin UTXO. But how do we view how our addresses are split up into different UTXOs?
Earlier we checked the "Display coin control features" box in Settings > Options > Display. Once that's checked you'll notice there's another section in the Send tab labeled "Coin Control Features". If you click the "Inputs" button, you'll get a new window. And look, there's our 2 UTXOs.
All UTXOs try to stake separately from each other, and remember that the chance a UTXO has to stake is proportional to it's size. So in this situation, my 10 coin UTXO has twice the chance to stake as my 5 coin UTXO. Now wallets, especially ones that make a lot of transactions, can get very fragmented over time. I've fragmented my wallet a little so I can show you what I'm talking about.
How do we clean this up? We can consolidate all this into one UTXO by checking all the boxes on the left and selecting OK.
Now pay attention to the fields on the top:
  • Quantity: The total amount of UTXOs we have selected.
  • Amount: The total amount of coins we have selected.
  • Fee: How much it would cost in fees to send all those UTXOs (more UTXOs = more transaction data = more fees)
  • After Fee: Amount - Fees.
  • Bytes: How large the transaction is in bytes.
  • Priority: How your client would prioritize making a transaction with this specific set of UTXOs selected had you not used coin control.
  • Low Output: If your transaction is less than 0.01 coins (I think).
  • Change: What you will get back in change.
  • custom change address: You can set the address you get your change back at, by default it will generate a new address.
So let's fill out our transaction so we end up with 1 UTXO at the end.
In "Pay To:" Just put any address in your wallet, and for the amount put what it has listed in the "After Fee" Field. Just like this.
Notice how we get no change back.
Now click "Send", we'll be prompted to enter our passphrase and we're asked if we want to pay the fee, go ahead and click "Yes".
Now if we go back to the Overview tab we get this funky icon. If you hover your mouse over it, it says "Payment to yourself", and the -0.0002 GRC is the network transaction fee.
(Ignore the first one, that was me fragmenting my wallet)
Now if we look at the Coin Control menu, we can see that we've slimmed our wallet down from 7 UTXOs to 1.
Now why would you want to use coin control?
2 Situations:
  1. UTXOs less than 0.0125 coins cannot stake. So you can combine a lot of tiny, useless UTXOs into 1 bigger one that can stake.
  2. After a UTXO stakes, it cannot stake for another 16 hours. So if you have 1 large UTXO that is big enough to stake more than once every 16 hours, you can split it into smaller UTXOs which can allow you to stake slightly more often.
  3. By default, the wallet will always generate a new address for change, which can make your wallet get very messy if you're sending lots of transactions. Keep in mind that more UTXOs = larger transactions = more fees.
Sidenote - When you stake, you will earn all research rewards owed reguardless of which UTXO staked. However, you'll earn the 1.5% interest for that UTXO. Not your whole wallet.


A fork is when the network splits into multiple chains, with part of the network on each chain. A fork can happen when 2 blocks are staked by different clients at the same time or very close to the same time, or when your client rejects a block that should have been accepted due to a bug in the code or through some other unique circumstance.
How do I know if I'm on a fork?
Generally you can spot a fork by looking at the difficulty on your Overview tab. With current network conditions, if your difficulty is below 0.1, then you're probably on a fork.
You can confirm this by comparing your blockhash with someone elses, like a block explorer.
Go to [Help > Debug Window > Console]. This is the RPC console, we can use to do a lot of things. You can type help to get a list of commands, and you can type help [command you need help with] (without the brackets) to get information on a command. We'll be using the getblockhash [block number] command.
Type getblockhash [block number] in the console, but replace [block number] with the number listed next to the "Blocks:" field on the Overview tab.
This will spit out a crazy string of characters, this is the "blockhash" of that block.
Now head over to your favorite block explorer, I'll be using gridcoinstats. Find the block that you have the hash for, use the search bar or just find it in the list of blocks.
Now compare your hash with the one gridcoinstats gives you. Does it match?
If it matches, then you're probably good to go. If it matches but you still think you're on a fork, then you can try other block explorers, such as or
If it doesn't match, then you need to try to get off that fork.
How do I get off a fork?
  1. Just wait for an hour or two. 95% of the time your client is able to recover itself from a fork given a little time.
  2. Restart the client, wait a few minutes to see if it fixes itself. If it doesn't restart again and wait. Repeat about 4 or 5 times.
  3. Find where the fork started. Using the getblockhash command, go back some blocks and compare hashes with that on a block explorer so you can narrow down what the last block you and the block explorer had in common. Then use reorganize [the last block hash you had in common]. Note that reorganize takes a blockhash, not a block number.
  4. Use Advanced > Download Blocks.
  5. If none of this works, you can take a look at social media (reddit/steemit) and see what other people are saying.


Your configuration file depends on your operation system:
  • On Windows: %appdata%\GridcoinResearch\
  • On Linux: ~/.GridcoinResearch/
  • On MacOS: /Users/USERNAME/Library/Application/Support/GridcoinResearch/
And it should look like this.
If you open up your gridcoinresearch.conf, you'll see the default one it generated. Note that if you entered your email earlier, the first line will have your email on it instead of "investor". If you decided you want to solo mine but didn't enter your email when you first started the wallet, go ahead and put your email on the first line in place of "investor". If you're a pool miner, just leave it as "investor".
Next, it's recommended that you use the addnodes on the gridcoin wiki. So our gridcoinresearch.conf will look like this.
A useful line for solo miners is PrimaryCPID=[YOUR CPID]. Sometimes your wallet can pick up on the wrong CPID so it's good to have that in there if you're solo mining.


A listening node is a node that listens for blocks and transactions broadcasted from nodes and forwards them on to other nodes. For example, during the syncing process when you're getting your node running for the first time, you're downloading all the blocks from listening nodes. So running a listening node helps support the network.
Running a gridcoin listening node is simple. All you need to do is add listen=1 to your gridcoinresearch.conf and you need to forward port 32749 on your router.
If you don't know how to port forward, I'd suggest googling "How to port forward [your router manufacturer]".

QUICK LINKS Official Website Unofficial Website Block Explorer Block Explorer Faucet Faucet
Gridcoin Wiki
Gridcoin Github
Arikado Pool
And that's all I have for now!
I plan to keep this post up-to-date with changes in the client. So if anyone has any suggestions, have clarifications they want made, or maybe I got something wrong, then please feel free to leave a comment below or PM me!
submitted by Personthingman2 to gridcoin [link] [comments]

What is Bitcoin and How To Secure Your Bitcoin Wallet Bitcoin RPC Remote Code Execution Exploit for BitcoinCore 0.9-0.15.1 CVE-2017-9230 Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors HOW TO ENCRYPT AND DECRYPT WALLET How To Make A Secure BIP 38 Encrypted Bitcoin Paper Wallet ...

encryptwallet¶. encryptwallet "passphrase". Encrypts the wallet with ‘passphrase’. This is for first time encryption. After this, any calls that interact with private keys such as sending or signing will require the passphrase to be set prior the making these calls. Not in the current code. The way it works now, you have to make two RPC calls -- one to unlock the wallet for a period of time (walletpassphrase) and one to do the transaction (sendtoaddress).You can follow up with a command to lock the wallet immediately, if desired (walletlock).walletpassphrase <passphrase> <timeout> Stores the wallet decryption key in memory for <timeout> seconds. This page describes the algorithm used for encrypting the wallet.dat file used in the original Bitcoin client.. Wallet encryption uses AES-256-CBC to encrypt only the private keys that are held in a wallet. The keys are encrypted with a master key which is entirely random. A full "RPC Shell" as I call it, providing a commandline like interface to the bitcoin JSON-RPC API. Built-in SSH Functionality (not requiring outside SSH client or certificate app). That provides the following: (note SSH is disabled currently due to some bugs) Secure Encrypted Tunnel to the remote bitcoin host Full-Service Wallets¶. The simplest wallet is a program which performs all three functions: it generates private keys, derives the corresponding public keys, helps distribute those public keys as necessary, monitors for outputs spent to those public keys, creates and signs transactions spending those outputs, and broadcasts the signed transactions.

[index] [27082] [18856] [15071] [22704] [9990] [3598] [8843] [25023] [7163] [32711]

What is Bitcoin and How To Secure Your Bitcoin Wallet

bitcoin wallet, best bitcoin wallet, bitcoin wallets, bitcoin paper wallets, bitcoin wallet online, bitcoin wallet reviews, free bitcoin wallet, bitcoin wall... Bitcoin JSON-RPC tutorial. Handling JSON, entering parameters and receiving error messages. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U. Published on May 1, 2017 This is a video tutorial on how to encrypt & decrypt your PIVX Wallet. By encrypting your wallet, it will provide a layer of protection and safety; we would recommend you ... Bitcoin Hardware Wallet & Encrypted Secure Messaging and File Transfer by DigiSafeGuard ... Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - Duration: 8:10. m1xolyd1an 14,249 views. Bitcoin JSON-RPC Tutorial 5 ... Bitcoin-QT wallet review - Duration: 8:53. Secure Your Wallet 5,092 views. 8:53. Python Bitcoin Tutorial for Beginners - Duration: ...