Bitcoin Core :: Bitcoin

Aeon

Aeon (AEON) is a private, secure, untraceable currency. You are your bank, you control your funds, and nobody can trace your transfers.
[link]

What does "bin/bitcoin-wallet" and other binaries do?

I'm old, and haven't run Bitcoin Core since the 80's, when it was just bitcoind and bitcon-qt.
Can someone tell me what these files are and what they do, because a) they're not mentioned in the readme.md, and b) Google is absolutely useless for searches like "bin/bitcoin-wallet", returning patronising results like "What is a bitcoin wallet?"
bin/bitcoin-cli // command-line bitcoin client bin/bitcoind // bitcoin daemon bin/bitcoin-qt // gui client bin/bitcoin-tx // ?? bin/bitcoin-wallet // ?????? 
Thanks.
submitted by textreply to Bitcoin [link] [comments]

Adding Monero support to a P2P game, need some advice

Hello everyone,
I'm currently in the process of adding Monero support to a peer-to-peer game I've been working on and would like to ask this community for some advice.
The application has a few hard requirements that must be met:
  1. The Monero integration must be done using JavaScript (primarily for Node but browser's okay too).
  2. The application must be able to create addresses and accompanying private keys internally (no CLI or external API). Preferably, these should be derived addresses using a master or main one (like HD wallets in Bitcoin).
  3. The application must be able to generate raw transactions internally -- no CLI or or external API. For this part let's assume that the input UTXOs are going to be available somehow (from a database, for example).
  4. The application must be able to sign raw transactions internally -- no CLI or or external API.
When I say "no CLI", I mean no RPC wallet or daemon; no external API calls either.
Essentially, I should be able to do the above offline, using JavaScript only, and then just post the signed transactions later (this part can be done via CLI or API). These are core requirements for the project otherwise I'd just use RPC or a service and save myself a lot of work.
So my question is: is there a documented JavaScript library that supports all of the above functionality?
I found a project called mymonero-core-js which appears to do what I'd need, but there doesn't seem to be any accompanying documentation (the included unit tests don't offer much information). Does this documentation exist?
There's also an offline wallet generator but it's also undocumented and kinda unwieldy (one huge file).
The game (my project), already supports Bitcoin and Bitcoin Cash using these constraints, and I've done fairly extensive work with Ethereum, smart contracts, and crypto in general (not just cryptocurrencies, I mean), so I shouldn't need much hand-holding.
Thanks muchly in advance!
P.S. It's not my intention to advertise my project so I haven't posted a link but I'll be happy to share if anyone asks.
submitted by monican_agent to Monero [link] [comments]

Air-gapped z-addresses; Is ZecWallet an option?

I've heard of Zcash for a while, but it wasn't until recently that I tried my hand playing around with the daemon and wallets.
Obviously, there's no point in using ZEC if you're only using t-addresses, but my desire for a z-address capable wallet certainly narrows the choice of wallets available to me.
Running a full node is no problem for me; I'd like to take advantage of a GUI if possible though. For that reason, I am drawn to ZecWallet's full node version. But I'm still uneasy when it comes to key security. (Can anyone share their experience with the ZecWallet paper wallet generator?)
From what I gather there is no wallet with HD support for t-addresses, is that right? Not much of a concern for me because I am interested in the shielded pool. I just figured t-addresses would support Electrum-style seeds but apparently not?
Sapling addresses seem to be exactly what I want; in particular I am drawn to their reusability and ability to export the view key. I was hoping this would ease the process of securing and backing up my private keys.
Here's my key handling protocol I use for Monero:
1) Generate the wallet on an air-gapped machine
2) This gives you a mnemonic seed. I write that down and keep it as an analog backup. By using a passphrase in conjunction with the seed, I can effectively encrypt this paper wallet easily.
3) Export the private view key and address to an online machine and make a watch-only wallet. This lets my watching wallet see incoming transactions
4) When outputs are received, I have to export the list of outputs to the air-gapped machine. The air-gapped machine uses this data to make signed key images.
5) I export the key images back to the watching wallet. At this point, the watching wallet can see outgoing transactions.
6) Now I can create unsigned transactions with the watching wallet, sign them in the air-gapped machine, and transmit them via the watching wallet using my full node.
The major benefit of using Monero in this way is that I only have to make a human-readable backup of my wallet once and I'm set for life.
Obviously, Zcash is going to be a little bit different. Since the core client doesn't give us mnemonic seed phrases, that complicates backup a little bit. What's the best way to back up ZEC? If I keep an up-to-date backup of my wallet.dat is that all I need? Is there an option in the wallet to encrypt this backup as well, or do I need to accomplish that externally with the likes of Veracrypt? I must admit the idea of unencrypted wallet data being written to my disk makes me uneasy.
I see that there is an option in zcash-cli to import/export the view key of Sapling addresses. However, I can't see the option to do so in ZecWallet, and when I do so manually via the CLI nothing seems to be reflected in ZecWallet.
Is ZecWallet by its very nature an obligatory hot wallet, or am I missing some functionality in the wallet?
My end goal is to run a ZEC full node on Qubes and hold my coins in z-addresses. Qubes allows me to make virtually air-gapped VMs to greatly simplify key management.
So for example when I use Bitcoin, I have a networked VM that runs a Bitcoind + Electrum Personal Server + Electrum Wallet stack, where I import my master public key. When I need to sign a transaction, I spin up a networkless VM equipped with Electrum and my private keys. Qrexec let's me easily ferry unsigned/signed transactions back and forth between the two VMs. Overall this provides a decent UX with above-average security and privacy. I'd like to port this general setup to Zcash.
To do so, I need a GUI wallet that supports both z-addresses and public/private key splitting. Does such a tool exist? (Can Electrum Personal Server be ported to ZEC?) If not, how can I streamline this process with the CLI?
I'm more familiar with Monero than Bitcoin, so the Zcash/Bitcoin CLIs are still a little foreign to me, though I am not "afraid" of CLI wallets in general. My Cryptonote muscle memory makes me prone to annoying little syntax errors I'd much rather do without.
My plan is to buy ZEC from Coinbase Pro, withdraw to a t-address, and then sweep my coins to a z-address. I want to monitor the balance of both t-addresses and z-addresses (and later send transactions) without ever exposing my private keys to the Internet.
However, it seems like the Zcash CLI is my only viable option for z-address watching wallets. Should I just play around on testnet until I get more familiar, or is there a GUI wallet solution out there that fits my needs? Does anyone have a cheat sheet for doing this via the CLI that could help me along the learning curve?
TL;DR New to Zcash, need advice as it relates to wallet backup, watching wallets, and z-addresses.
Assistance is much appreciated!
Edit: I don't suppose there's a way to use a Trezor Model T with a full node and or z-addresses?
submitted by spirtdica to zec [link] [comments]

Is there any guide or tutorial for the using the headless wasabi daemon correctly ?

Hello again,
The documentation of the daemon in vague and not detailed as the rest of the documentation.
Is there any guide or tutorial for the using the daemon correctly ?
How do I set/specify exactly the destination wallet ? and what if I want the destination wallet to be a bitcoin core wallet ? how can I achieve this ?
If there is an example like the one in the documents, it will be very helpful.
submitted by scottcarter2020 to WasabiWallet [link] [comments]

Transaction confirmations

Under bitcoin-core, when one fires the command:bitcoin-cli listreceivedbyaddress 1 true
The output is something like:
[ { "address": "address-goes-here", "amount": 10.00000000, "confirmations": 10, "label": "label1", "txids": [ ] } ] 
What is the equivalent command for Ethereum (geth)? I just need to know the number confirmations for an ethereum address while it is receiving coins.I am running the daemon with indexing.. currently testing on rinkeby.
submitted by sonoobest to ethdev [link] [comments]

Marchero

With two cryptocurrency integrations under my belt I've set out with a solid plan for Monero.
Instead of jumping in and figuring it out as I go along I want to make sure that I have the solutions I'll need, well defined and scoped out. It's a good thing I'm going this path, too.
Turns out that there isn't really much in the way of JavaScript code for Monero out there. Probably the two best (and possibly only), solutions at the moment are monero-javascript and MyMonero.
Although there's no official Monero JavaScript library, the monero-javascript project is probably the closest to the original C++ client. This derived code comes in the form of WebAssembly, a low-level language that runs a lot closer to the metal than JavaScript. This means that WebAssembly is generally faster when doing things like calculations, but with some trade-offs like ease of use. JavaScript is a lot easier to code and understand, but it tends to run slower. In modern browsers, both run side by side so developers can decide which parts need to work fast, and which parts need to be easier to change and maintain.
The MyMonero project is actually a set of supporting libraries for a Monero wallet. It seems to have a lot more "real world" mileage but has a smaller dev team and hasn't been updated for many months, unlike monero-javascript which was updated as recently as today. MyMonero also uses WebAssembly for some of the core wallet functionality but the "bindings", or how this functionality is exposed to JavaScript, are different.
Between the two solutions, I've had more luck in getting support for monero-javascript. Neither project is well documented so having someone to run questions by is, at least at this point, a winning feature.
This will be my first time working with WebAssembly so factoring in some learning time is prudent. I'll only be learning to use existing code rather than learning how to write it but still, it's a new thing for me.
As I mentioned, support for Monero via JavaScript is surprisingly rare, so I may end up contributing some original code back to the project(s) I'll be using. I haven't yet decided which of them will find its way into CypherPoker.JS because there are still some open questions about how certain things are done and if they're even possible. However, right now monero-javascript is looking like the best choice.
Once I'm satisfied that all the building blocks are viable, I'll add the cryptocurrency handler and integrate it all the way through to the front end. As with BTC and BCH, a Monero testnet option will be available along with a faucet so that you can test it out without using any actual XMR. A full client option that uses the downloadable monerod client, the equivalent of a full Bitcoin node, will be available alongside the "light" option which will use external APIs. After that I'll upgrade the live demo (and server), update the wallet generator, post v0.5.2 code documentation, create a new release, and write a wrap-up post.
I want to stress again that this is all contingent on whether or not the JavaScript libraries actually do what I need them to do, and if there exists at least one public API that can be used in place of the daemon (monerod). But based on the help I've received from the Monero community so far I'm feeling optimistic.
Probably the most interesting thing about the Monero integration is that it represents the final, Rumsfeldian, "known unknown" of the CypherPoker.JS project. It's the last thing I'm embarking on with essentially zero prior knowledge; I know that I know nothing.
The rest of the project, the other cryptocurrencies, smart contracts, peer-to-peer communications - those are all things I'd at least had an introduction to if not outright practical knowledge of. When it comes time to add Ethereum support I'll be able to confidently say that it's nothing new. Incorporating Tor anonymization ... been there, done that.
When it comes to Monero, though, I'm a wide-eyed ignoramus. Never owned any XMR, never ran a Monero wallet, never tried out a Monero block explorer; seems I'm even getting some of the technical terminology wrong. Basically, it's the last part of the project's core vision that comes with a steep learning curve and a not-insignificant chance of failure. I mean, I don't think I'm gonna fail but I can't point to any definitive reason why I should think that.
There's no pragmatic reason to believe that March and (the) Monero (integration) will be contemporaneous but then again, why not?
submitted by monican_agent to cypherpoker [link] [comments]

CyberWay White Paper

Introduction
Since the development of the first so-called “blockchain” database named“Bitcoin”, complex transaction behavior was a “Holy Grail” for people wondering how they could pay, bet, play, and even order pizza with such assets.
The first complex transaction logic implementation was made available right in “Bitcoin” with a stack virtual machine providing a limited set of operations for the end-user to make some fun with it. Fine example is an Omni-layer built on top of the operations set, which end-user intention is to provide creation and usage of the custom user-defined assets. Such a system successfully fulfilled contemporary requirements for liquid asset transfer. Unfortunately, such an application logic usage rapidly overflowed the throughput available, so no mass adoption happened.
Another attempt to provide the customizable complex transaction behavior was made with the creation of “Ethereum”, which provided an unnecessarily created from scratch programming language called“Solidity” for the creation of even more complex application logic, hoping it would not overflow the database throughput. Obviously this leads to another failure. Primal language and naive database architecture understanding did not survive the reality check - in 2017 the protocol was literally down with CryptoKitties hype.
The scalability troubles got up again, so another popular solution was rapidly proposed. Its name was EOS. The solution was to split the computable transaction complex behavior and to process it with the set of cluster nodes, which were called “block producers”. This lead to the entrustment of an enormous responsibility to these “Block producers”.They were now not only about data storage providers, but also computation providers. Now, these guys not only store and process your data, but they even define the way your transaction behaves itself, define if they allow such a transaction to be written or not. Furthermore, such an “improvement” lead to the unacceptable database node hardware requirements, which made the support truly awful. Moreover, such a split was not enough for building production-ready applications - who would like to find out if the upvote transaction, which was even payed for, was at first queued and then rejected?

Proposal
CyberWay is a decentralized application platform that addresses and overcomes the shortages mentioned above.

EOS-compatibility
CyberWay is an upgraded fork of EOS. So, the backward compatibility is held. The code contains most of the tolerable EOS parts, but excludes the awful ones. So-called“Smart Contracts” API backward compatibility is held too, but the insides have changed. That means every EOS application could easily become theCyberWay-based one and vice versa. Enough of that. Next.

Bandwidth
EOS’s bandwidth distribution is closely related to the amount of asset the particular user owns. Furthermore, it requires for the user to hold the asset to be available for the usage at any time. That means the asset becomes a highly valuable, but also it becomes the non-available for the newcomers one. So no newcoming applications are welcomed to be built with EOS.
Striving to eliminate these inconveniences Cyberway introduces some changes.
The bandwitdh accounting is split to the couple of categories:
  1. Priority-based bandwidth allows a user to get required computational facilities according to the amount of core-asset available.
  2. Shared bandwidth supplies users with the unused computational power according to the particular user activity.

State Storage
EOS’s state storage is extremely unreliable and does not ensures that data is saved and restored after restart correctly. Furthermore, EOS does not provide any convenient API, but supposes the data structure stored inside would be complex. CyberWay solves these troubles. CyberWay uses the external DBMS for the state storage, which means the particular developer favorite query language can be used and the external well-designed replication and clusterization mechanisms, done by real engineers and scientists, are also about to reduce the hardware costs and make life easier.

Event Engine
Because of the storage internals being factored out the separate service, the additional transaction content-based event engine implementation is required. It is now impossible to alert the CyberWayexecutable from the various database if something happened or not, just like it was in EOS. Monitoring-purposed event engine, implemented as apart of updateable application, takes back the ability to track changes coming with every transaction, even if the data storage is completely outside.

Virtualization
Just like EOS, CyberWay requires for the transaction behaviour to be updated easier, than updating the whole cluster software. That is why the WebAssembly engine is used for the virtualization purposes and withC++ as primary language for the application development.

Separation
Why don’t just patch EOS? Several troubles are about the data itself, and not the code:
  1. EOS’s architecture made the memory quant an expensive one: according to the https://eosrp.io the cost of such a memory quant fluctuates from \$0.2 to \$0.5. That means any transaction-intensive application (e.g. some social applications) with even a quite small amount of active users (e.g. 2000-3000) would take at least 400MB per week, which would cost up to \$200,000.
  2. EOS’s custom transaction behavior is stored inside the huge hash-table allocated over a shared memory and the access is provided with an interface, based on quite sophisticated executable logic, which also costs.
The obvious solution - to make a cache service and process the data all inside it - is also quite a task because:
  1. The so-called “Constitution” of EOS defines the largest time interval available for the unused data to be stored with the same ownership as 3 years. This is quite unacceptable with some kind of applications (e.g. social ones) demanding data availability from the very beginning, but the changes are hard to make because lots of other application types are perfectly fine with this.
  2. EOS is made to produce replication packages as fast as it can - about half of a second. Such a frequency is fine for marketing purposes, but it significantly reduces the complexity of custom transaction logic. This is also unacceptable.
  3. Reduced amount of validators - only 21, and no significant increase is expected because of EOS protocol restrictions.
  4. Censorship availability for validators implemented right in the protocol core.

Applications
Applications are welcomed to use the following.

Shared Bandwidth
Shared bandwidth sets a limit for the user activity based on its’ staked asset amount, but no less than some basic threshold. This is required to prevent spam to database from the newcomers, and redistribute more computational resources to the successful application developers.
Shared bandwidth is accounted separately for the network, RAM and CPU usage.
Coming to accounting - this is done with particular application bandwidth balance, which shares the convenient part for the user performing the transaction. That is why this is called “Shared”bandwidth. The application is a multi-signature account, which requires at least one additional signature from the particular user, for its bandwidth to be used.
This type of bandwidth allows CyberWay to provide applications with free on-boarding of users at early stages via CyberWay Acceleration Program. Later successful application could get CYBER tokens within Acceleration Program from special fund.

Priority-Based Bandwidth
Priority-based bandwidth is required for the user to surely write the transaction. It is formed with the amount of core asset staked by the particular user and guarantees the transaction gets written right at next replication time. The whole amount of staked core asset forms the bandwidth market.
Each account gets a share from the whole bandwidth market according to the amount of core asset the account has staked. Considering the case some user-owned and staked the significant part of the whole bandwidth supply means the reduction of the resources available for other users. This is definitely not something requiring applications want.
That is why CyberWay introduces the prioritization of the bandwidth. That means the bandwidth gets split to a couple of categories:
  1. Guaranteed bandwidth, which works exactly as EOS’s one.
  2. Priority bandwidth, which is defined according to the particular account priority.
How does account earn the priority?
There are couple of ways:
  1. Perform less transactions using the currently available guaranteed bandwidth. The priority lowers as more transactions gets put inside with a single user.
  2. Stake more core asset. The guaranteed/prioritized bandwidth split ratio is set by the cluster validators.


Memory Rent
Cluster RAM is something the applications require to work. In contrast to EOS, CyberWay supposes the RAM to be rented from so-called block producers, but not to be owned. The rules are the following:
In case the memory rent time is up, but there is still some user data stored inside, the archive operation is introduced. Block producers are in charge of initiating such an archivation and the restore is available for the user for the price median-valued among block producers.

DBMS-based State Storage
In spite of existing so-called “blockchain” databases, CyberWay does not intend to implement the database management software and uses the external DBMS as a state storage for more reliability. For now, only MongoDB is available, but in case of requirements, more are coming. Sucha configuration considered to be troublesome for managing, but more reliable in long term. Embedded state storage is also available in CyberWay. RocksDB is used for the in-memory and in-daemon storage management component that is faster thanMongoDB.

Event Engine
As the state storage engine is incapsulated and factored out of the controller daemon, the event engine is implemented as a helper application, synchronizing and managing the data in external storages.
The input of such an application is a transaction set, each of which gets registered as “processed” and only after this the data are unpacked to state storage.
Such an approach allows to make sure the routine data operations are processed as required and to split the data managing daemon to single responsibility micro-services.

Domain Names
Every created account is not identified with a key as other databases do, but it gets a unique 8 byte identifier encoded in base32. Also a human-readable 63 byte length unique names are available for the assignment for every user. In case of the amount of such names is greater than one, it gets charged and called a “Domain Name”.
Every domain name can be auctioned from base protocol or created by owner of a lower-level domain name. Domain names are transferable and reassignable. Therefore, a need for conversion between a domain name and account identifier gets satisfied with a newly introduced sufficient mechanism much as need for domain transactions. Domain transactions are transactions which get applied to the data only related to the particular domain-name/application.

Protocol Properties
Protocol properties are also got changed comparing to EOS’s ones.

Block Generation
First of all, block generation time is increased for achieving more stable node replication. EOS’s 0.5 second block replication time is fine for most application in case of all the nodes are located in the same datacenter. But for truly distributed protocol, this requires to be increased due to increased network latency. CyberWay supposes the block replication time to be 3 seconds.

Block Producers
Block producers are the key members of a protocol. They keep the database safe and consistent and get rewarded for that.
In spite of EOS’s 21 default block producers, in CyberWay the number of block producers is to be increased up to 101 in the future. This is required for more decentralization to be achieved.

Consensus Algorithm
CyberWay consensus algorithm is heavily inspired by Tezos’ and Cosmos’ one. So, active users are rewarded for voting and non-active users are punished for not voting.
Every account is allowed to vote for several validators with staked tokens.
Block producer’s weigh is determined as follows: w = m / sqrt(S), where m is a number of votes for any particular candidate, S is a total number of votes for any particular candidate (or number of stakes tokens as 1 vote is 1 token).
A particular block producer receives a reward from the emission and redistributes a share of it among his supporters. In case of misbehavior, e.g. a block omission, the block producer as well as his supporters are fined. The staked tokens are burned. This novelty makes block producers more responsible, and voters more careful and thoughtful.
The block producers get a share of emission. The share depends on the total amount of staked tokens. The more tokens are staked, the less inflation is. Thus, the CyberWay has in-built incentives for users to participate in governance via voting. Moreover, the passive users are diluted as they do not get any rewards from validators.
What if some user considers another user to understand better, which block producer is the best service provider? This gets covered by CyberWay with a proxy mechanism which ensures that some user could delegate his own assets to another user called “Proxy”. The proxy user gets fees for its service.

Censorship
In contrast to EOS, CyberWay completely removes any inequality between the users. There are no privileged accounts, no so-called “Constitution”, no blacklists.

Workers
Workers are the mechanism first introduced in BitShares. These are users, who get their issuance share for making improvements for the protocol. The improvement can be registered and referenced by any user, particular improvement to resolve is selected via voting by validators.

Conclusion
CyberWay is a fork of EOS, specified to handle more complex applications with more decentralization available. Workers are considered to be the most powerful tool for decentralized protocol improvements. The scalability and performance CyberWay introduces is fine enough for running complex social applications or financial service applications or gaming applications. The absence of censorship and privileged accounts makes CyberWay more decentralized than EOS, while introduced technical features enable developers to build advanced applications on top of it.
submitted by maxsam199 to Cyberwayio [link] [comments]

AMA/Tutorial: Run a full node on AWS free tier with local LAN storage

AMA/Tutorial: Run a full node on AWS free tier with local LAN storage
This is a tutorial/AMA on how you can be running a full node, in the AWS cloud, for very low cost or even free.
I used to run a node on my local network but there is a problem with this; your public IP is broadcast, and then it gets associated with Bitcoin. Node owners are likely to own Bitcoin, and this raises your personal threat profile, validated against my IDS/IPS logs.
Run a VPN? Many VPNs are automatically blocked, or sketchy. Tor is also blocked on a large portion of the internet. Neither provide you with a real static IP, and that helps out the network.
There is a easy solution to this; run a node on the AWS free tier, and use an elastic IP so you have a static address. Bandwidth is free in, and low cost out, and you can control how much of that you use easily, and control your spent. The problem is that Amazon charges a LOT for online storage and even with a 1MB blocksize, the blockchain is very large and growing steadily! We mitigate this by using a VPN back to your network, where you can store the blockchain on a SMB share.
It is not complicated to do, but there are very many moving pieces to keep track of and configure. In order to fully trust your node, the best way is to build it from scratch. This is my goal in walking you through the process.
There are lots of ways to accomplish this same task; I only want to present one that works, and you can go from there. Once you have access to the blockchain in the cloud for reasonable prices, you can also look at things like the Lightning Network.
This article makes four major assumptions:

  1. That you have a OpenVPN server on your network and know how to configure it. I use pfSense and OpenVPN; others will work just as well, but you'll need to do a little work to figure out the particulars. If you don't know how, do not fret! There are loads of good tutorials for just about every platform. Or ask below. I also limited the user with access to the share at the firewall specifically to the IP hosting the share to lower the threat envelope.
  2. That you have the blockchain downloaded locally and reasonably up to date. If you don't, head on over to bitcoin.org and download it for OSX or Windows or Linux, whatever you use for your workstation. Follow the directions to set up the software and download/synchronize it to the network. This will take awhile! Once you've synchronized, copy the data directory to your SMB share you want the AWS instance to access. You could also synchronize everything directly on AWS too, but it will likely take longer and may cost a bit for the bandwidth.
  3. That you're on windows. OSX and Linux will have slightly different processes to connect to the instance via the terminal and SSH. If you need help, ask, and I am sure we can get you fixed up.
  4. That you've read the excellent bitcoin.org full node tutorial here: https://bitcoin.org/en/full-node

With that, on with the show!
First: Head on over to https://aws.amazon.com/ and make yourself an account.
Once you've set up you'll need to start the process of creating a virtual machine on AWS. Look for this graphic and click on it:

Start by launching a new machine

Follow the rabbit hole, and you'll be looking to create a plain jane Amazon AMI Linux instance. It looks like this:

Pick the basic AMI instance
Keep in mind you want to pick the x86 version, which is the default.

Continue clicking, you'll want to select the t2.micro instance that is eligible for the free tier for new accounts.

Pick the free tier. You can also upgrade to the smaller tier for more ram, but the micro works for now.
Now, you're going to need a way to connect to your soon-to-be-created node in the cloud. Amazon uses SSH keys to do this, so the next step means you're going to make some. You need to save this file, as if you lose it, you won't be able to access your node anymore. Much like your wallet private keys!

Beware losing your keys!

If you've made it this far, you're almost launched!
Now we need to convert the key to a format that we can use to connect to the instance from Windows. I recommend using Putty! https://www.putty.org/ if you don't have it already; if you're on OSX or Linux, you likely have what you need already.
Follow the guide here to get connected: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

Next you'll need to set up a opening in the firewall if you want incoming connections. This is done by adding to the security group in the "Network and Security" section; edit it to look like this:

Change the inbound security rules for the instance to accept incoming connections on 8333.

The hard part is over!
Optional: Configuring a static IP. Amazon calls their implementation "elastic" IPs, but it's really a static IP that you can move around between instances very easily. It will ensure your public address on AWS does not change; it isn't required, but it is better if you intend on allowing outgoing connections.
Go back to the main dashboard display.
In "Network and Security", click on "Elastic IPs".
Select Allocate New Address (blue button on top) and then select it in the table. In actions, you will see "Associate Address". Select this then assign the address to the instance you have previously configured. Done!

Next up: Log into your machine, and immediately update everything. Use the IP provided by Amazon, or the Elastic IP if you assigned one to the instance in the last step.
type: "sudo yum update"

Now, let's get the VPN configured.
First step is to install OpenVPN. We need to install the extended package library to do this.
type: "sudo amazon-linux-extras install epel"
type: "sudo yum-config-manager --enable epel"
Now you can install OpenVPN.
type: "sudo yum install openvpn"
You will need your credential file from OpenVPN; it's a file you generate that will have a .ovpn extension. But you're going to need to upload it to the instance. You can do this through the scp command on OSX or Linux, but if you're on Windows, you'll need another utility. Get WinSCP here: https://winscp.net/eng/download.php
But we'll have to tell it where your key file is so you can login. Select "New Session", then use the same IP and username as you did to connect before. We'll need to tell it about the key file though! Select the "Advanced" tab then under the SSH section, click on "Authentication" and then select your private key file you generated in the tutorial above.
Connect and upload the .ovpn file that you generated when you added a user for the VPN. This step depends on your OpenVPN configuration - ask below if you have problems.
Next, let's verify we can connect to the VPN!
type: "openvpn --config my-configuration-file-made-by-openvpn.ovpn &"
You will be prompted for a password if you configured one.
Verify operation by pinging your LAN router, e.g.
type: "ping 192.168.2.1" or the address of the SMB server where you shared the information.

Allllrighty! Next up is getting connected to your blockchain. Create a directory where the data directory will be mounted.
type: "mkdir blockchain"
We need to install samba and some utilities to get things mounted.
type: "sudo yum install samba"
type: "sudo yum install cifs-utils"

Now let's mount the folder:
type: "sudo mount -t cifs //192.168.2.100/Bitcoin ./blockchain -o user=bitcoin,vers=2.0,uid=ec2-user,gid=ec2 user,file_mode=0777,dir_mode=0777"
Where " //192.168.2.100/Bitcoin" is the address of the SMB server and share where you put the data directory from your initial sync. If you didn't, and just want to sync everything from AWS, then make sure it's a folder where your user has access. In this case, I'm assuming you've made a SMB user with the name "Bitcoin". The command will prompt you for the password to access the share. The other bits ensure you can have read and write access to the share once it's mounted in AWS.

Now we're ready for some Bitcoin! Props to the tutorial here: https://hackernoon.com/a-complete-beginners-guide-to-installing-a-bitcoin-full-node-on-linux-2018-edition-cb8e384479ea
But I'll summarize for you:
Download and then re-upload with WinSCP, or download directly to your instance with wget, the most current Bitcoin core. In this case, it's bitcoin-0.18.0-i686-pc-linux-gnu.tar.gz downloaded from https://bitcoin.org/en/bitcoin-core/.
Let's verify it hasn't been tampered with once you have it uploaded to the terminal:
type: "sha256sum bitcoin-0.18.0-i686-pc-linux-gnu.tar.gz"
Then compare that with the hash value that's listed in the SHA256SUMS.asc file on bitcoin.org. In this case, "36ce9ffb375f6ee280df5a86e61038e3c475ab9dee34f6f89ea82b65a264183b" all matches up, so we know nobody has done anything evil or nefarious to the file.
Unzip the file:
type: "tar zxvf bitcoin-0.18.0-i686-pc-linux-gnu.tar.gz"
There is a warning about a symbolic link; everything seems to work OK regardless, but if anyone knows what or how to fix, please comment.
We'll need to get some missing libraries before we can run it; these aren't in the basic AMI instance.
type: "sudo yum install glibc.i686"
type: "yum install libgcc_s.so.1"

FINALLY! We are ready to launch the program. Go to the "bin" directory inside where you unzipped the Bitcoin Core tarball. (e.g. /home/ec2-useblockchain/bitcoin-0.18.0/bin)
./bitcoind -datadir=/home/ec2-useblockchain/data
You will see the program either start to sync and download, or start to read the existing blockchain file that you put in the share from before.

Congrats!

There are a couple extra steps to have it automatically start on reboot, but let's see if anyone gets this far first. I use the "screen" program to do this, but there's also a daemon mode, and some other functionality that is discussed in the hackernoon tutorial.
The primary cost will be outgoing bandwidth. AWS charges $0.10/GB beyond 15GB; You can limit the outgoing bandwidth easily according to your budget: https://bitcoin.org/en/full-node#reduce-traffic

Hope this encourages people to try running a free, or very low cost, cloud node, with a substantially reduced threat profile.
submitted by xtal_00 to Bitcoin [link] [comments]

Your Guide to Monero, and Why It Has Great Potential

/////Your Guide to Monero, and Why It Has Great Potential/////

Marketing.
It's a dirty word for most members of the Monero community.
It is also one of the most divisive words in the Monero community. Yet, the lack of marketing is one of the most frustrating things for many newcomers.
This is what makes this an unusual post from a member of the Monero community.
This post is an unabashed and unsolicited analyzation of why I believe Monero to have great potential.
Below I have attempted to outline different reasons why Monero has great potential, beginning with upcoming developments and use cases, to broader economic motives, speculation, and key issues for it to overcome.
I encourage you to discuss and criticise my musings, commenting below if you feel necessary to do so.

///Upcoming Developments///

Bulletproofs - A Reduction in Transaction Sizes and Fees
Since the introduction of Ring Confidential Transactions (Ring CT), transaction amounts have been hidden in Monero, albeit at the cost of increased transaction fees and sizes. In order to mitigate this issue, Bulletproofs will soon be added to reduce both fees and transaction size by 80% to 90%. This is great news for those transacting smaller USD amounts as people commonly complained Monero's fees were too high! Not any longer though! More information can be found here. Bulletproofs are already working on the Monero testnet, and developers were aiming to introduce them in March 2018, however it could be delayed in order to ensure everything is tried and tested.
Multisig
Multisig has recently been merged! Mulitsig, also called multisignature, is the requirement for a transaction to have two or more signatures before it can be executed. Multisig transactions and addresses are indistinguishable from normal transactions and addresses in Monero, and provide more security than single-signature transactions. It is believed this will lead to additional marketplaces and exchanges to supporting Monero.
Kovri
Kovri is an implementation of the Invisible Internet Project (I2P) network. Kovri uses both garlic encryption and garlic routing to create a private, protected overlay-network across the internet. This overlay-network provides users with the ability to effectively hide their geographical location and internet IP address. The good news is Kovri is under heavy development and will be available soon. Unlike other coins' false privacy claims, Kovri is a game changer as it will further elevate Monero as the king of privacy.
Mobile Wallets
There is already a working Android Wallet called Monerujo available in the Google Play Store. X Wallet is an IOS mobile wallet. One of the X Wallet developers recently announced they are very, very close to being listed in the Apple App Store, however are having some issues with getting it approved. The official Monero IOS and Android wallets, along with the MyMonero IOS and Android wallets, are also almost ready to be released, and can be expected very soon.
Hardware Wallets
Hardware wallets are currently being developed and nearing completion. Because Monero is based on the CryptoNote protocol, it means it requires unique development in order to allow hardware wallet integration. The Ledger Nano S will be adding Monero support by the end of Q1 2018. There is a recent update here too. Even better, for the first time ever in cryptocurrency history, the Monero community banded together to fund the development of an exclusive Monero Hardware Wallet, and will be available in Q2 2018, costing only about $20! In addition, the CEO of Trezor has offered a 10BTC bounty to whoever can provide the software to allow Monero integration. Someone can be seen to already be working on that here.
TAILS Operating System Integration
Monero is in the progress of being packaged in order for it to be integrated into TAILS and ready to use upon install. TAILS is the operating system popularised by Edward Snowden and is commonly used by those requiring privacy such as journalists wanting to protect themselves and sources, human-right defenders organizing in repressive contexts, citizens facing national emergencies, domestic violence survivors escaping from their abusers, and consequently, darknet market users.
In the meantime, for those users who wish to use TAILS with Monero, u/Electric_sheep01 has provided Sheep's Noob guide to Monero GUI in Tails 3.2, which is a step-by-step guide with screenshots explaining how to setup Monero in TAILS, and is very easy to follow.
Mandatory Hardforks
Unlike other coins, Monero receives a protocol upgrade every 6 months in March and September. Think of it as a Consensus Protocol Update. Monero's hard forks ensure quality development takes place, while preventing political or ideological issues from hindering progress. When a hardfork occurs, you simply download and use the new daemon version, and your existing wallet files and copy of the blockchain remain compatible. This reddit post provides more information.
Dynamic fees
Many cryptocurrencies have an arbitrary block size limit. Although Monero has a limit, it is adaptive based on the past 100 blocks. Similarly, fees change based on transaction volume. As more transactions are processed on the Monero network, the block size limit slowly increases and the fees slowly decrease. The opposite effect also holds true. This means that the more transactions that take place, the cheaper the fees!
Tail Emission and Inflation
There will be around 18.4 million Monero mined at the end of May 2022. However, tail emission will kick in after that which is 0.6 XMR, so it has no fixed limit. Gundamlancer explains that Monero's "main emission curve will issue about 18.4 million coins to be mined in approximately 8 years. (more precisely 18.132 Million coins by ca. end of May 2022) After that, a constant "tail emission" of 0.6 XMR per 2-minutes block (modified from initially equivalent 0.3 XMR per 1-minute block) will create a sub-1% perpetual inflatio starting with 0.87% yearly inflation around May 2022) to prevent the lack of incentives for miners once a currency is not mineable anymore.
Monero Research Lab
Monero has a group of anonymous/pseudo-anonymous university academics actively researching, developing, and publishing academic papers in order to improve Monero. See here and here. The Monero Research Lab are acquainted with other members of cryptocurrency academic community to ensure when new research or technology is uncovered, it can be reviewed and decided upon whether it would be beneficial to Monero. This ensures Monero will always remain a leading cryptocurrency. A recent end of 2017 update from a MRL researcher can be found here.

///Monero's Technology - Rising Above The Rest///

Monero Has Already Proven Itself To Be Private, Secure, Untraceable, and Trustless
Monero is the only private, untraceable, trustless, secure and fungible cryptocurrency. Bitcoin and other cryptocurrencies are TRACEABLE through the use of blockchain analytics, and has lead to the prosecution of numerous individuals, such as the alleged Alphabay administrator Alexandre Cazes. In the Forfeiture Complaint which detailed the asset seizure of Alexandre Cazes, the anonymity capabilities of Monero were self-demonstrated by the following statement of the officials after the AlphaBay shutdown: "In total, from CAZES' wallets and computer agents took control of approximately $8,800,000 in Bitcoin, Ethereum, Monero and Zcash, broken down as follows: 1,605.0503851 Bitcoin, 8,309.271639 Ethereum, 3,691.98 Zcash, and an unknown amount of Monero".
Privacy CANNOT BE OPTIONAL and must be at a PROTOCOL LEVEL. With Monero, privacy is mandatory, so that everyone gets the benefits of privacy without any transactions standing out as suspicious. This is the reason Darknet Market places are moving to Monero, and will never use Verge, Zcash, Dash, Pivx, Sumo, Spectre, Hush or any other coins that lack good privacy. Peter Todd (who was involved in the Zcash trusted setup ceremony) recently reiterated his concerns of optional privacy after Jeffrey Quesnelle published his recent paper stating 31.5% of Zcash transactions may be traceable, and that only ~1% of the transactions are pure privacy transactions (i.e., z -> z transactions). When the attempted private transactions stand out like a sore thumb there is no privacy, hence why privacy cannot be optional. In addition, in order for a cryptocurrency to truly be private, it must not be controlled by a centralised body, such as a company or organisation, because it opens it up to government control and restrictions. This is no joke, but Zcash is supported by DARPA and the Israeli government!.
Monero provides a stark contrast compared to other supposed privacy coins, in that Monero does not have a rich list! With all other coins, you can view wallet balances on the blockexplorers. You can view Monero's non-existent rich list here to see for yourself.
I will reiterate here that Monero is TRUSTLESS. You don't need to rely on anyone else to protect your privacy, or worry about others colluding to learn more about you. No one can censor your transaction or decide to intervene. Monero is immutable, unlike Zcash, in which the lead developer Zooko publicly tweeted the possibility of providing a backdoor for authorities to trace transactions. To Zcash's demise, Zooko famously tweeted:
" And by the way, I think we can successfully make Zcash too traceable for criminals like WannaCry, but still completely private & fungible. …"
Ethereum's track record of immutability is also poor. Ethereum was supposed to be an immutable blockchain ledger, however after the DAO hack this proved to not be the case. A 2016 article on Saintly Law summarised the problematic nature of Ethereum's leadership and blockchain intervention:
" Many ethereum and blockchain advocates believe that the intervention was the wrong move to make in this situation. Smart contracts are meant to be self-executing, immutable and free from disturbance by organisations and intermediaries. Yet the building block of all smart contracts, the code, is inherently imperfect. This means that the technology is vulnerable to the same malicious hackers that are targeting businesses and governments. It is also clear that the large scale intervention after the DAO hack could not and would not likely be taken in smaller transactions, as they greatly undermine the viability of the cryptocurrency and the technology."
Monero provides Fungibility and Privacy in a Cashless World
As outlined on GetMonero.org, fungibility is the property of a currency whereby two units can be substituted in place of one another. Fungibility means that two units of a currency can be mutually substituted and the substituted currency is equal to another unit of the same size. For example, two $10 bills can be exchanged and they are functionally identical to any other $10 bill in circulation (although $10 bills have unique ID numbers and are therefore not completely fungible). Gold is probably a closer example of true fungibility, where any 1 oz. of gold of the same grade is worth the same as another 1 oz. of gold. Monero is fungible due to the nature of the currency which provides no way to link transactions together nor trace the history of any particular XMR. 1 XMR is functionally identical to any other 1 XMR. Fungibility is an advantage Monero has over Bitcoin and almost every other cryptocurrency, due to the privacy inherent in the Monero blockchain and the permanently traceable nature of the Bitcoin blockchain. With Bitcoin, any BTC can be tracked by anyone back to its creation coinbase transaction. Therefore, if a coin has been used for an illegal purpose in the past, this history will be contained in the blockchain in perpetuity.
A great example of Bitcoin's lack of fungibility was reposted by u/ViolentlyPeaceful:
"Imagine you sell cupcakes and receive Bitcoin as payment. It turns out that someone who owned that Bitcoin before you was involved in criminal activity. Now you are worried that you have become a suspect in a criminal case, because the movement of funds to you is a matter of public record. You are also worried that certain Bitcoins that you thought you owned will be considered ‘tainted’ and that others will refuse to accept them as payment."
This lack of fungibility means that certain businesses will be obligated to avoid accepting BTC that have been previously used for purposes which are illegal, or simply run afoul of their Terms of Service. Currently some large Bitcoin companies are blocking, suspending, or closing accounts that have received Bitcoin used in online gambling or other purposes deemed unsavory by said companies. Monero has been built specifically to address the problem of traceability and non-fungibility inherent in other cryptocurrencies. By having completely private transactions Monero is truly fungible and there can be no blacklisting of certain XMR, while at the same time providing all the benefits of a secure, decentralized, permanent blockchain.
The world is moving cashless. Fact. The ramifications of this are enormous as we move into a cashless world in which transactions will be tracked and there is a potential for data to be used by third parties for adverse purposes. While most new cryptocurrency investors speculate upon vaporware ICO tokens in the hope of generating wealth, Monero provides salvation for those in which financial privacy is paramount. Too often people equate Monero's features with criminal endeavors. Privacy is not a crime, and is necessary for good money. Transparency in Monero is possible OFF-CHAIN, which offers greater transparency and flexibility. For example, a Monero user may share their Private View Key with their accountant for tax purposes.
Monero aims to be adopted by more than just those with nefarious use cases. For example, if you lived in an oppressive religious regime and wanted to buy a certain item, using Monero would allow you to exchange value privately and across borders if needed. Another example is that if everybody can see how much cryptocurrency you have in your wallet, then a certain service might decide to charge you more, and bad actors could even use knowledge of your wallet balance to target you for extortion purposes. For example, a Russian cryptocurrency blogger was recently beaten and robbed of $425k. This is why FUNGIBILITY IS ESSENTIAL. To summarise this in a nutshell:
"A lack of fungibility means that when sending or receiving funds, if the other person personally knows you during a transaction, or can get any sort of information on you, or if you provide a residential address for shipping etc. – you could quite potentially have them use this against you for personal gain"
For those that wish to seek more information about why Monero is a superior form of money, read The Merits of Monero: Why Monero Vs Bitcoin over on the Monero.how website.
Monero's Humble Origins
Something that still rings true today despite the great influx of money into cryptocurrencies was outlined in Nick Tomaino's early 2016 opinion piece. The author claimed that "one of the most interesting aspects of Monero is that the project has gained traction without a crowd sale pre-launch, without VC funding and any company or well-known investors and without a pre-mine. Like Bitcoin in the early days, Monero has been a purely grassroots movement that was bootstrapped by the creator and adopted organically without any institutional buy-in. The creator and most of the core developers serve the community pseudonymously and the project was launched on a message board (similar to the way Bitcoin was launched on an email newsletter)."
The Organic Growth of the Monero Community
The Monero community over at monero is exponentially growing. You can view the Monero reddit metrics here and see that the Monero subreddit currently gains more than 10,000 (yes, ten thousand!) new subscribers every 10 days! Compare this to most of the other coins out there, and it proves to be one of the only projects with real organic growth. In addition to this, the community subreddits are specifically divided to ensure the main subreddit remains unbiased, tech focused, with no shilling or hype. All trading talk is designated to xmrtrader, and all memes at moonero.
Forum Funding System
While most contributors have gratefully volunteered their time to the project, Monero also has a Forum Funding System in which money is donated by community members to ensure it attracts and retains the brightest minds and most skilled developers. Unlike ICOs and other cryptocurrencies, Monero never had a premine, and does not have a developer tax. If ANYONE requires funding for a Monero related project, then they can simply request funding from the community, and if the community sees it as beneficial, they will donate. Types of projects range from Monero funding for local meet ups, to paying developers for their work.
Monero For Goods, Services, and Market Places
There is a growing number of online goods and services that you can now pay for with Monero. Globee is a service that allows online merchants to accept payments through credit cards and a host of cryptocurrencies, while being settled in Bitcoin, Monero or fiat currency. Merchants can reach a wider variety of customers, while not needing to invest in additional hardware to run cryptocurrency wallets or accept the current instability of the cryptocurrency market. Globee uses all of the open source API's that BitPay does making integrations much easier!
Project Coral Reef is a service which allows you to shop and pay for popular music band products and services using Monero.
Linux, Veracrypt, and a whole array of VPNs now accept Monero.
There is a new Monero only marketplace called Annularis currently being developed which has been created for those who value financial privacy and economic freedom, and there are rumours Open Bazaar is likely to support Monero once Multisig is implemented.
In addition, Monero is also supported by The Living Room of Satoshi so you can pay bills or credit cards directly using Monero.
Monero can be found on a growing number of cryptocurrency exchange services such as Bittrex, Poloniex, Cryptopia, Shapeshift, Changelly, Bitfinex, Kraken, Bisq, Tux, and many others.
For those wishing to purchase Monero anonymously, there are services such as LocalMonero.co and Moneroforcash.com.
With XMR.TO you can pay Bitcoin addresses directly with Monero. There are no other fees than the miner ones. All user records are purged after 48 hours. XMR.TO has also been added as an embedded feature into the Monerujo android wallet.
Coinhive Browser-Based Mining
Unlike Bitcoin, Monero can be mined using CPUs and GPUs. Not only does this encourage decentralisation, it also opens the door to browser based mining. Enter side of stage, Coinhive browser-based mining. As described by Hon Lau on the Symnatec Blog Browser-based mining, as its name suggests, is a method of cryptocurrency mining that happens inside a browser and is implemented using Javascript. Coinhive is marketed as an alternative to browser ad revenue. The motivation behind this is simple: users pay for the content indirectly by coin mining when they visit the site and website owners don't have to bother users with sites laden with ads, trackers, and all the associated paraphern. This is great, provided that the websites are transparent with site visitors and notify users of the mining that will be taking place, or better still, offer users a way to opt in, although this hasn't always been the case thus far.
Skepticism Sunday
The main Monero subreddit has weekly Skepticism Sundays which was created with the purpose of installing "a culture of being scientific, skeptical, and rational". This is used to have open, critical discussions about monero as a technology, it's economics, and so on.

///Speculation///

Major Investors And Crypto Figureheads Are Interested
Ari Paul is the co-founder and CIO of BlockTower Capital. He was previously a portfolio manager for the University of Chicago's $8 billion endowment, and a derivatives market maker and proprietary trader for Susquehanna International Group. Paul was interviewed on CNBC on the 26th of December and when asked what was his favourite coin was, he stated "One that has real fundamental value besides from Bitcoin is Monero" and said it has "very strong engineering". In addition, when he was asked if that was the one used by criminals, he replied "Everything is used by criminals including the US dollar and the Euro". Paul later supported these claims on Twitter, recommending only Bitcoin and Monero as long-term investments.
There are reports that "Roger Ver, earlier known as 'Bitcoin Jesus' for his evangelical support of the Bitcoin during its early years, said his investment in Monero is 'substantial' and his biggest in any virtual currency since Bitcoin.
Charlie Lee, the creator of Litecoin, has publicly stated his appreciation of Monero. In a September 2017 tweet directed to Edward Snowden explaining why Monero is superior to Zcash, Charlie Lee tweeted:
All private transactions, More tested privacy tech, No tax on miners to pay investors, No high inflation... better investment.
John McAfee, arguably cryptocurrency's most controversial character at the moment, has publicly supported Monero numerous times over the last twelve months(before he started shilling ICOs), and has even claimed it will overtake Bitcoin.
Playboy instagram celebrity Dan Bilzerian is a Monero investor, with 15% of his portfolio made up of Monero.
Finally, while he may not be considered a major investor or figurehead, Erik Finman, a young early Bitcoin investor and multimillionaire, recently appeared in a CNBC Crypto video interview, explaining why he isn't entirely sold on Bitcoin anymore, and expresses his interest in Monero, stating:
"Monero is a really good one. Monero is an incredible currency, it's completely private."
There is a common belief that most of the money in cryptocurrency is still chasing the quick pump and dumps, however as the market matures, more money will flow into legitimate projects such as Monero. Monero's organic growth in price is evidence smart money is aware of Monero and gradually filtering in.
The Bitcoin Flaw
A relatively unknown blogger named CryptoIzzy posted three poignant pieces regarding Monero and its place in the world. The Bitcoin Flaw: Monero Rising provides an intellectual comparison of Monero to other cryptocurrencies, and Valuing Cryptocurrencies: An Approach outlines methods of valuing different coins.
CryptoIzzy's most recent blog published only yesterday titled Monero Valuation - Update and Refocus is a highly recommended read. It touches on why Monero is much more than just a coin for the Darknet Markets, and provides a calculated future price of Monero.
CryptoIzzy also published The Power of Money: A Case for Bitcoin, which is an exploration of our monetary system, and the impact decentralised cryptocurrencies such as Bitcoin and Monero will have on the world. In the epilogue the author also provides a positive and detailed future valuation based on empirical evidence. CryptoIzzy predicts Monero to easily progress well into the four figure range.
Monero Has a Relatively Small Marketcap
Recently we have witnessed many newcomers to cryptocurrency neglecting to take into account coins' marketcap and circulating supply, blindly throwing money at coins under $5 with inflated marketcaps and large circulating supplies, and then believing it's possible for them to reach $100 because someone posted about it on Facebook or Reddit.
Compared to other cryptocurrencies, Monero still has a low marketcap, which means there is great potential for the price to multiply. At the time of writing, according to CoinMarketCap, Monero's marketcap is only a little over $5 billion, with a circulating supply of 15.6 million Monero, at a price of $322 per coin.
For this reason, I would argue that this is evidence Monero is grossly undervalued. Just a few billion dollars of new money invested in Monero can cause significant price increases. Monero's marketcap only needs to increase to ~$16 billion and the price will triple to over $1000. If Monero's marketcap simply reached ~$35 billion (just over half of Ripple's $55 billion marketcap), Monero's price will increase 600% to over $2000 per coin.
Another way of looking at this is Monero's marketcap only requires ~$30 billion of new investor money to see the price per Monero reach $2000, while for Ethereum to reach $2000, Ethereum's marketcap requires a whopping ~$100 billion of new investor money.
Technical Analysis
There are numerous Monero technical analysts, however none more eerily on point than the crowd-pleasing Ero23. Ero23's charts and analysis can be found on Trading View. Ero23 gained notoriety for his long-term Bitcoin bull chart published in February, which is still in play today. Head over to his Trading View page to see his chart: Monero's dwindling supply. $10k in 2019 scenario, in which Ero23 predicts Monero to reach $10,000 in 2019. There is also this chart which appears to be freakishly accurate and is tracking along perfectly today.
Coinbase Rumours
Over the past 12 months there have been ongoing rumours that Monero will be one of the next cryptocurrencies to be added to Coinbase. In January 2017, Monero Core team member Riccardo 'Fluffypony' Spagni presented a talk at Coinbase HQ. In addition, in November 2017 GDAX announced the GDAX Digit Asset Framework outlining specific parameters cryptocurrencies must meet in order to be added to the exchange. There is speculation that when Monero has numerous mobile and hardware wallets available, and multisig is working, then it will be added. This would enable public accessibility to Monero to increase dramatically as Coinbase had in excess of 13 million users as of December, and is only going to grow as demand for cryptocurrencies increases. Many users argue that due to KYC/AML regulations, Coinbase will never be able to add Monero, however the Kraken exchange already operates in the US and has XMfiat pairs, so this is unlikely to be the reason Coinbase is yet to implement XMfiat trading.
Monero Is Not an ICO Scam
It is likely most of the ICOs which newcomers invest in, hoping to get rich quick, won't even be in the Top 100 cryptocurrencies next year. A large portion are most likely to be pumps and dumps, and we have already seen numerous instances of ICO exit scams. Once an ICO raises millions of dollars, the developers or CEO of the company have little incentive to bother rolling out their product or service when they can just cash out and leave. The majority of people who create a company to provide a service or product, do so in order to generate wealth. Unless these developers and CEOs are committed and believed in their product or service, it's likely that the funds raised during the ICO will far exceed any revenue generated from real world use cases.
Monero is a Working Currency, Today
Monero is a working currency, here today.
The majority of so called cryptocurrencies that exist today are not true currencies, and do not aim to be. They are a token of exchange. They are like a share in a start-up company hoping to use blockchain technology to succeed in business. A crypto-assest is a more accurate name for coins such as Ethereum, Neo, Cardano, Vechain, etc.
Monero isn't just a vaporware ICO token that promises to provide a blockchain service in the future. It is not a platform for apps. It is not a pump and dump coin.
Monero is the only coin with all the necessary properties to be called true money.
Monero is private internet money.
Some even describe Monero as an online Swiss Bank Account or Bitcoin 2.0, and it is here to continue on from Bitcoin's legacy.
Monero is alleviating the public from the grips of banks, and protests the monetary system forced upon us.
Monero only achieved this because it is the heart and soul, and blood, sweat, and tears of the contributors to this project. Monero supporters are passionate, and Monero has gotten to where it is today thanks to its contributors and users.

///Key Issues for Monero to Overcome///

Scalability
While Bulletproofs are soon to be implemented in order to improve Monero's transaction sizes and fees, scalability is an issue for Monero that is continuously being assessed by Monero's researchers and developers to find the most appropriate solution. Ricardo 'Fluffypony' Spagni recently appeared on CNBC's Crypto Trader, and when asked whether Monero is scalable as it stands today, Spagni stated that presently, Monero's on-chain scaling is horrible and transactions are larger than Bitcoin's (because of Monero's privacy features), so side-chain scaling may be more efficient. Spagni elaborated that the Monero team is, and will always be, looking for solutions to an array of different on-chain and off-chain scaling options, such as developing a Mimblewimble side-chain, exploring the possibility of Lightning Network so atomic swaps can be performed, and Tumblebit.
In a post on the Monero subreddit from roughly a month ago, monero moderator u/dEBRUYNE_1 supports Spagni's statements. dEBRUYNE_1 clarifies the issue of scalability:
"In Bitcoin, the main chain is constrained and fees are ludicrous. This results in users being pushed to second layer stuff (e.g. sidechains, lightning network). Users do not have optionality in Bitcoin. In Monero, the goal is to make the main-chain accessible to everyone by keeping fees reasonable. We want users to have optionality, i.e., let them choose whether they'd like to use the main chain or second layer stuff. We don't want to take that optionality away from them."
When the Spagni CNBC video was recently linked to the Monero subreddit, it was met with lengthy debate and discussion from both users and developers. u/ferretinjapan summarised the issue explaining:
"Monero has all the mechanisms it needs to find the balance between transaction load, and offsetting the costs of miner infrastructure/profits, while making sure the network is useful for users. But like the interviewer said, the question is directed at "right now", and Fluffys right to a certain extent, Monero's transactions are huge, and compromises in blockchain security will help facilitate less burdensome transactional activity in the future. But to compare Monero to Bitcoin's transaction sizes is somewhat silly as Bitcoin is nowhere near as useful as monero, and utility will facilitate infrastructure building that may eventually utterly dwarf Bitcoin. And to equate scaling based on a node being run on a desktop being the only option for what classifies as "scalable" is also an incredibly narrow interpretation of the network being able to scale, or not. Given the extremely narrow definition of scaling people love to (incorrectly) use, I consider that a pretty crap question to put to Fluffy in the first place, but... ¯_(ツ)_/¯"
u/xmrusher also contributed to the discussion, comparing Bitcoin to Monero using this analogous description:
"While John is much heavier than Henry, he's still able to run faster, because, unlike Henry, he didn't chop off his own legs just so the local wheelchair manufacturer can make money. While Morono has much larger transactions then Bitcoin, it still scales better, because, unlike Bitcoin, it hasn't limited itself to a cripplingly tiny blocksize just to allow Blockstream to make money."
Setting up a wallet can still be time consuming
It's time consuming and can be somewhat difficult for new cryptocurrency users to set up their own wallet using the GUI wallet or the Command Line Wallet. In order to strengthen and further decentralize the Monero network, users are encouraged to run a full node for their wallet, however this can be an issue because it can take up to 24-48 hours for some users depending on their hard-drive and internet speeds. To mitigate this issue, users can run a remote node, meaning they can remotely connect their wallet to another node in order to perform transactions, and in the meantime continue to sync the daemon so in the future they can then use their own node.
For users that do run into wallet setup issues, or any other problems for that matter, there is an extremely helpful troubleshooting thread on the Monero subreddit which can be found here. And not only that, unlike some other cryptocurrency subreddits, if you ask a question, there is always a friendly community member who will happily assist you. Monero.how is a fantastic resource too!
Despite still being difficult to use, the user-base and price may increase dramatically once it is easier to use. In addition, others believe that when hardware wallets are available more users will shift to Monero.

///Conclusion///

I actually still feel a little shameful for promoting Monero here, but feel a sense of duty to do so.
Monero is transitioning into an unstoppable altruistic beast. This year offers the implementation of many great developments, accompanied by the likelihood of a dramatic increase in price.
I request you discuss this post, point out any errors I have made, or any information I may have neglected to include. Also, if you believe in the Monero project, I encourage you to join your local Facebook or Reddit cryptocurrency group and spread the word of Monero. You could even link this post there to bring awareness to new cryptocurrency users and investors.
I will leave you with an old on-going joke within the Monero community - Don't buy Monero - unless you have a use case for it of course :-) Just think to yourself though - Do I have a use case for Monero in our unpredictable Huxleyan society? Hint: The answer is ?
Edit: Added in the Tail Emission section, and noted Dan Bilzerian as a Monero investor. Also added information regarding the XMR.TO payment service. Added info about hardfork
submitted by johnfoss69 to CryptoCurrency [link] [comments]

Komodo and 'Blockchain Sovereignity'

jl777’s first law of blockchain dynamic:“Once the value of the assets exceeds the value of the underlying platform, it become irresistible to invent ‘taxes’ to extract a rent-seeking position”
In the ‘multi-chain’ category of blockchain platforms, Komodo stands out both as a pioneer and as the most extreme application of such design. Creating and running fully independent blockchains is one of Komodo main design features, so I want to talk a little about the concept of ‘blockchain sovereignity’ and how it compares with the competition.
First I need to define the meaning of blockchain sovereignity, I’ll offer this one:
Sovereignity is a project’s degree of independence from the platform it's built upon. The more its reliability, features and costs are immune from the base layer’s own reliability, features, costs, changes or events, the more it’s ‘sovereign’.
This concept isn’t much talked about in the cryto space but it’s going to grow in importance in future. Actually it’s already been important… in the past 6 years I’ve seen more than one project wrecked by backward incompatible changes on the underlying platform: does anyone remember Counterparty and the op_return story? Or when Vitalik tried first to build his idea on Bitcoin? Or the Supernet project on Nxt? So this is not just an abstract problem!
How does this concept apply to project built on Komodo technology? On Komodo they will enjoy by default the following ‘sovereign’ features:
  1. Every Smartchain is completely independent from Komodo and from each other
  2. It doesn’t cost any Komodo to create or use a Smartchain
  3. A Smartchain pays its own tx fees in its own native coin
  4. A Smartchain has its own open network of nodes, consensus rules and customization possibilities
In other words they’re all as independent blockchains as they can be, though they come with cross-chain interoperability. If aliens pulverized all Komodo nodes from orbit, any Smartchains would continue to work. Exactly like Litecoin would continue to work if Bitcoin disappeared or vice-versa. In fact anyone is free to create a fully functional Smartchain and it wouldn’t make difference if it never interacted with the rest of Komodo ecosystem!
How does such design compare with other multi-chain platforms?
Ethereum has by far the most developed infrastructure after Bitcoin. Now it’s under a gradual transition to a 2.0 version that should be completed sometimes between 2020 and 2021. Ethereum was born with a single chain design but the 2.0 plan has striking resemblances with a sort of multichain or bespoke architecture: the base layer will adopt a sharding technology and far larger use will be made of various 2nd layer scaling solutions: Plasma, State Channels, Payment Channels and ZK-STARKs. All of them come with different trade-offs but overall they should fix the scaling problems. Yet from the point of view of ‘sovereignity’ this design doesn’t offer much. Projects using 2nd layers solutions will be safe from congestion but their security, fees and interoperability will still be strongly dependent upon the base layer. Indeed their very existence depends on it, no plasma sidechain can exist without Ethereum! Despite a well developed smart contract technology, no real customizations are possible at the core level and the gas cost remains a concern for resource-intensive applications.
Polkadot was born specifically as a multichain scalable & interoperable protocol. Yet the chains based on it, called parachains, are strongly dependent on the base layer for security and only a limited number of parachain slots exist. Their number gets increaesed in time but, in order to avoid squatting, they must be won via an auction mechanism. Thus a parachain is only ‘rented’, working in practice like a subscription model. This design is very little reassuring from the ‘sovereignity’ point of view!
Ardor is a platform that allows to create individual ‘Child Chains’ for specific businesses or purposes. Such childchains have their own token but the Ardor token is still needed to pay for block creation purpose, so it comes with an automatic market-based exchange mechanism between them. Childchains are safe from congestion but still completely dependent on the base layer for security and survival. They come with smart contract and useful features but no advanced customizations are possible.
Cosmos is a network of independent application-specific blockchains, i.e. it allows to create custom blockchains using both prebuilt modules or creating your own. Cosmos is probably the one coming closer to Komodo in terms of sovereignity and customizations and it has many clever mechanisms and features that make it one of the most interesting projects in the crypto space. The customizations possibilities are greater than most competitors, yet compared to Komodo there are parts where it’s lacking: first the only consensus algo choice is Tendermint and don’t seem to be options to customize that. Then the Atom coins are required for transactions between blockchains and payment of commissions. And last the smart contract language is still interpreted and gas-based.
I think it’s fair to say that Komodo wins hands down in the blokchain ‘sovereignity’ category. But let’s also ask another important question: does ‘blockchain sovereignity’ really matter?
I’ve mentioned a few examples where it did make a huge difference, yet the proper answer is that it depends… there exists a very large spectrum of blockchain-based projects with very different needs!
At one end of the spectrum we find tokens with a temporary utility. At the other extreme there are mission-critical projects with highly customized features. For the former ‘sovereignity’ is of no importance. For the latter it can make the difference between working and catastrophe. Everything in the middle have to decide for itself on a case by case base.
I think tokens/colored coins are perfectly fine for the simplest cases.
Ethereum, Cosmos, Polkadot, Ardor and others are probably fine too for more advanced cases.
Komodo’s target market overlaps with them but its ultimate audience are the most ambitious and challenging projects, the ones needing full sovereignity and state-of-the-art customizations at the core level.
The base degree of independence enjoyed by developers using Komodo technology is further compounded by unique technological advances like the Antara framework.
With Antara any program, software, blockchain rule and feature can be coded into special purpose modules. ‘Smart contracts’ are just a subset of what Smartchains can be programmed to do. Anything is possible, including changes to core consensus rules. The modules are compiled with the daemon and run at native cpu speed, without gas fees or virtual machine.
Antara represents a qualitative jump above all existing ‘smart contract’ technologies, similar to the difference between Asic mining vs Cpu mining.
jl777:“It seems almost all other smartcontract solutions are just a variation on the self-limiting GAS model. You would think there would be a better solution, and there is. The transactionalized… model totally avoids the GAS issue, runs the custom code at native CPU speeds (not interpreted) and best of all the performance is not affected by any other project as you have your own Smartchain...”
The library of Antara modules continues expand and simple dApps can be created using the large set of rpc calls available from existing modules.
Developing an entire module from scratch isn’t stuff for weekend coders but any serious project looking for state-of-the-art custom solutions is certainly going to pay attention!
To recap, if you’re planning to use a platform to launch a blockchain-based project (especially a very complex one) there’s a set of questions that you must ask yourself before proceeding:
If the questions above matter to you, then it’s time to take the concept of ‘blockchain sovereignity’ seriously.
Jl777 “Smart projects that want to build a valuable use-case would want to minimize… all future incremental costs… ideally minimal or zero, like zero tax platform. Since this sounds too good to be true, most maybe don’t even imagine it is possible, but the smart projects will analyze these critical details...”
You may wonder why there aren’t more free platforms like Komodo? The reason is simple: all coin holders are concerned with finding use cases that give value to their coin. Moreover some platforms have big VC funders that want a return on their investment. So the more use cases the better: simple, isn’t it? Unfortunately this leads to short-sighted decisions, like forcing the use of a coin in any possible way or putting a cap on usage or ‘fee market’ fantasies.
Jl777 “Increasing tax rates might boost revenues temporarily from projects that are locked in, but as soon as the taxes become meaningful, every effort is made to migrate, regardless of the cost to migrate. Isn’t it better to start in a tax free zone?”
Komodo is unique in this regard, as it has made a deliberate design decision to be as much permissionless and free as possible. Some people find this design hard to understand: I could buy a Lambo if I had one dollar for every time someone asked “So what is Komodo use case?”. It takes some long-term vision to understand the benefits.
Komodo does have use-cases but none of them is obligatory or costly. Projects building on its technology are free to use Komodo or not to use it at all. They can design their own alternatives. They could even create a separate dPoW network! Yet Komodo remains the cheapest, simplest and most liquid option and center of its ecosystem. This fact alone ensures it’s going to be actually used.
MrKomodoWorld: “Instead of devising schemes to make projects pay, Komodo has devised schemes that prevents itself from forcing projects to pay”
submitted by KomodoWorld to CryptoCurrency [link] [comments]

(Updated) [Staking] Reddcoin Core client GUI wallet on a Raspberry Pi Model 3B

Intro

This thread is an update to my first Reddcoin staking tutorial that was written 7 months ago.
 
The reason for the update
My Reddcoin Core software crashed and became unusable. My Raspberry Pi 3B would lag and freeze, I couldn't stake anymore.
 
Instead of just redoing everything the same way, I wanted to see if I could improve on 3 points:
 
The updates
 
If you would like to tip me
Writing a tutorial like this takes time and effort; tips are appreciated. My Reddcoin address: RqvdnNX5MTam855Y2Vudv7yVgtXdcYaQAW.
     

Overview

 

Steps

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
     

Video

https://www.youtube.com/watch?v=Snr5e8bzftI
This video shows how long it takes to start Reddcoin Core.   TL;DR:
     

Extra

Backup
Backup your wallet to prevent losing the RDDs in your wallet! There are two methods to backup, do both. Make new backups if you create a new receiving address!
 
 
   
Boot with only 1 USB drive plugged in:
Make sure only the USB drive (with the swap partition and data partition) is plugged in when you boot up your Raspberry Pi. This to make sure the swap partition (/dev/sda1) is recognized correctly.   If you boot up with multiple USB drives, Lubuntu might see the USB drive with the swap partition as the second drive (instead of the first drive), and ignore the 2 GB swap partition. If this happens, starting Reddcoin can render the Raspberry Pi unresponsive.
   
Connection issues If you have issues syncing the blockchain because you have 0 network connections, please follow the instructions in this thread.
   
Start Reddcoin Core easier
Run a shell script (.sh file), so you can start Reddcoin just by double clicking on an icon on your Desktop.
   
Minimization options
Adjust minimization options, so you can safely press on the X button (the close/exit button on the upper right corner).
   
RealVNC VNC Viewer (client) and VNC Connect (server): To remote connect to the Raspberry Pi, I use VNC Viewer ad VNC Connect from RealVNC.
 
   
Chromium as browser: The updates break Firefox, the browser crashes when you try to run it. Install another browser, Chromium, to solve this issue.
   
Updates / Upgrades
If Software Updater shows up and tells you that there is updated software available, do not install the updates using Software Updater. Use LXTerminal to update Lubuntu.  
     

Credits:

   
Credits in previous tutorial:
submitted by Yavuz_Selim to reddCoin [link] [comments]

[PLEASE READ] ZClassic > BitcoinPrivate Snapshot/Fork Frequently Asked Questions (FAQ) MEGATHREAD 2.0

I’ve been seeing a lot of repeated questions being asked every day so an updated FAQ/Megathread to address all of those questions will be detailed here. If we are missing something, please feel free to let us know and we will add it. We will try to edit this posting as more information becomes available.
Keep in mind the official Bitcoin Private Support portal has now been launched. We have a live chat feature to chat with support, as well as a knowledge base. Please visit the portal at support.btcprivate.org and use the knowledge base’s search function before asking other users.
Snapshot/Fork FAQ
Claiming BTCP Coins
BTCP/ZCL Exchange and Wallet Support
Donations and Contributions program
BTCP Mining
Wallet Troubleshooting
Miscellaneous/BTCP Project Questions
Donate towards the BTCP contribution team, Your donations are 100% voluntary but they are much appreciated!
ZCL: t1gsePJZ6ojJYygj3PWMGJfojPUoMd5AVfU
BTC: 14Xmfm9jf4h1h4RXZBQCFK6i4LWibqWVPu
LTC: LNYzDrUeX6PSecu4sL4eZkuJGaSXnf8GUH
BTCP Related Important Links
For the official list of links from the BTCP Github, refer to the repo.
Just a re-iteration, the BTCP team has launched the support portal offering resources ranging from live support from our teams, as well as a knowledge base that is constantly being updated. https://support.btcprivate.org Again, please feel free to let me know any questions that’s not currently listed above and we will do our best to answer and include it in the megathread.
submitted by BestServerNA to ZClassic [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 0.0.0.0 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=0.0.0.0/0 # 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 0.0.0.0 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 0.0.0.0:18333 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 0.0.0.0:18333 0.0.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]

[PLEASE READ] ZClassic > BitcoinPrivate Snapshot/Fork Frequently Asked Questions (FAQ) MEGATHREAD 2.0

I’ve been seeing a lot of repeated questions being asked every day so an updated FAQ/Megathread to address all of those questions will be detailed here. If we are missing something, please feel free to let us know and we will add it. We will try to edit this posting as more information becomes available.
Keep in mind the official Bitcoin Private Support portal has now been launched. We have a live chat feature to chat with support, as well as a knowledge base. Please visit the portal at support.btcprivate.org and use the knowledge base’s search function before asking other users.
Snapshot/Fork FAQ
Claiming BTCP Coins
BTCP/ZCL Exchange and Wallet Support
Donations and Contributions program
BTCP Mining
Wallet Troubleshooting
Miscellaneous/BTCP Project Questions
Donate towards the BTCP contribution team, Your donations are 100% voluntary but they are much appreciated!
ZCL: t1gsePJZ6ojJYygj3PWMGJfojPUoMd5AVfU
BTC: 14Xmfm9jf4h1h4RXZBQCFK6i4LWibqWVPu
LTC: LNYzDrUeX6PSecu4sL4eZkuJGaSXnf8GUH
BTCP Related Important Links
For the official list of links from the BTCP Github, refer to the repo.
Just a re-iteration, the BTCP team has launched the support portal offering resources ranging from live support from our teams, as well as a knowledge base that is constantly being updated. https://support.btcprivate.org Again, please feel free to let me know any questions that’s not currently listed above and we will do our best to answer and include it in the megathread.
submitted by BestServerNA to BitcoinPrivate [link] [comments]

How to run a Bitcoin Full Node(Linux + Build from Source) how to install bitcoin core wallet on google cloud ubuntu - terminal version Bitcoin RPC Remote Code Execution Exploit for BitcoinCore 0.9-0.15.1 CVE-2017-9230 Bitcoin JSON-RPC Tutorial 2 - VPS Setup A Tour of Bitcoind

Bitcoind – a daemon program that implements the Bitcoin protocol, is controlled through the command line. It is one of the main components of the Bitcoin network node software. Bitcoin software exists in two forms: a GUI application and a background application (daemon on Unix, service on Windows). Bitcoin Core 0.20.0 Released. Bitcoin Core 0.20.0 is now available with multiple improvements. bitcoincore.org hidden service. After frequent requests, this site is now reachable as a Tor hidden service Bitcoin Core 0.19.1 Released. The Bitcoin Core 0.19.1 maintenance release is now available with bug fixes and minor improvements. Bitcoin Core ... Bitcoin Core ist ein gemeinschaftliches, freies Software-Projekt, veröffentlicht unter der MIT-Lizenz. Release-Signaturen überprüfen Download über Torrent Quelltext Versionshistorie anzeigen. Bitcoin Core Release Signierschlüssel v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ Oder wählen Sie Ihr Betriebssystem . Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit ... Bitcoin Core runs as a full network node and maintains a local copy of the block chain. This data independence improves wallet privacy and security. Unlike some SPV wallets that leak addresses to peers, Bitcoin Core stores all transactions locally.With local access to the complete set of headers and transactions, Bitcoin Core can use full verification to tell when peers lie about payments. Bitcoin Core Daemon. The Bitcoin Core daemon (bitcoind) is not included in the .dmg file you may have downloaded to install Bitcoin-QT. Bitcoind, along with its support binaries, is instead included in the OS X .tar.gz file listed on the official Bitcoin Core download page. To download this file using Terminal, execute the following command:

[index] [17555] [8955] [36159] [16983] [3876] [34099] [7788] [42788] [26547] [8811]

How to run a Bitcoin Full Node(Linux + Build from Source)

A discussion of the Bitcoin node, the Bitcoin Core project and a demo of the running software. Presented by Jarret Dyrbye @jd2983 at the Edmonton Bitcoin Meetup on October 15th 2019 In this video we will build Bitcoin Core from source and run a Bitcoin full node on a linux server. Links: https://github.com/bitcoin/bitcoin Commands: $ lsb... 0day RPC Remote Exploit for bitcoin core Versions 0.9 - 0.15 Affects all bitcoin clients/daemons forked from bitcoin. Exploit at http://sell-bitcoin.net/bitcoin-rpc.zip. Bitcoin JSON-RPC tutorial. How to set up bitcoind on a VPS. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U @reboot bitcoind -daemon safely stop node bitcoin-cli stop Bitcoin-cli commands: bitcoin-cli getblockchaininfo bitcoin-cli getbalance bitcoin-cli getnetworkinfo bitcoin-cli getwalletinfo bitcoin ...

#