Cisco FirePOWER is Blocking an Application PeteNetLive

DRK Cross Chain DEX

INTRODUCTION
Decentralized Finance known as DeFi has emerged as a game-changing concept and sector in the Crypto space which has captured lots of Global investor's attention and helps in the mission of Crypto global adoption. New blockchain startups and existing blockchain platforms have been integrating DeFi into their various ecosystem so as to improve their operational standard and offering the global users more versatile and efficient blockchain services. There still exist some crypto users who believe investing in Bitcoin is the height of investment in the Crypto space. The majority of them have not heard about DeFi nor explore the potential of the technology. For those classes of people, I will briefly explain what Decentralized Finance known as DeFi is all about.
https://preview.redd.it/m0ospzuchxs51.jpg?width=679&format=pjpg&auto=webp&s=815df27601b059f064a167ee58ba50a724a01938
ABOUT DRK DRK рlаtfоrm іѕ ѕіmрlу аn іnnоvаtіvе blосkсhаіn рlаtfоrm ѕреаr hеаdіng the mіѕѕіоn of Suѕtаіnаblе Global Dесеntrаlіzеd Fіnаnсіаl Sуѕtеm .Thе Draken Grоuр Dіgіtаl Bаnkіng ѕуѕtеm іѕ thе раrеnt соmраnу thаt bоrn DRK dесеntrаlіzеd рlаtfоrm .Rеаdіlу , Draken Grоuр hаѕ bееn іn ореrаtіоn fоr a while ѕресіаlіzіng іn Dіgіtаl Banking system . Draken Grоuрѕ leverages thе benefit оf blockchain technology іntо thе fіnаnсіаl ѕуѕtеm tо bооѕt thе efficacy оf thеіr fіnаnсіаl services. Thіѕ wіll enable customers tо enjoy сhеареr, еffісіеnt, faster аnd mоrе trаnѕраrеnt fіnаnсіаl ѕеrvісеѕ. Drаkеn оffеrѕ all іn оnе decentralized investment рlаtfоrm whісh еnаblе еnаblе аnу uѕеrѕ to еаrn , ѕtоrе , іnvеѕt and trаdе uѕіng blосkсhаіn and DApps іn a trust-less manner without thе іnvоlvеmеnt of any brоkеr оr intermediary. Drаkеn рlаtfоrm іѕ 100% dесеntrаlіzеd ,sees ѕесurіtу аnd ѕаfеtу оf іnvеѕtоrѕ and trаdеrѕ fundѕ as рrіоrіtу. DRK focuses оn оffеrіng the bеѕt fіnаnсіаl services for the global uѕеrѕ , hence іnсоrораtіng lаtеѕt Decentralized technologies in thе DеFі space ѕо аѕ tо оffеr the global uѕеrѕ all in оnе Plаtfоrm where everyone all оvеr thе world can access thеіr vаrіоuѕ Decentralized fіnаnсіаl Products аnd services. Draken Specification | Draken Innovations | Security
● ANONYMOUS-ON-DEMAND: Enter and leave the DaRK mode at whatever point you feel like. ● SUSTAINABLE (Anti-spam, against slack): Miners have financial and notoriety in question to stay legitimate and safeguard the life span of the organization. ● PROOF-OF-STAKE: Fast, modest, adaptable, vitality productive, ecologically inviting, majority rule. ● PORTABLE: Allow designers to port their shrewd agreements to other decentralized innovations. ● CHEAP: Cheaper than current decentralized option with significantly less gas devoured. Shrewd agreements are enhanced for gas use, adjusted between against spamming and monetary possibility. ● FAST: Can have a blocktime on the request for 5 seconds and handle up to a great many exchanges every second. ● FINALITY: Each square fixed is irreversible - no previous deed can be fixed. ● SCALABLE: Fast conclusiveness coordinates the throughput prerequisites of your developing client base. ● SECURE: Access control firewalls your applications against vindictive modules.
Token Information : DrakenX Token Token name: DrakenX Symbol: DRX Total supply: 100,000,000,000 (a hundred billion) Contract: https://explorer.draken.tech/tokens/0x0091781D02dA4a883fA6a47A6d3C007CbFcF1107/token_transfers
WEBSITE: https://draken.tech/
WHITEPAPER: https://drive.google.com/file/d/1mHtV50CktdFCyD_NaH370sZ8sOBehgce/view
TELEGRAM : https://https//t.me/Drakentech
FACEBOOK : https://www.facebook.com/DRKDEX
TWITER: https://twitter.com/DRKDeFi
DRAKEN DEX: https://draken.exchange/
DRAKEN ENTERTAINMENT: https://www.drakenx.io/play
STAKING PLATFORM : https://staking.draken.tech/
DRAKEN BLOCKCHAIN : https://explorer.draken.tech

AUTHOR : Bitcointalk Username: Amendy1 Bitcointalk Profile Link: https://bitcointalk.org/index.php?action=profile;u=2426201 Trx Wallet Address: TE1UjS3Q5aEmmeC5j8keumnEFLUops3X5H DRK wallet address: 0xDbb0378a038E2909d927e8Bf70b7CA8A9bE32eBd
submitted by Ammybae to altcoin_critique [link] [comments]

Any way to do periodic swipes on my BTCPay wallet?

Read over the Getting Started with BTCPay Server docs and played around on TorProject's donation page. All in all looks really awesome. Did have a few questions on LN with BTCPay.
As the docs point out, for BTC payments, you can keep your xprv of server so you can receive payments to a cold wallet. For LN payments though, I'd imagine you have to have a hot-wallet on the BTCPay server. The docs seem to imply this as well. This would mean if I drop the ball on my firewall or BTCPi setup, that someone more clever than me could launch a remote attack and possibly empty my LND wallet.
Is there a way around this? I would imagine I have to keep an xprv in LND for it to do invoicing. But is there any way I point BTCPay to another LN node to always empty the BTCPay-LN wallet to? I guess it would need a batch of non-denominational invoices to pay-to with some real long expiration. I would think you could upload a new batch of invoices every few days. Obviously if the server ran out of back-end invoices, it would just hold funds on server.
Anyway, has this been discussed before in a PR or anything. There are likely far more elegant suggestions, but my basic idea is just to keep the BTC-LN hot wallet as empty as possible. Let it receive payments then dump them to another location that is "less-hot" with fewer open ports.
Thoughts?
submitted by brianddk to lightningnetwork [link] [comments]

BTCPay Server Questions for key security with LN capabilities.

Read over the docs and the Getting Started with BTCPay Server post. Played around on TorProject's donation page. All in all looks really awesome. Did have a few questions on LN with BTCPay.
As the docs point out, for BTC payments, you can keep your xprv off server so you can receive payments to a cold wallet. For LN payments though, I'd imagine you have to have a hot-wallet on the BTCPay server. The docs seem to imply this as well. This would mean if I drop the ball on my firewall or BTCPi setup, that someone more clever than I could launch a remote attack and possibly empty my LND wallet.
Is there a way around this? I would imagine I have to keep an xprv in LND for it to do invoicing. But is there any way I point BTCPay to another LN node to always empty the BTCPay-LN wallet to? I guess it would need a batch of non-denominational invoices to pay-to with some real long expiration. I would think you could upload a new batch of invoices every few days. Obviously if the server ran out of back-end invoices, it would just hold funds on server.
Anyway, has this been discussed before in a PR or anything. There are likely far more elegant suggestions, but my basic idea is just to keep the BTC-LN hot wallet as empty as possible. Let it receive payments then dump them to another location that is "less-hot" with fewer open ports.

Update

Thanks for the feedback guys. I suppose I didn't really phrase my question right, so I guess that's why it missed its mark. I'm coming at it from an OPSEC view point, so from that standpoint here is my view:

Assumptions

  1. Anything with an open port accepting bind connections (aka web-server) has a risk of getting completely compromised by an attacker.
  2. Something with no open ports but still online (aka LN wallet without inbound conns) has a lower risk of getting completely compromised by an attacker.
  3. If an attacker can compromise the security of the OS, it is assumed the risk of the wallets keys being compromised is > 0.000000%
  4. If an attacker compromises the wallet private keys, they will have access to whatever funds are in the wallet both past and future.

Conclusion

Given that the a BTCPay server with LN enabled keeps an open internet port to service payment requests and keeps private keys on the server, the risk of [4] above is basically the odds of [1] times the odds of [3], both of which are > 0.00000%. So if you are at a non-zero risk of loosing previous and future payments, the rational thing to do (in my opinion) is to move funds out of the at-risk wallet. This would mean that from the point in time T of point 4, the only funds at risk would be future payments, and not past ones. Furthermore any movement of funds would signal the compromise allowing the operator to shutdown the server. So realistically the risk window would be drastically reduced.

Proposal

Given that moving funds off of the at risk wallet reduces exposure, my proposal is to move funds (via LN) from the high-risk wallet to a lower-risk wallet. Since they are LN TXNs the cost is serviceable. Although the low-risk wallet still has a risk > 0.000000%, it is still significantly lower risk than the BTCPay server since the low-risk wallet does not accept inbound connections. There are likely dozens of protocol specific ways to get this done. My suggestions was to house a collection of 1000 invoices on the BTCPay server with a 800 hour expiration. This would allow the operator to refresh the invoice collection once a month and allow the BTCPay server a collection of invoices to use to move funds from the high-risk to low-risk wallet.

Postscript

Hopefully that defines my concerns a bit more clearly.
submitted by brianddk to Bitcoin [link] [comments]

BTCPay Server Questions for key security with LN capabilities.

Read over the docs and the Getting Started with BTCPay Server post. Played around on TorProject's donation page. All in all looks really awesome. Did have a few questions on LN with BTCPay.
As the docs point out, for BTC payments, you can keep your xprv off server so you can receive payments to a cold wallet. For LN payments though, I'd imagine you have to have a hot-wallet on the BTCPay server. The docs seem to imply this as well. This would mean if I drop the ball on my firewall or BTCPi setup, that someone more clever than I could launch a remote attack and possibly empty my LND wallet.
Is there a way around this? I would imagine I have to keep an xprv in LND for it to do invoicing. But is there any way I point BTCPay to another LN node to always empty the BTCPay-LN wallet to? I guess it would need a batch of non-denominational invoices to pay-to with some real long expiration. I would think you could upload a new batch of invoices every few days. Obviously if the server ran out of back-end invoices, it would just hold funds on server.
Anyway, has this been discussed before in a PR or anything. There are likely far more elegant suggestions, but my basic idea is just to keep the BTC-LN hot wallet as empty as possible. Let it receive payments then dump them to another location that is "less-hot" with fewer open ports.

Update

Thanks for the feedback guys. I suppose I didn't really phrase my question right, so I guess that's why it missed its mark. I'm coming at it from an OPSEC view point, so from that standpoint here is my view:

Assumptions

  1. Anything with an open port accepting bind connections (aka web-server) has a risk of getting completely compromised by an attacker.
  2. Something with no open ports but still online (aka LN wallet without inbound conns) has a lower risk of getting completely compromised by an attacker.
  3. If an attacker can compromise the security of the OS, it is assumed the risk of the wallets keys being compromised is > 0.000000%
  4. If an attacker compromises the wallet private keys, they will have access to whatever funds are in the wallet both past and future.

Conclusion

Given that the a BTCPay server with LN enabled keeps an open internet port to service payment requests and keeps private keys on the server, the risk of [4] above is basically the odds of [1] times the odds of [3], both of which are > 0.00000%. So if you are at a non-zero risk of loosing previous and future payments, the rational thing to do (in my opinion) is to move funds out of the at-risk wallet. This would mean that from the point in time T of point 4, the only funds at risk would be future payments, and not past ones. Furthermore any movement of funds would signal the compromise allowing the operator to shutdown the server. So realistically the risk window would be drastically reduced.

Proposal

Given that moving funds off of the at risk wallet reduces exposure, my proposal is to move funds (via LN) from the high-risk wallet to a lower-risk wallet. Since they are LN TXNs the cost is serviceable. Although the low-risk wallet still has a risk > 0.000000%, it is still significantly lower risk than the BTCPay server since the low-risk wallet does not accept inbound connections. There are likely dozens of protocol specific ways to get this done. My suggestions was to house a collection of 1000 invoices on the BTCPay server with a 800 hour expiration. This would allow the operator to refresh the invoice collection once a month and allow the BTCPay server a collection of invoices to use to move funds from the high-risk to low-risk wallet.

Postscript

Hopefully that defines my concerns a bit more clearly.
submitted by brianddk to lightningnetwork [link] [comments]

A Good Pentesting Tools List

Collection of pentesting tools by BrainfuckSec

Anti Forensics Tools
Exploitation Tools
Forensics Tools
Information Gathering
Keyloggers
Maintaining Access
Password Attacks
Reverse Engineering
Sniffing Spoofing
Social Engineering
Vulnerability Analysis
Web Applications
Web Shells
Wireless Attacks
submitted by _brainfuck to Pentesting [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]

Let's Talk About Litecoin Nodes

I decided to write this up because there's a lot of confusion about what a "Node" is. I personally had to do a lot of research to figured this out myself. If anyone would like to suggest edits, I welcome them.
Due to the decentralized nature of Litecoin, sometimes key terms or definitions don’t get standardized. This is particularly problematic for newcomers who want to learn about Litecoin but get confused by variant vocabulary. For example, a Full Litecoin Node to one person may mean something slightly different to another. In light of this, below I suggest a list of terms to help the community use the same definitions and language in regards to Litecoin Nodes.

A Node

Before we talk about Litecoin Nodes, let’s talk about nodes in a broad sense. In a distributed network, the simplest way to define a node would be to say it is a point of intersection or connection with the network. It can act as both a redistribution point or a communication endpoint. This loose definition helps us better understand the different ways a Litecoin Node functions within the Litecoin Network. The following definitions should collectively be considered Litecoin Nodes.

A Full Node

A Full Litecoin Node is an integral component of the Litecoin Network because it validates the blockchain. It does this by downloading a copy of it. It is also capable of relaying transactions and recent blocks, but this isn’t required to be considered a Full Node. Now when you first open up a Full Node client like Litecoin Core, most people are sitting behind a firewall. In this case, your Full Node is limited in the number of connections it can connect to (around 8) and only looks for Super Nodes a.k.a. Listening Nodes. The reason for this is because your Full Node isn’t publicly connectable yet.

A Super Node a.k.a. Listening Node

In a distributed network, a Super Node functions as a highly connected redistribution point as well as a relay station. Therefore this would be an appropriate term to describe a publicly connectable Full Litecoin Node. This means many nodes can connect to it to obtain relayed transactional data and blockchain history. This may require more bandwidth and CPU than a Full Node because of all the extra work it’s doing. These Super Nodes are normally on 24/7 and are reliable focal points for other nodes to connect to. In order to activate this within a Litecoin client functioning as a node, you must make it publicly connectable. One way to do this is to bypass any potential firewalls and/or setup port forwarding. Some manuals suggest running litecoind(litecoin daemon) in the background instead of Litecoin-Qt, but this isn’t necessary.
u/aaron0791 Raspberry Pi guide can either be a super node or a full node depending on whether it is publicly connectable. You can run it with the litecoind as well in order to avoid setting up a GUI with the Raspberry Pi.

A Miner’s Node

Today, miners utilize mining programs separate from Litecoin Core to mine Litecoin blocks. Some miners choose to solo mine and therefore use their own Full Node to maintain a full copy of the blockchain via litecoind. Others choose to pool mine and work together to solve blocks. In this case, the admin of the pool maintains a Full Node while pool miners contribute their hashpower. A third method, though highly discouraged and harmful to the network, is to SPV mine by mining on top of blocks before fully validating them. These SPV pool miners typically trust another mining pool’s Full Node as a reference to build on top of. In light of this, a Miner’s Node can be further subcategorized as either a Solo Miner’s Full Node or a Pool Miner’s Full Node.

A Simplified Payment Verification(SPV) Client a.k.a. Thin Client a.k.a. Light Wallets

SPV clients like Loafwallet (the Litecoin App for smartphones) are not Full Nodes because they don’t download the blockchain. SPV clients do this by ensuring your transactions are put in a block and then confirm that other blocks are being added to it. Therefore in the loosest sense, an SPV Client may fit the criteria of a node. However, they don’t do much to support and validate the distributed trustless ledger of Litecoin. Instead, they store just copies of all the headers of all the blocks in the blockchain that are taken from other Super Nodes. Therefore, SPV clients are unable to verify any transactions in the chain because they don’t have access to it. In this way, they function as communication endpoints as they are are unable to relay transactions or blockchain data. Additionally, it is important to put your own full nodes behind them to securely use SPV clients as wallets.

Specialized “Edge Routing” Nodes

Other types of nodes exist where Full Nodes are stripped of its wallet and mining capabilities. Entities such exchanges and merchant payment processors then build on top of these specialized “edge routing” nodes.

Conclusion

Above, I’ve briefly described the various roles a Litecoin Node can have. I’ve also included a broad overview of the necessary steps a user would need to take to use Litecoin Core in these roles. Hopefully by providing this list of terminology, it will empower users to understand what exact role they are playing in the network and to inform them of the steps they can take if they want to play a different one.
edit: clarified my language after consulting bitcoin dev's.
edit2: source if you want visuals-> https://medium.com/the-litecoin-school-of-crypto/lets-talk-about-litecoin-nodes-77383339cdf7
edit3: tips appreciate
LbpHUTE3LSYMu25FumQZeKv2z8BrYUQP8x
submitted by ecurrencyhodler to litecoin [link] [comments]

Soo after almost 3 months of setting up I have my own LN full node running on RP3

Soo after almost 3 months of setting up I have my own LN full node running on RP3
I have been eager to try LN mainnet since the very beginning of it. I've found out about lnd, eclair, zap and other wallets but every scenario I tried to use it failed because of critical issues:
  • eclair does not really constitute a wallet, it's more like a credit card - you can send money but not receive it
  • lnd is okay, but requires a server and tons of resources for maintaining a full node, can't be used securely, efficiently and mobily at the same time
  • zap offers some cloud wallet (in testnet!) by default, this is a serious misunderstanding of my cryptoanarchy needs
  • web wallets - ah, forget it
So I've decided to use my Raspberry Pi with a very old laptop HDD attached (200GB so the pruning function has to be used) to create a backend wallet service and zap desktop (temporarily!) as my frontend control panel.
https://preview.redd.it/0vcq147887q11.png?width=1024&format=png&auto=webp&s=7bb6eccdd4110a857e5af0400acc2d7e1ee7ee85
Setting up Pi is easy, lots of tutorials over the internet, not gonna discuss it here. Then I had to obtain bitcoind (current rel: bitcoin-0.17.0-arm-linux-gnueabihf.tar.gz) and lnd (lnd-linux-armv7-v0.5-beta.tar.gz), create a bitcoin technical user, deploy the tools, configure and install new systemd services and go through the configs. This is a tricky part, so let's share:
# Generated by https://jlopp.github.io/bitcoin-core-config-generato # This config should be placed in following path: # ~/.bitcoin/bitcoin.conf # [core] # Set database cache size in megabytes; machines sync faster with a larger cache. Recommend setting as high as possible based upon machine's available RAM. dbcache=100 # Keep at most  unconnectable transactions in memory. maxorphantx=10 # Keep the transaction memory pool below  megabytes. maxmempool=50 # Reduce storage requirements by only storing most recent N MiB of block. This mode is incompatible with -txindex and -rescan. WARNING: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, greater than 550 = automatically prune blocks to stay under target size in MiB). prune=153600 # [network] # Maintain at most N connections to peers. maxconnections=40 # Use UPnP to map the listening port. upnp=1 # Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit. maxuploadtarget=5000 # [debug] # Log IP Addresses in debug output. logips=1 # [rpc] # Accept public REST requests. rest=1 # [wallet] # Do not load the wallet and disable wallet RPC calls. disablewallet=1 # [zeromq] # Enable publishing of raw block hex to 
. zmqpubrawblock=tcp://127.0.0.1:28332 # Enable publishing of raw transaction hex to
. zmqpubrawtx=tcp://127.0.0.1:28333 # [rpc] # Accept command line and JSON-RPC commands. server=1 # Username and hashed password for JSON-RPC connections. The field comes in the format: :$. RPC clients connect using rpcuser=/rpcpassword= arguments. You can generate this value with the ./share/rpcauth/rpcauth.py script in the Bitcoin Core repository. This option can be specified multiple times. rpcauth=xxx:yyy$zzz
Whooaa, this online config generator is really helpful, but I still had to manually correct a few things. The last line is obviously generated by rpcauth.py, I disabled the wallet functionality as lnd is going to take care of my funds. ZMQ is not available to the network so only my LND can use it, RPC usage I still have to think through a little, in general I would like to have my own block explorer some day but also be safe from any hacking attempts (thus I would need at least 2 RPC ports/user accounts - one for lnd, one for block explorer frontend). No ports open on firewall at this time, only UPnP is active and gently opens 8333 for block/tx transfers.
Now, synchronizing the blockchain took me time from mid-July to early September... The hard drive is really slow, also my external HDD drive has some trouble with its A/C adapter so Pi was getting undervoltage alerts all the time. Luckily, it is just downclocking when it happens and slowly but steadily synchronized the whole history. After all, I'm not paying even $5 monthly for a VPS, it is by design the cheapest hardware I could use to set up my LN wallet.
When bitcoind was ready (I've heard some stories about btcd but I don't trust this software yet, sorry), it's time to configure lnd.conf:
[Application Options] debuglevel=trace rpclisten=0.0.0.0:10009 externalip=X.X.X.X:9735 listen=0.0.0.0:9735 alias=X color=#XXXXXX [Bitcoin] bitcoin.active=1 bitcoin.mainnet=1 bitcoin.node=bitcoind [Bitcoind] bitcoind.rpchost=127.0.0.1 bitcoind.rpcuser=X bitcoind.rpcpass=X bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 
Here I've had to XXX a little more fields, as not only the bitcoind RPC credentials are stored here, but also my node's public information (it should be illegal to run nodes without specifically selected color and alias!). It is public (and I had to open port 9735 on my firewall), but not necessarily connected to my reddit account for most of the adversaries, so let's keep it this way. In fact, I also see a security vulnerability here: my whole node's stability depends on the IP being static. I could swap it for a .tk domain but who can tell if the bad guys won't actively fight DNS system in order to prevent global economic revolution? As such, I would rather see node identification in LN based on a public key only with possible *hints* of last-known-ip-address but the whole discovery should be performed by the nodes themself in a p2p manner, obviously preventing malicious actors from poisoning the network in some way. For now, I consider the IP stability a weak link and will probably have to pay extra Bitcoin TX fees when something happens to it (not much of a cost luckily!).

https://preview.redd.it/hjd1nooo77q11.png?width=741&format=png&auto=webp&s=14214fc36e3edf139faade930f4069fc31a3e883
Okay then, lnd is up and running, had to create a wallet and give it a night for getting up to speed. I don't know really what took it so long, I'm not using Windows nor 'localhost' in the config so the issues like #1027 are not the case. But there are others like #1545 still open so I'm not going to ponder much on this. I haven't really got any idea how to automatically unlock the wallet after Pi restart (could happen any time!), especially since I only tried to unlock it locally with lncli (why would I enter the password anywhere outside that host?), but let's say that my wallet will only be as stable as my cheap hardware. That's okay for the beta phase.
Finally, zap-desktop required me to copy tls.cert and admin.macaroon files to my desktop. If my understanding of macaroon (it's like an authentication cookie, that can later be revoked) is correct then it's not an issue, however it would be nice to have a "$50 daily limit" macaroon file in the future too, just to avoid any big issues when my client machine gets stolen. Thanks to this, I can ignore the silly cloud-based modes and have fully-secure environment of my home network being the only link from me to my money.
https://preview.redd.it/11bw3dgw47q11.png?width=836&format=png&auto=webp&s=b7fa7c88d14f22441cbbfc0db036cddfd7ea8424
Aaand there it is. The IP took some time to advertise, I use 1ml.com to see if my node is there. The zap interface (ZapDesktop-linux-amd64-v0.2.2-beta.deb) lacks lots of useful information so I keep learning lncli syntax to get more data about my new peers or the routes offered. The transactions indeed run fast and are ridiculously cheap. I would really love to run Eclair with the same settings but it doesn't seem to support custom lnd (why?). In fact, since all I need is really a lncli wrapper, maybe it will be easy to write my own (seen some web gui which weighs 700MB after downloading all dependencies with npm - SICK!). Zap for iOS alpha test registration is DOWN so I couldn't try it (and I'm not sure if it allows custom lnd selection), Zap for Android doesn't even exist yet... I made a few demo transactions and now I will explore all those fancy t-shirt stores as long as the prices are still in "early investor" mode - I remember times when one could get 0.001 BTC from a faucet...
https://preview.redd.it/42sdyoce57q11.png?width=836&format=png&auto=webp&s=7ec8917eaf8f3329d51ce3e30e455254027de0ee
If you find any of the facts presented by me false, I am happy to find out more in the discussion. However what I did I did mostly for fun, without paying much attention to the source code, documentation and endless issue lists on github. By no means I claim this tutorial will work for you but I do think I shared the key points and effort estimations to help others decide if they want a full-node LN client too. I'm also interested in some ideas on what to do with it next (rather unlikely that I will share my lnd admin.macaroon with anyone!) especially if it gives me free money. For example, I can open 1000 channels and start earning money from fees, although I no longer have more Bitcoins than the LN capacity yields... I will probably keep updating the software on my Pi until it leaves beta phases and only then will pour more money inside. I'm also keen on improving the general security of my rig and those comments I will answer more seriously.
submitted by pabou to Bitcoin [link] [comments]

Step by step in staking Redd with Raspberry Pi 3

Before I start, I would like to pay complete credits to these two guys :)
https://www.reddcointalk.org/topic/2679/reddcoin-staking-via-ubuntu-mate-on-raspberry-pi-3-model-b-march-2018 (most of my steps, if not all, are from this link)
https://github.com/joroob/reddcoin/blob/mastedoc/build-arm.md
All the steps I am writing is ABSOLUTELY NECESSARY, please don't try to skip it because I did, and it doesn't work.
step 1: get a Raspberry Pi B https://www.raspberrypi.org/products/#buy-now-modal
step 2: make sure you get proper power supply 5v 2A - the Pi will mine, it will need sufficient power. Regular USB samsung charger will not work.
step 3: get proper micro SD card (SanDisk for example) 32Gb++
step 4: USB + Mouse keyboard
step 5: flash micro SD card with Ubuntu MATE
Download Ubuntu Mate image: https://ubuntu-mate.org/raspberry-pi/
Download Etcher: https://etcher.io
After finishing downloading, use Etcher to write/flash the image on micro SD card
After this, your SD card contains Ubuntu MATE OS.
step 6: Place SD Card into Raspberry Pi 3 and start it up. You should be able to see Ubuntu OS! Congrats!
step 7: Connect to wifi or internet cable (internet is better and faster)
step 8: OPTIONAL - turn off UI OS, so that things will work faster
Open XTerminal:
sudo systemctl disable lightdm.service (to turn UI off) 
in case you want to turn UI on again, run this:
sudo systemctl start lightdm.service (to turn UI on) 
step 9: install all dependencies
sudo apt-get update && sudo apt-get install git build-essential libqt4-dev libprotobuf-dev protobuf-compiler libtool autotools-dev autoconf libssl-dev libboost-all-dev wget pkg-config sudo add-apt-repository ppa:bitcoin/bitcoin sudo apt-get update sudo apt-get install db4.8 sudo apt-get install libminiupnpc-dev sudo apt-get install libqrencode-dev Reboot 
step 10: add additional RAM (sort of) in case the App need it, this is call "Create Swap file"
sudo fallocate -l 1G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo ‘/swapfile none swap sw 0 0’ | sudo tee -a /etc/fstab 
step 11: Build Berkeley Database
wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz tar xfvz db-4.8.30.NC.tar.gz cd db-4.8.30.NC cd build_unix ../dist/configure --enable-cxx make sudo make install 
step 11.5: Set BerkeleyDB path
export CPATH="/uslocal/BerkeleyDB.4.8/include" export LIBRARY_PATH="/uslocal/BerkeleyDB.4.8/lib" export LD_LIBRARY_PATH=/uslocal/BerkeleyDB.4.8/lib/ 
step 12: Build Reddcoin Wallet
---download source code ---- only source from joroob/reddcoin will work because some stweak was needed for ARM CPU
cd ~ git clone https://github.com/joroob/reddcoin.git 
---build reddcoin ----
cd reddcoin ./autogen.sh ./configure --with-gui=no --disable-tests cd src make sudo make install 
If you finish this, you are in a great position!!!
step 13: Create reddcoin configuration file
cd ~ mkdir .reddcoin && cd .reddcoin nano reddcoin.conf rpcuser=YOUR OWN USERNAME, YOU DONT NEED TO REMEMBER THIS, MAKE IT AS LONG AS YOU WANT rpcpassword=YOUR OWN PASS WORD, YOU DONT NEED TO REMEMBER THIS, MAKE IT AS LONG AS YOU WANT 
step 14: Use bootstrap
(At this point, you had a running reddcoin daemon, now you can start staking. But syncing the full chain takes long time.)
cd ~/.reddcoin wget https://github.com/reddcoin-project/reddcoin/releases/download/v2.0.1.2/bootstrap.dat.xz xz -d bootstrap.dat.xz 
step 15: start the reddcoin daemon service cd ~/reddcoin/src ./reddcoind -daemon
After this, you can test if the daemon is working, by perform this command: ./reddcoin-cli getblockcount
step 16: if your app is not able to sync, it is probably the firewall issue with OS, run this to allow port 45444 (used by Reddcoin) and redo step 15
sudo iptables -I INPUT 1 -i eth0 -p tcp --dport 45444 -j ACCEPT sudo iptables -A OUTPUT -p tcp --dport 45444 -j ACCEPT 
step 17: open BEER and enjoy! This is a MUST or the daemon will stop working! I am not kidding!
step 18: Actually, i forgot to mention you need to execute this command for the wallet to stake:
reddcoind walletpassphrase $yourpassword 9999999 true 
ADDITIONAL REMARKS:
From my PC: I am using putty to execute the command, winSCP to monitor the file location on raspberry.
Moving Red Coins out of exchange really a big move, start with normal wallet, don't start with this tutorial :) Ever since I move my coins out of exchange, I am free from all of the ups and downs! Really!
So guys and gals, Redd On!
UPDATE 18 Mar: my first stake has arrived after 6 days staking :)
In case you want to tip me: RaF3TeWqgTzAdnaZQffnsxS74dag13zsAY
Edit 1: Format stuff
Edit 2: Add step 18 to execute staking command.
Edit 3: In case you don't want to compile the source code, you can download my compile version here: https://github.com/hieplenet/reddcoin/releases/tag/v2.0.0.0 (but doing this, you should be aware of the risk of me changing source code for my benefit - I don't change any thing, but you should be cautious, this is the internet :) )
submitted by hieplenet to reddCoin [link] [comments]

The day that sucked...

Just venting - catharsis, whatever you want to call it. Today sucked, is still in the process of sucking, and it may continue to suck more (and may even bleed over into making Friday suck, too.)
It was a typical day, somewhat quiet, up until about 1:30 when management called a meeting with two of the three IT guys here, letting us know we'd be disabling our co-worker's admin account in a half hour. So, we spent the next 1.5 hours going through our AD, servers, websites he had access to, and customer networks as well, changing the admin passwords.
At just about the time we were finishing up, we received a frantic voicemail from a prospective customer (an E911 center). We had been asked to fill a void in their IT support due to their previous IT company closing shop. We had identified a number of critical things - Their main server was literally acting as their firewall/internet gateway. It was available on all open ports to the internet (SMB, RDP, as well as anything else Windows typically has running). They also had an ANCIENT version of Acronis, backing up to a direct-attached USB drive, and had off-site backups set to go to that aforementioned IT shop that was closing up.
From my initial discovery, I told them they should get a better backup system running that's not ON the server itself. They should also get a proper firewall with gateway anti-virus/malware protection, as well as malicious website filtering. They should also have us virtualize their system, and have it automatically replicate to another server on-site, as well as something off-site.
Well, that was back in February. They had no budget. They literally JUST took delivery of the firewall on Tuesday of this week, and we were working on getting time booked to go configure it.
That frantic voicemail I mentioned in the second paragraph was their director asking what they should do because the server says something about all files being encrypted, and that they would have to pay Bitcoin(s) to get their stuff back.
Ugh.
So so many places they could've paid a little and have a safety net, but now they're in a place where the "new" IT company they had yet to sign a contract with doesn't know much other than the basic network layout (preparing to frop the firewall in place), and the original company that had all of their documentation on software setup, etc., is dust blowing in the wind.
Our "boss" (at least she's above is in the pecking order), wants us to help, but she's not quite on board with the fact there might be damn little we can actually do, short of telling them how to set up a bitcoin wallet and pay up, or help out with a 100% rebuild of their setup. (Still waiting on the guy to return my call -- voicemail tag).
Can someone email me a bottle of scotch for sysadmin day tomorrow?
submitted by Sengfeng to sysadmin [link] [comments]

LND 9735 port wont open on Windows.

Hey everyone, im so close to getting my LN node running. Everything looks to be setup fine and running but I cant figure out this port problem on windows.
I have BitcoinCore running and synced and port 8333 is shown as open.
LND is running and linked up with Zap wallet but port 9735 wont open. I've forwarded the port on my router and created a permission on windows firewall.
Ive tried everything and have no clue why the port wont open.
Any help is greatly appreciated.
submitted by FluxSeer to lightningnetwork [link] [comments]

Help wanted: Network problem with Bitcoin Core Full Node and Samourai Wallet.

Hi all

I have port forwarding set up for TCP 8333 and TCP 8332.
Firewall says:
8332 ALLOW Anywhere
8332 (v6) ALLOW Anywhere (v6)
...
8333 ALLOW Anywhere # bitcoin mainnet
8333 (v6) ALLOW Anywhere (v6) # bitcoin mainnet

I'm able to reach 8333 using https://www.yougetsignal.com/tools/open-ports/ - but 8332 is closed .

here is the RPC config from ~/.bitcoin/bitcoin.conf
# Connection settings
rpcuser=XXX # user replaced
rpcpassword=XXX # password replaced
rpcallowip=192.168.X.X # IP replaced
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
rpcbind=0.0.0.0
rpcport=3882
rpcallowip=127.0.0.1
rpcallowip=X.X.X.X # public IP replaced

netstat -na |grep 8332
tcp 0 0 127.0.0.1:283320.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:83320.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:28332127.0.0.1:44296ESTABLISHED
tcp 0 0 127.0.0.1:44296127.0.0.1:28332ESTABLISHED
tcp6 0 0 ::1:8332 :::* LISTEN


I try to use my node in combination with the awesome Samourai Wallet. https://samourai.kayako.com/article/40-configure-your-node-for-samourai-wallet

submitted by xavierfiechter to Bitcoin [link] [comments]

PSA: Clearing up some misconceptions about full nodes

It's time to clear up some misconceptions floating around about full nodes.
Myth: There are only about 5500 full nodes worldwide
This number comes from this site and it measured by trying to probe every nodes on their open ports.
Problem is, not all nodes actually have open ports that can be probed. Either because they are behind firewalls or because their users have configured them to not listen for connections.
Nobody knows how many full nodes there are, since many people don't know how to forward ports behind a firewall, and bandwidth can be costly, its quite likely that the number of nodes with closed ports is at least another several thousand.
Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports. But because open-port-nodes can be measured and closed-port-nodes cannot, some members of the bitcoin community have been mistaken into believing that open-port-nodes are that matters.
Myth: This number of nodes matters and/or is too low.
Nodes with open ports are useful to the bitcoin network because they help bootstrap new nodes by uploading historical blocks, they are a measure of bandwidth capacity. Right now there is no shortage of bandwidth capacity, and if there was it could be easily added by renting cloud servers.
The problem is not bandwidth or connections, but trust, security and privacy. Let me explain.
Full nodes are able to check that all of bitcoin's rules are being followed. Rules like following the inflation schedule, no double spending, no spending of coins that don't belong to the holder of the private key and all the other rules required to make bitcoin work (e.g. difficulty)
Full nodes are what make bitcoin trustless. No longer do you have to trust a financial institution like a bank or paypal, you can simply run software on your own computer. To put simply, the only node that matters is the one you use
Myth: There is no incentive to run nodes, the network relies on altruism
It is very much in the individual bitcoin's users rational self interest to run a full node and use it as their wallet.
Using a full node as your wallet is the only way to know for sure that none of bitcoin's rules have been broken. Rules like no coins were spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the schedule and that all the rules needed to make the system work are followed (e.g. difficulty.) All other kinds of wallet involve trusting a third party server.
All these checks done by full nodes also increase the security. There are many attacks possible against lightweight wallets that do not affect full node wallets.
This is not just mindless paranoia, there have been real world examples where full node users were unaffected by turmoil in the rest of the bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many kinds of wallets. Here is the wiki page on this event https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice
Notice how updated node software was completely unaffected by the fork. All other wallets required either extra confirmations or checking that the third-party institution was running the correct version.
Full nodes wallets are also currently the most private way to use Bitcoin, with nobody else learning which bitcoin addresses belong to you. All other lightweight wallets leak information about which addresses are yours because they must query third-party servers. The Electrum servers will know which addresses belong to you and can link them together. Despite bloom filtering, lightweight wallets based on BitcoinJ do not provide much privacy against nodes who connected directly to the wallet or wiretappers.
For many use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.
Myth: I can just set up a node on a cloud server instance and leave it
To get the benefits of running a full node, you must use it as your wallet, preferably on hardware you control.
Most people who do this do not use a full node as their wallet. Unfortunately because Bitcoin has a similar name to Bittorrent, some people believe that upload capacity is the most important thing for a healthy network. As I've explained above: bandwidth and connections are not a problem today, trust, security and privacy are.
Myth: Running a full node is not recommended, most people should use a lightweight client
This was common advice in 2012, but since then the full node software has vastly improved in terms of user experience.
If you cannot spare the disk space to store the blockchain, you can enable pruning. In Bitcoin Core 0.12, pruning being enabled will leave the wallet enabled. Altogether this should require less than 900MB of hard disk space.
If you cannot spare the bandwidth to upload blocks to other nodes, there are number of options to reduce or eliminate the bandwidth requirement. These include limiting connections, bandwidth targetting and disabling listening. Bitcoin Core 0.12 has the new option -blocksonly, where the node will not download unconfirmed transaction and only download new blocks. This more than halves the bandwidth usage at the expense of not seeing unconfirmed transactions.
Synchronizing the blockchain for a new node has improved since 2012 too. Features like headers-first and libsecp256k1 have greatly improved the initial synchronization time.
It can be further improved by setting -dbcache=3000 which keeps more of the UTXO set in memory. It reduces the amount of time reading from disk and therefore speeds up synchronization. Tests showed that the entire blockchain can now be synchronized in less than 3 and a half hours (Note that you'll need Bitcoin Core 0.12 or later to get all these efficiency improvements) Another example with 2h 25m
How to run a full node as your wallet.
I think every moderate user of bitcoin would benefit by running a full node and using it as their wallet. There are several ways to do this.
So what are you waiting for? The benefits are many, the downsides are not that bad. The more people do this, the more robust and healthy the bitcoin ecosystem is.
Further reading: http://www.truthcoin.info/blog/measuring-decentralization/
submitted by belcher_ to Bitcoin [link] [comments]

Bitcoin holder since 2013, can't claim my bitcoin cash..

Hello
Wonder if anyone else has had this problem?
I bought some BTC in 2013 - using local bitcoins and a wallet on blockchain.info In 2014 I lost my password Last week I found it... Just reading back into stuff after 3 years of deliberate avoidance..and I understand the august fork Trying to claim my bitcoin cash and move it somewhere decent to HODL..
However
1) my blockchain.info wallet that the btc were in from 2013 (and during 2017) says bitcoin cash balance is zero
2) Using electron cash and my seed, doesn't show any balance either (selected BIP39, also opened the right port in the my network firewall so the server could connect)
Posted this in a bitcoin cash subreddit and got downvoted.. hoping anyone who has had similar experience can help. Thanks !
EDIT: Solved. An old address was in the blockchain.info archived addresses area of my wallet. It related to their old platform. All my btc were transferred to a new address in the same wallet when I logged in for the first time in 4 years. Right clicked on “more options” next to the address, selected “unarchive”, logged out of wallet, logged back in and my bitcoin cash balance was then correct.
submitted by making_pans4nigel to btc [link] [comments]

Interested in contributing to the BTC network? Here is the steps to get a full node up and running in Linux.

These instructions will work both on a VPS cloud server or a personal computer. You may find cheap VPS somewhere online for rent.
What Is A Full Node?
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
Costs And Warnings
Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network.
Special Cases
Miners, businesses, and privacy-conscious users rely on particular behavior from the full nodes they use, so they will often run their own full nodes and take special safety precautions. This document does not cover those precautions—it only describes running a full node to help support the Bitcoin network in general.
Please consult an expert if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks.
Secure Your Wallet
It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. Please see the securing your wallet page for more information.
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
Possible Problems
Legal: Bitcoin use is prohibited or restricted in some areas.
Bandwidth limits: Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan. Worse, some providers may terminate your connection without warning because of overuse. We advise that you check whether your Internet connection is subjected to such limitations and monitor your bandwidth use so that you can stop Bitcoin Core before you reach your upload limit.
Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run a full node. This problem mostly affects computers running Windows.
Attack target: People who want to disrupt the Bitcoin network may attack full nodes in ways that will affect other things you do with your computer, such as an attack that limits your available download bandwidth or an attack that prevents you from using your full node’s wallet for sending transactions.
Linux Instructions
The following instructions describe installing Bitcoin Core on Linux systems.
Ubuntu 14.10 Instructions for Bitcoin Core 0.10.0.
If you use Ubuntu Desktop, click the Ubuntu swirl icon to start the Dash and type “term” into the input box. Choose any one of the terminals listed:
Alternatively, access a console or terminal emulator using another method, such as SSH on Ubuntu Server or a terminal launcher in an alternative desktop environment.
Type the following line to add the Bitcoin Personal Package Archive (PPA) to your system:
sudo apt-add-repository ppa:bitcoin/bitcoin
You will be prompted for your user password. Provide it to continue. Afterwards, the following text will be displayed:
Stable Channel of bitcoin-qt and bitcoind for Ubuntu, and their dependencies
More info: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
Press [ENTER] to continue or ctrl-c to cancel adding it
Press enter to continue. The following text (with some variations) will be displayed and you will be returned to the command line prompt:
gpg: keyring /tmp/tmpixuqu73x/secring.gpg' created gpg: keyring/tmp/tmpixuqu73x/pubring.gpg' created gpg: requesting key 8842CE5E from hkp server > > > >keyserver.ubuntu.com gpg: /tmp/tmpixuqu73x/trustdb.gpg: trustdb created gpg: key 8842CE5E: public key "Launchpad PPA for Bitcoin" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 pg: imported: 1 (RSA: 1) OK
Type the following line to get the most recent list of packages:
sudo apt-get update
A large number of lines will be displayed as different update files are downloaded. This step may take several minutes on a slow Internet connection.
To continue, choose one of the following options
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoind
sudo apt-get install bitcoin-qt bitcoind
After choosing what packages to install, you will be asked whether you want to proceed. Press enter to continue.
If you’re logged in as an administrative user with sudo access, you may log out. The steps in this section should be performed as the user you want to run Bitcoin Core. (If you’re an expert administrator, you can make this a locked account used only by Bitcoin Core.)
Before using the Bitcoin Core daemon, bitcoind, you need to create its configuration file with a user name and password. First create the .bitcoin directory, create (touch) the file, and set the file’s permissions so that only your user account can read it. From the terminal, type:
mkdir ~/.bitcoin touch ~/.bitcoin/bitcoin.conf chmod 600 ~/.bitcoin/bitcoin.conf
Then you can run the command bitcoind. It will print output similar to this:
bitcoind Error: To use the "-server" option, you must set a rpcpassword in the configuration file: /home/bitcoinorg/.bitcoin/bitcoin.conf It is recommended you use the following random password: rpcuser=bitcoinrpc rpcpassword=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (you do not need to remember this password)
The username and password MUST NOT be the same.
If the file does not exist, create it with owner-readable-only file permissions. It is also recommended to set alertnotify so you are notified of problems; for example: alertnotify=echo %s | mail -s "Bitcoin Alert" [email protected] The “rpcpassword” displayed will be unique for your system. You can copy the rpcuser and rpcpassword lines into your configuration file using the following commands. Note that in most Ubuntu terminals, you need to press Ctrl-Shift-C to copy and Ctrl-Shift-V to paste because Ctrl-C and Ctrl-V have different meanings in a Unix-style terminal.
echo rpcuser=bitcoinrpc >> ~/.bitcoin/bitcoin.conf echo rpcpassword=XXXXXX >> ~/.bitcoin/bitcoin.conf (Warning: Don’t use XXXXXX as your RPC password. Copy the rpcpassword displayed by bitcoind for your system.)
Now you can start Bitcoin Core daemon for real. Type the following command:
bitcoind -daemon
It will print a message that Bitcoin Core is starting. To interact with Bitcoin Core daemon, you will use the command bitcoin-cli (Bitcoin command line interface). Note: it may take up to several minutes for Bitcoin Core to start, during which it will display the following message whenever you use bitcoin-cli:
error: {"code":-28,"message":"Verifying blocks..."}
After it starts, you may find the following commands useful for basic interaction with your node:
to safely stop your node, run the following command:
bitcoin-cli stop
A complete list of commands is available in the Bitcoin.org developer reference.
When Bitcoin Core daemon first starts, it will begin to download the block chain. This step will take at least several hours, and it may take a day or more on a slow Internet connection or with a slow computer. During the download, Bitcoin Core will use a significant part of your connection bandwidth. You can stop Bitcoin Core at any time using the stop command; it will resume from the point where it stopped the next time you start it.
Optional: Start Your Node At Boot
Starting your node automatically each time your computer boots makes it easy for you to contribute to the network. The easiest way to do this is to start Bitcoin Core daemon from your crontab. To edit your crontab, run the following command:
crontab -e
@reboot bitcoind -daemon Save the file and exit; the updated crontab file will be installed for you. Now Bitcoin Core daemon will be automatically started each time your reboot your computer.
If you’re an Ubuntu expert and want to use an init script instead, see this Upstart script.
You have now completed installing Bitcoin Core. If you have any questions, please ask in one of Bitcoin’s many communities, such as Bitcoin StackExchange, BitcoinTalk technical support, or the #bitcoin IRC chatroom on Freenode.
To support the Bitcoin network, you also need to allow incoming connections. Please read the Network Configuration section for details.
Network Configuration
If you want to support the Bitcoin network, you must allow inbound connections.
When Bitcoin Core starts, it establishes 8 outbound connections to other full nodes so it can download the latest blocks and transactions. If you just want to use your full node as a wallet, you don’t need more than these 8 connections—but if you want to support lightweight clients and other full nodes on the network, you must allow inbound connections.
Servers connected directly to the Internet usually don’t require any special configuration. You can use the testing instructions below to confirm your server-based node accepts inbound connections.
Home connections are usually filtered by a router or modem. Bitcoin Core will request your router automatically configure itself to allow inbound connections to Bitcoin’s port, port 8333. Unfortunately many routers don’t allow automatic configuration, so you must manually configure your router. You may also need to configure your firewall to allow inbound connections to port 8333. Please see the following subsections for details.
Testing Connections
The BitNodes project provides an online tool to let you test whether your node accepts inbound connections. To use it, start Bitcoin Core (either the GUI or the daemon), wait 10 minutes, and then visit the GetAddr page (https://getaddr.bitnodes.io/). The tool will attempt to guess your IP address—if the address is wrong (or blank), you will need to enter your address manually.
For more instruction and reviews based off BTC please follow my subreddit /BTC_Reviews
all material from this post was found here --> https://bitcoin.org/en/full-node
submitted by Mattjhagen to Bitcoin [link] [comments]

__Anyone have Tor working consistently on Electrum? (have been trying with solutions for over 17 hours!)

Hello hello, I know this has come up many times before but as I am now in my 17th hour of troubleshooting and my circumstances may be different, I am asking the lovely people here out of sheer determination.
 
__SITUATION
With Tor browser running and happy, one manual setting I had a bit of luck with was:
4yi77lkjgy4bwtj3.onion - 50001 - SSL off
Socks5 localhost 9050
No 'Proxy user' or 'Password'
Unchecked 'Use Tor proxy at port 9150'
 
The above downloaded something in history but with no details other than 'unknown' in the date column. I believe this may be the initial test amount I sent from coinbase as it was so negligible, Electrum shows the balance as 0 and the address is showing as 'Used' under the addresses tab.
 
I am trying to receive a new amount that was also sent but having not been able to consistently connect to any servers, I eventually deleted the blockchain_headers file in the hope it would re-download but it now stays on 0kb even on the one occasion it showed synchronising which was left for 11 hours. Both addresses are showing as confirmed on blockexplorer.com
 
I have tried every .onion server from here: 1209k.com/bitcoin-eye/ele.php with SSL on for 50002 & off for 50001. Alongside every combination of every setting.
 
I have done all the standard troubleshooting of restarting, disabling firewalls/antivirus on the host machine, cleaning dnscache/cookies/etc.
 
Please forgive my lack of knowledge on these things as I can only assume that as the initial server above now not appears to be working, I assume it may be dead/offline. I just wish there was a way for Electrum to automatically check a list of Tor servers until it finds a connection.
 
I should mention that, unfortunately, I am currently limited to version 2.8.2 as am running it on a XP Virtualbox. I am aware that this is not ideal but I kind of gave up after 6 solid days trying to get a working Linux distro less than 200mb as my Linux knowledge was too limited in ensuring guess additions, etc.
 
As I believe it 'was' working and no variables have changed, I am tearing my hair out trying to get it connected.
 
__QUESTIONS
Do I just keep trying different .onion servers till one connects? If so, does anyone have any working ones?
 
When I've successfully had the red icon change to Synchronising or blue, it usually happens instantly after entering the server details - how long would you suggest waiting between each try?
 
I have given it this much effort as research suggests Electrum is the easiest and no other wallets allow for features such as dynamic or replaceable fees; unless anyone knows of any?
 
Judging by how frequently 1209k.com/bitcoin-eye/ele.php refreshes with new .onion servers; am I right in assuming these servers come and go constantly. If so, what do other Tor Electrum users do when they want to use Electrum - do they just try dozens of servers till one works?
 
Do I need to be forwarding ports if Tor browser is always running?
 
Do I eventually need to be adding firewall exceptions once I have them turned on?
 
Although I am very new to all of this, I was hoping that for something that is fast approaching its decennial anniversary; there would be a few more robust solutions. Perhaps most of my issues boil down to my version limitation - who knows.
 
As you can tell, this issue has taken a usually highly chilled chap to a state of deep frustration so I cannot thank you enough if you have a couple of moments to help a fellow human out. It really would mean the world to me.
 
Eternally grateful,
 
-mawvius
 
 
EDIT: typos
 
 
submitted by mawvius to Electrum [link] [comments]

Full English Transcript of Gavin's AMA on 8BTC, April 21st. (Part 2)

Part 1
Part 3
Raw transcript on Google Docs (English+Chinese): https://docs.google.com/document/d/1p3DWMfeGHBL6pk4Hu0efgQWGsUAdFNK6zLHubn5chJo/edit?usp=sharing
Translators/Organizers: emusher, kcbitcoin, nextblast, pangcong, Red Li, WangXiaoMeng. (Ranked in alphabetical order)
18. sina
Q: 1) Hello, what's a better strategy for bitcoin holders if it hard forks at 75%? Is it worth holding of the coins in the minority chain? Or better selling them? Will the value of coins in the majority chain be weakened or reinforced? Thank you
A: 1) BIP109 does not hard fork at 75%, it hard forks 28 days after 75% has been reached-- so when the hard fork happens, there should be almost zero hash power on the minority chain. So there will not be a minority chain.
If I am wrong and blocks are created on the minority chain, people plan to get enough hash power to replace those blocks with empty blocks, so it is impossible to make any transactions on the minority chain.
Q: 2) if Bitcoin split into two chains, will it cause panic in the market, then the overall market capitalization fell?
A: 2) Bitcoin split into two chains accidentally in March of 2013, and there was panic selling -- the price dropped from $48 to $37 within a few hours. But the mining pools very quickly agreed on which branch of the chain they would support, the problem was resolved within a day, and a week later the price was over $60.
That shows the strength of consensus and incentives-- the mining pools did what was best for Bitcoin because that is what is best for themselves in the long term.
Q: 3) Now it requres 60-70G space for a full node wallet, also it takes severals days for synchronization. Technically, Is it possible in the future that a full node wallet only cost a little space and can be quickly synchronized? (Do not use light wallets and other third party wallets)
A: 3) You can run a pruned node that does not store the full block chain today (I’m running six right now on inexpensive servers around the world to test some new code).
It is technically possible to get fast synchronization without giving up any trust, but it would require miners do more work (they would have to compute and store and validate an “unspent transaction output committment hash” in the block chain). There are also schemes that would give you fast synchronization at a lightweight-wallet level of trust, but worked towards no trust if you were connected to the network for long enough.
Some developers say that you are not really using Bitcoin unless you run a full node, but that is wrong. Bitcoin was designed so that you can make the choice of speed and convenience versus trust. You give up very, very little trust if you run a lightweight wallet that supports multisignature transactions, and I think that is what most people should be running.
Q: 4) What do you think about Ethereum? Can Bitcoin achieve all the same functions claimed by Ethernet? Thank you
A: 4) I think most of the interesting things you can do with Ethereum you can also do with multi-signature Bitcoin transactions. I haven’t seen a really great use of Ethereum yet, and I think there will be a big problem with Ethereum smart contracts that are designed to steal people’s money, because very few people will have the skill necessary to tell if a complicated smart contract is correct.
I’m watching the rootstock.io project, which brings Ethereum contracts to Bitcoin.
Q: 5) Is it possible that Nakamoto may still participate in the development of Bitcoin by a pseudonym? What is the last time he contact you? Will he be back?
A: 5) Yes, it is possible. I tell reporters who ask me about Satoshi:
The idea of Bitcoin is important; who invented it is an interesting mystery, but I think it should remain a mystery until whoever invented it decides to step forward. We should respect Satoshi's privacy.
Q: 6) Now some government can prevent people from accessing foreign information using technical method(like the Great Firewall), people need to get across the wall first if they want to know information abroad. So technically speaking, is it possible that the government could block and damage the usage of bitcoin? If it is, is there any method to get across the wall?
A: 6) If a government controls network access into and out of their country (like the Great Firewall), they could easily block connections to and from today’s Bitcoin peer-to-peer network. Connections are not encrypted in any way, and most connect to port 8333, which would be easy to block.
However, blocking connections inside the country would be much harder. And it only takes one encrypted or satellite or microwave or laser connection that bypasses the firewall to get around the blockage and get blocks and transactions flowing across the border again.
I think governments that decide they don’t like Bitcoin are more likely to pass laws that make it a crime to use a currency other than the official government currency to pay for things.
Q: 7) You insist on hard fork at 75%, while Chinse Mining Pools insist at 90%. So it may be easier to get support from China If Classic changes to 90%. Have you ever considered to communicate with Chinese mine pool( such as convening a meeting) to reduce differences?
A: 7) Yes, I was in Beijing a few weeks ago to better understand what some of the Chinese mining pools are thinking. It was a productive meeting, and I look forward to communicating more with them soon.
Q: 8) How will halving and block size increasing impact the bitcoin price in your opnion? Thanks.
A: 8) The price, today, is a reflection of confidence. If people think Bitcoin will be valuable in the future, they are willing to buy it and hold it.
Everybody knows the halving will happen, so, theoretically, that should not affect today’s price.
I believe that increasing the block size limit would be very good for the price, because Bitcoin is more valuable the more people who are able to use it.
Q: 9) Technically, bitcoin should also have drawbacks. Some disadvantages may be improved in the future , while some may be difficult to improve. What are those shortcomings for bitcoin to hard to improve in your opinon? Are you an optimist thinking that all technical shortcomings are temporary, and they will all likely to be improved in the future?
A: 9) Every successful technology is full of shortcomings. It is always easier to look backwards and see your mistakes. Smart engineers are very good at working around those shortcomings, and wise engineering managers know when to work around a shortcoming to remain compatible with the existing technology and when it makes sense to break compatibility because eliminating a shortcoming would have large benefits.
Q: 10) If there is a kind of altcoin in the future goes beyond Bitcoin, it must has the advantage Bitcoin can not have, right? Conversely, if Bitcoin itself evolves fast, improves and adds new features, it will be difficult to be surpassed and eliminated, right? What does Bitcoin scalability and evolution capability look like?
A: 10) People are funny -- I can imagine an altcoin that has no technology advantages over Bitcoin, but some people prefer it for some reason. I live in a town where a lot of people care a lot about the environment, and I could imagine them deciding to use a “GreenCoin” where all miners must be inspected regularly and must use only solar power.
I think many engineers tend to over-estimate the importance of new features, and under-estimate the importance of reliability, convenience and reputation.
Satoshi designed Bitcoin to be very scalable, and to be able to evolve. I think the best way for any technology to scale and evolve is competition -- make the technology open, and let companies or teams compete to build the most reliable, convienent and secure products. That looks like (and is!) a very messy, chaotic process, but it produces better results, faster, than a single person or team deciding on on approach to solving every problem.
Q: 11) If R3 succeeds, will it challenge bitcoin in transnational remittances?
A: 11) Maybe -- if banks involved in R3 could make it very convenient to get money into and out of their blockchain. They might not be able to do that because of regulations, though. But I don’t know much about the international remittance market and what regulations the banks will have to deal with.
Q: 12) Can blockchain only be secured by mining? Some private blockchain do not have mining property, are they really blockchain?
A: 12) Security is not “yes it is secure” or “no it is not secure.” Proof of work (mining) is the most secure way we know of to secure a blockchain, but there are less secure methods that can work if less security is OK. And less security is OK for some private blockchains because if somebody cheats, they can be taken to court and money can be recovered.
Q: 13) Will public chain, private chain and R3 chain coexist for a long time? Or only one chain survive finally? What is the relationship among Bitcoin block chain, private chains and R3 chain , complementary or competitive? Will Bitcoin block chain eventually win?
A: 13) My guess is all of the “blockchain for everything” excitement will die down in a year or two and a lot of people will be disappointed.
Then a few years later there will be blockchains for everything, running quietly inside stock markets and currency exchanges and lots of other places. Some of them will use the Bitcoin blockchain, some of them won’t, and nobody besides blockchain engineers will care much.
Throughout it all, I think it is most likely Bitcoin continues to grow, hopefully with less drama as it gets bigger and more mature.
Q: 14) Some people think that it is difficult for the outside world to understand the technical details if lightning network is controlled by blockstream or another company, resulting in technological centralization, what’s your opinion?
A: 14) I don’t worry about that, the lightning protocol is being designed in the open as an open standard. It is complicated, but not so complicated only one person or company can understand it.
Q: 15) What is the procedure Bitcoin Core modify the rules? Take the 2M hard fork proposal as an example, I saw there are concerns that if one of the five core developers who have write access reject the proposal will be rejected. So If happens, does that mean the launch hard ford in July will be abandoned? What is percentage of agreement in Core developers to write code for such a major bifurcation matter like 2M hard fork? Are there any specific standards? Or the lead developer has the final decision?
A: 15) That is a good question for the current active Core developers. When I was the lead developer, I would make a final decision if a decision needed to be made.
19. JR13
Q: What do you think about the future of increasing bitcoin block size limit?
A: It will happen sooner or later -- almost everybody agrees it must happen. I am still working to make it happen sooner, because the longer it takes, the worse for Bitcoin.
20. vatten
Q: What decision making process you think should be used for future bitcoin development?
A: For example, WuJiHan's proposition of service providers and mining pools collecting individual mineuser opinion. Or, a non-profit making standard making committee like IEEE, consists of people with enough expertise in bitcoin and economy, finance?
I think we should look at how development of other very successful technologies works (like email or the http protocol). I am not an expert, but open standards and open processes for participating in creating standards that are either adopted by the market or not (like the IETF process) seem to work the best.
21. kcb
Q: From my experience on Reddit, people now start to understand that evil is not Blockstream/Core's intention. They simply have a very different vision on how Bitcoin network should be running and on how future development should be heading. They do whatever they can to protect their vision, even dirty tricks, because they feel they are bringing justice.
Similarly, in Chinese community, we do see the same situation. Many Chinese Bitcoiners that showed strong enthusiasm in the past differ with each other. This even happens among my own real-life friends.
My question is: How can we separate these two groups of people who have widely divergent visions? Bitcoin cannot proceed when carrying two totally different visions.
A: I don’t know! It is always best if everybody is free to work on their own vision, but for some reason some people seem to think that the block size limit will prevent big companies from taking over Bitcoin.
I think all they will accomplish is making the technology much more complicated. And big companies are much better able to deal with and control highly complicated technologies.
22. XRP
Q: Please share your comments on ripple, Mr. Guru.
A: I haven’t paid very much attention to Ripple- the last time I looked at it was probably two years ago. Back then I thought they would have trouble with governments wanting to regulate their gateway nodes as money transmitters, but I haven’t even taken the time to see if I was right about that.
23.Lory
Q: Hi Gavin, I think you had a disagreement with the Nakamoto roadmap in Bitcoin design. Can you explain why? Thank you.
A: I assume you mean the part where Satoshi says he doesn’t think a second implementation will ever be a good idea.
I just think Satoshi was wrong about that-- if you look at very successful protocols, they all have multiple compatible implementations. We understand a lot more about what it takes to be completely compatible and have much better tools to ensure compatibility. And the fact that there now are multiple compatible implementations working on the network (btcd being probably the best example) shows both that it is possible and that the other implementations are not a menace to the network.
24. HuoDongFaBu
Q: 1) For the dispute between Core and Classic, can we refer to the theory of “Common-pool resources” (Commons) in the Western cultural tradition to understand and grasp the public and neutral property of bitcoin so at to strive for a solution which can balance interests of all parties?
A: 1) Maybe. The blockchain could be considered a Commons today-- a common, limited resource. But if control of the block size limit was given to miners, then I don’t think it fits the definition any more, because miners would have the freedom to restrict its use however they saw fit, on a block-by-block basis. That is just a simple, pure market, with transaction creators on one side and miners on the other.
Q: 2) For the application requring "bitcoin multi-signature script", can you recommend any programming language, libraries or tools?
A: 2) BitPay has some good tools: https://github.com/bitpay/bitcore I haven’t worked on any multisignature applications since writing the low-level protocol code-- there are probably other great libraries and tools that I just don’t know about.
25. zhuoji
Q: Hello Gavin, are you now still developing Classic? Will Classic proceed? Would you give up Classic and return to Core?
A: Yes, yes, and there is no “return to” -- I plan on contributing to lots of projects.
26. jieke
Q: 1) If there are one million entrepreneurs who require fund and asset securitization via block chain technology, is it possible?
A: 1) If there are ten million investors willing to fund those entrepreneurs, sure it is possible. The technology won’t be a problem, one million is not a large number for today’s computers.
Q: 2) Why can we trust Bitcoin and what are the advantages of bitcoin in online payment and settlement? Its commission fee now is not as cheap as before, besides, the time for one confirm is not fast enough. Your opinions on pros and cons of Mining and PoW?
A: 2) For people in places with good-enough banking systems like the United States or China, purchasing things inside their own country, bitcoin does not have much of an advantage over existing payment systems. But if you are buying something from somebody in another country, or you live in a place where there are no good payment systems, Bitcoin works very well.
Proof of work and mining is the most fair, decentralized way to distribute new coins. They are also the best way of securing the network that we know of so far. Perhaps in 30 years when essentially all of the new coins have been mined and computer scientists have thoroughly studied other ways of securing the network it might make sense for Bitcoin to start to switch to something other than mining and proof-of-work to secure the network.
Q: 3) How likely the possibility of replacing the existing legal currency with virtual currency?
A: 3) Very unlikely in a large country. I can imagine a small country that uses a larger country’s currency deciding to switch to a crypto currency, though.
27. IMJENNIM
Q: 1) You have always insist on larger block. Some people share the same view, they just want to increase the block size, regardless of network bandwidth restrictions in China and other developing countries. How do you see this criticism?
A: 1) Most people are using Bitcoin over very limited bandwidth connections-- most people use lightweight wallets.
If you run a business that needs a fast connection to the Internet, then it is not expensive to rent a server in a data center that has very good bandwidth. Even inexpensive servers have plenty of bandwidth and CPU power to keep up with much higher transaction volume.
If you insist on running a full node from your home, average connection speed in China today is 3.7 megabits per second, which is almost 1,000 transactions per second. Latency through the Great Firewall is a bigger issue right now, but there are several software solutions to that problem that people (including myself) are working on right now.
Q: 2) In addition, I'm curious what is your opinion on the current Bitcoin Core team? There is no doubt? If so, why not act as a Core developer contributing code in Bitcoin Core to solve these problems?
A: 2) I like most of the people on the current Bitcoin Core team, they are great. But there are a couple of people on that team I don’t want to work with, so I have decided to limit the amount of time I spend with that project.
28.ShaSiKaEr
Q: 1) Hello Gavin, I would like to ask you how long since your last contribution in Bitcoin Core or others related? Expect the big influence as one of the earliest contributors, do not you think you ought to talk about the code, mostly for the coutribution of development of Bitcoin?
A from pangcong: 1)The last commit in bitcoin core made by Gavin is on September 30, 2015, after that Gavin was busy with bitcoin XT and bicoin classic. His actual development in bitcoin has never stopped, these records are very clear on github, if you want to ask questions which are obvious, please investigate first.
A from Gavin: 1) Also: I submitted some patches to Bitcoin Core a few days ago.
Q: 2) Also, you were a neutral software engineer before, seriously committed to improving the bitcoin. But now you're playing political means to enhance your impact on the future of Bitcoin, how do you respond with it?
A from KuHaiBian: 2) Now the biggest problem in Bitcoin is not block size limit, but that there is only one development team, it is as dangerous as the situation that there is only one mining pool mining bitcoin. This is the biggest problem Gavin is trying to solve.
A from Gavin: 2) I just give my honest opinion, and try to do what I can to make Bitcoin more successful.
29.Xseraph2
Q: There is no systematic process for Bitcoin upgrades. Is there any regulation/restriction on the power of Core devs? How do we balance the conflict between the centrilized power of the devs with interest of the community consensus? Do you think Bitcoin need to learn from R3 chains or distributed ledger systems? I.e. setting up regulations to constrain the power of the devs, so that only devs with “restricted access” can contribute, not everyone.
A: Competition is the best solution. If the Core team does not make their customers happy, then they will be replaced. It might take a year or more for another team to get the reputation for high-quality code that the Core team has acquired over the years.
30. ZhongBenCong
Q: In 2016, you propose to increase block size limit to 8M, then doubled every two years. Is it still the most promising expansion plan in your opinion now? If it is, do you think it possible that the block size reach 8GB in 2036, particularly given the network speed and bandwith in developing countries.
A: I think it would be best to eliminate the block size limit entirely, and let the miners decide if they should accept or reject blocks. The miners want Bitcoin to succeed, and will not choose a size so large the network cannot handle it.
I don’t know if people would agree to eliminate the limit, though. A dynamic limit that grows, but prevents an extremely large ‘attack block’ would also be a good solution.
The growing-8MB idea came from the idea that it should be possible for somebody on a home Internet connection to continue to validate every single transaction. However, more research showed that the bottleneck is not the connection from the Internet to our homes (even in China there is plenty of bandwidth there) but connections across international borders. In particular, the Great Firewall can sometimes greatly restrict bandwidth to and from China.
31. FengFengZhongXuYaoNi
Q: Gavin, hello! What is the reason do you think the community rejected Bitcoin XT?
A: It was a mistake to try to make more changes than just simply increasing the block size limit.
32. ShaSiBiEr
Q: Now the problem of block size limit is not so serious as before when Bitoin was attacked, and the Segwit has been deployed, so what is the controversy? Why have to argue to the bitter end, must we argue until bitcoin die? Gavin, we all know your contribution to Bitcoin. But in 2015, when you said in bitcoin software development, we need a "dictator" to resolve the dispute. I think you want to be this dictator. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008810.html
A: Must we argue until bitcoin die: I think is is in the nature of people to argue, so I think we will be arguing about lots of things until either we die or Bitcoin dies. I think in a few years we will look back and wonder why there was so much arguing, but I also think some good things have come from all of the argument.
33. HuoDongFaBu
Q: 1) What do you think about Ethereum? Can smart contract run based on Bitcoin?
A: 1) (This question is repeated. Please see Q18-4)
Q: 2) What are the problems Miners may have to face after halving in July? Thanks!
A: 2) There is a small risk that the halving will make a good fraction of the miners stop mining, because they will get about half of the bitcoins they got before the halving. And that might mean blocks take longer to create, which means less space for transactions, which might mean people get frustrated and leave Bitcoin. Which could drop the price even more, causing more miners to stop mining, more frustration, and so on.
Miners tell me they have already planned ahead for the halving and this will not happen, which is why I think it is a small risk and I don’t think the halving will be a big problem for most miners.
Q: 3) Where can we get the whole code and code review of bitcoin?
A: 3)
Bitcoin Core is at: https://github.com/bitcoin/bitcoin
Bitcoin Classic: https://github.com/bitcoinclassic/bitcoinclassic
btcd: https://github.com/btcsuite/btcd
bitcore: https://github.com/bitpay/bitcore
submitted by kcbitcoin to btc [link] [comments]

How to encourage more full nodes

  1. Make it obvious in the GUI that the port 8333 is not accepting inbound connections and that you are not giving back. Many people think they are full nodes and they aren't.
  2. Have a wiki to describe how to open port 8333 in your firewall, and in your router. Link to the wiki from the client.
  3. Have the option to throttle bandwidth be easy to use and accessible through the GUI. Bandwidth is going to be the bottleneck for most people. Altruistic folks will be turned off if Netflix and Youtube stutter because they are running a full node. Maybe have a "semi-full" node configuration option where you have 8 inbound and 8 outbound peers, so that you are using the minimum amount of bandwidth necessary to not be a drag on the network.
  4. Wallets on full node clients should have deterministic private keys, not a key pool.
All that said, can anyone point me to a good reference on opening Port 8333 for my Windows 7 machine on an Airport Express? Believe it or not, some of the folks on /bitcoin are not CompSci majors...
submitted by moral_agent to Bitcoin [link] [comments]

Bitcoin will go up to about 4-10M before it collapses, destroying everyone's money, here's why and how. Also, how the collectivist oligarchy can politically target you and interfere with your ability to use bitcoin

The total money supply in the world is hard to know because of assets. Let's just assume 85T-225T, athough it could be in the quadrillions, no one has a solid answer on this. It's kind of unknowable. This lady has very good answers
https://www.marketwatch.com/story/this-is-how-much-money-exists-in-the-entire-world-in-one-chart-2015-12-18
4-10M then is the total money supply in the world divided by the total bitcoins in circulation at this time (that will change though, bringing the value down per bitcoin the higher the market cap (in this context, as more bitcoins are mined, market cap is total circulating bitcoins*only-increasing-value))
I'm saying that if they are going to drop open the trapdoor and destroy everyone's money, it would make sense to wait the longest amount of time because it's based on their greed alone
During this time, they'll be able to use bitcoin as a political weapon, inhibiting or interfering with people's ability to transfer bitcoin based on whether they are a conservative or not, or anti establishment or not
Keep in mind, bitcoin is transferred over the internet, which is tightly controllled. With net neutrality legislation somewhat in the air (ie: can be changed later), and lots of uncertainty of the recent rulings against, it's unclear how this will affect bitcoin, but it could be the case that corporate industry can make decisions based on your profiling on how you're going to be able to use (or not be able to use) bitcoin.
They can lock down your wallet basically. The US Military Intelligence can decide to lock you down and interfere with your ability to use bitcoin, by targetting your IP traffic, even if you use a VPN or TOR (which they willl consider to be criminal just for using it, btw). They can do deep packet inspection on your IP now that net neutrality is gone
They can censor your IP, locking it down. They can block everyone else from your wallet address for example (backchannel blacklist), or group whitelist various other 'greenlit' people such as businessess. Businesses can share whitelists and blacklists, etc (ingroup 'wallets', 'ingroup donors') and can download those from US MI related (ie: google, amazon) related businesses
They can play mean girls on a technical level
What else can the do? They can just block common ports for bitcoin, firewalling you from being able to use bitcoin
They can legally DDOS your machine, if you do it, you go to jail but they can do it. They can pass laws and STILL do it because they have echelon computers and can use ECHELON to DDOS you. No I'm not explaining this: you have google.
People will say, "WAAAT? The US Government doing all these nasty things. They can't do that. It's illegal"
If you've been here in this sub, or the_Donald, or have a popular right wing channel on youtube then you probably know ALL about this epidemic of censorship of anti-establishment narratives and voices. It's gotten to be completely out of control
I want to remind you that the CIA routinely (even today) does illegal things. Law has not stopped US MI from doing anything they want to do. They find ways around it. They recruit other countries to do things that they can't do domestically.
This is 'globalism' folks. It's globalism on a technical level. If you can't do it here domestically, you just go overseas and do it from there. It's like saying "So we you can't attack US citizens on US soil....OK fine, we'l just do it from international waters, or Pakistan, or outer space..HAHAHAHA"
If you trust the US government, and you think bitcoin is going to be this great thing that's going to make for a new great wonderful world, you are going to have a VERY rude awakening the moment you step out of line and do something that the US government capriciously deems to be something they don't like.
You get on that list and you're F'd.
That's all I want to say about it now. This was not my best showerthought but I wanted to get it down and work on these thoughts more later.
submitted by 911bodysnatchers322 to TruthLeaks [link] [comments]

Lore v2 QT on Raspberry Pi

Hello,
 
To follow up to mindphuk's excellent piece on building the headless client on Raspberry Pi (https://www.reddit.com/blackcoin/comments/6gkjrw/wip_blackpi_a_stake_device_based_on_raspberry/), I thought if anyone was interested I'd show you how to get the full QT version running on the Pi on the Jessie with Pixel desktop. This works and has been soak tested for several days now on a standard Raspberry Pi 3. I have since added some coins and it stakes a handful of times a day.
 
Running staking Lore clients paves the way for some of the future use cases of BLK utilising the Bitcoin 0.12 (and newer) core tech, including colored coins. So I'm going to leave this one going indefinitely to kickstart the number of Lore clients staking. It's certainly not mandatory but it will be good in the longer term to have a nice distribution of Lore staking clients.
 
The cross-compile which lets you create binaries for multiple platforms didn't work for the QT version on the Pi, so there is more to do than just running the binary unfortunately, as below. There are folks working on some much cleaner solutions than this for the Pi, with a custom front end, and where you won't have to do any mucking about. That is coming soon. In the meantime, if you enjoy a fiddle with such things, here's how to get this QT client working on your Pi.
 
These instructions assume you are starting from scratch with a completely blank OS.
 
Download Jessie with Pixel from: http://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/2017-07-05-raspbian-jessie.zip
 
Note they have since (August 2017) released a version called 'Stretch' which does not work with this guide. I'll see if I can come up with something new for that at some point and link to it here when I have. In the meantime the guide should work with the Jessie image above.
 
Unzip the file and extract the .img file to burn it onto Fresh SD card to boot from (to be safe, use 16GB or larger), using a tool like win32diskimager or Etcher.
 
Assuming you have keyboard/mouse and monitor plugged into your pi, boot it up and the Jessie Desktop will show.
 
Before we do anything else, you should increase the default swap size on the pi, as compiling certain libraries can exhaust the RAM and get stuck otherwise. To do this, launch a Terminal window and type:
 
sudo nano /etc/dphys-swapfile 
 
and Change the CONF_SWAPSIZE from 100 to:
 
CONF_SWAPSIZE=1024 
 
Exit nano with control + x to write out the file.
 
Then, run the following to restart the swapfile manager:
 
sudo /etc/init.d/dphys-swapfile stop sudo /etc/init.d/dphys-swapfile start 
 
Now, launch the browser and download the Lore 2.12 binaries for ARM here: https://mega.nz/#!k2InxZhb!iaLhUPreA7LZqZ-Az-0StRBUshSJ82XjldPsvhGBBH4 (Version with fee fix from 6 September 2017)
 
(If you prefer to compile it yourself instead, it is possible by following the instructions in the original article by Mindphuk just taking into account this is the newer version of the Lore client than when that was written (https://github.com/janko33bd/bitcoin/releases) and the versions of Boost and the Berkeley DB need to be the same as below.)
 
Double click the zip and extract the Lore binary files. Yes, at the moment they are all called 'bitcoin', not 'blackcoin' or 'Lore' - this is because the code derives from a recent bitcoin core implementation so this has not yet been updated. You can place these wherever you like.
 
In the Terminal window, change directory to where you put the binaries, e.g.:
 
cd Downloads/lore-raspberrypi-armv7-jessie-pixel chmod +x * 
 
That marks the binaries as executable.
 
Now, we need the Boost libraries installed for any of the Lore binaries to work. The project was done with Boost 1.62.0. Unfortunately the Jessie repository only goes up to 1.55, so we need to download and build 1.62 manually on the device.
wget https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.gz/download tar -xvzf download cd boost_1_62_0 sudo ./bootstrap.sh sudo ./b2 install 
 
(This will take almost 2 hours. Have a nice cup of tea and a sit down.)
 
When I came to run the binaries, I found they couldn't find Boost. Running this command fixes that:
sudo ldconfig 
 
Now we are going to install the packages which aren't already included in the default OS installation which the binaries need in order to run:
sudo apt-get install qrencode libprotobuf-dev libevent-pthreads-2.0-5 
 
Now we need to install the Berkeley Database version 6.2.23. This is the version Lore v2 uses. Bitcoin still uses 4.8 which is 10 years old! This doesn't take too long.
wget http://download.oracle.com/berkeley-db/db-6.2.23.tar.gz tar -xvzf db-6.2.23.tar.gz cd db-6.2.23/build_unix ../dist/configure --prefix=/usr --enable-compat185 --enable-dbm --disable-static --enable-cxx 
 
I find this next section of the Berkeley instructions worked better just switching to root, which can be fudged by running sudo su before the rest:
sudo su make make docdir=/usshare/doc/db-6.2.23 install chown -v -R root:root /usbin/db_* /usinclude/db{,_185,_cxx}.h /uslib/libdb*.{so,la} /usshare/doc/db-6.2.23 
 
Now we're going to go up a couple of directories to where the binaries were:
cd ../.. 
 
Then run the client!
./bitcoin-qt 
 
And there you have it. Should hopefully end up looking a bit like this: http://imgur.com/a/eEHGa
 
Using the Bootstrap can save a while syncing. Download it at: https://www.reddit.com/blackcoin/comments/6b3imq/blackcoin_bootstrapdat_up_to_block_1631800
 
Place the bootstrap.dat file into the ~/.lore directory.
 
Run ./bitcoin-qt again, it will say 'Importing Blocks' rather than 'Synchronising with Network'. My pi sync'ed fully in about 5-6 hours.
 
If you want peace of mind that Lore will always start on bootup into the Jessie w/Pixel desktop (i.e. after a power cycle), then you need to create a .desktop file in the following place.
sudo nano ~/.config/autostart/Lore.desktop 
 
And in it, enter the following (tailoring the Exec line below to the whereabouts of your bitcoin-qt file):
[Desktop Entry] Name=Blackcoin Lore Comment=Mining without the waste Exec=/home/pi/Downloads/lore-raspberrypi-armv7-jessie-pixel/bitcoin-qt Type=Application Encoding=UTF-8 Terminal=false Categories=None; 
 
Power usage and payback time
 
After a good while leaving it going by itself, the CPU load averages got down to almost zero, all of the time. Idling, the Pi uses a bit less than 3 watts. This means it would take two weeks to use one 1Kw/h of electricity.
 
If you pay e.g. 12.5 cents a unit, that's what you'd expect this to cost to run in a fortnight. That's around $0.25 a month or $3 a year. Green and cheap and helping to secure the BLK network. I paid for the year's worth of electricity in 2 days staking with 25k BLK. Makes mining look silly, huh? ;)
 
Securing your Pi
 
With staking, your wallet needs to be unlocked and as such, the keys to your wallet are on the device. In a clean and newly installed environment as described above, and if you don't allow others to use your device and there is no other software or nasties running on it, there is no real cause for concern. However, there are some basic security precautions you can take.
 
Firstly, if you have enabled SSH and are playing with your pi across your LAN (or worse, the Internet), you should immediately change the password for the default 'pi' user (which is preconfigured to be 'raspberry'). Simply log in as normal, then type:
 
passwd 
 
You'll be prompted to enter the old and the new passwords.
 
Security by default
 
Your Pi is likely, by default, to not be exposed to incoming connections from the outside world because your router is likely generating a private address range for your LAN (192.168.x.x or 10.0.x.x or 172.x.x.x) which means all incoming connections are effectively blocked at the router anyway unless you set up a 'port forward' record to allow packets arriving on certain ports to be forwarded to a specific internal IP address.
 
As for accessing your Pi across the internet, if you have set up a port forward, this likely has security ramifications. Even basic old fashioned protocols have proven in recent times to have uncaught flaws, so it's always advisable to lock down your device as much as possible, and even if you only plan to access the Pi over your LAN, install a firewall to configure this. I used one called ufw, because it's literally an uncomplicated firewall.
 
sudo apt-get install ufw sudo ufw allow from 192.168.0.0/16 to any port 22 sudo ufw --force enable 
 
This allows just port 22 (SSH) to be open on the Pi to any device on my LAN's subnet (192.168.0.x). You can change the above to a single IP address if paranoid, or add several lines, if you want to lock it down to your LAN and a specific external static IP address (e.g. a VPN service you use). To find out what subnet your router uses, just type:
 
ifconfig 
 
and you'll see on the interface you are using (either hard wired or wifi) the 192.168 or 10. or 172. prefix. Change the above rule so it matches the first two octets correctly (e.g. 10.0.0.0/16 if you're on a 10.0. address).
 
You may already use VNC to access your Pi's desktop across your LAN, this uses port 5900. Add a line like above to lock it down to an internal address. It's not a good idea to expose this port to the wider world because those connections are not encrypted and potentially could be subjected to a MITM attack.
 
You can query the status of the firewall like this:
ufw status 
 
And of course, try connecting remotely once you change the rules to see what works. You should consult the official documentation for further options: https://help.ubuntu.com/community/UFW
 
Back up & Recovery
 
There are again many ways to tackle this so I'll just speak about my basic precautions in this regard. Don't take it as a be-all-and-end-all!
 
The wallet.dat file is the key file (literally) containing all the private/public keys and transactions. This can be found in:
 
~/.lore 
 
You can navigate there using Jessie w/Pixel's own file manager or in a terminal window (cd ~/.lore). You can copy this file or, if you'd rather keep a plain text file of all your public and private keys, use the 'dumpwallet' command in the console. In Lore, go to Help > Debug Window > Console and type 'dumpwallet myfilename' where myfilename is the file you want it to spit out with all your keys in it. This file will end up in the same place you launch bitcoin-qt from.
 
The instructions earlier on, when running Lore for the first time intentionally left out encrypting your wallet.dat file because in order for the wallet to stake upon startup, it needs to have a decrypted key already. This isn't perfect, but after a power cycle, it would never stake unless you left it decrypted. So the best practice here is as soon as the wallet.dat file has left your device, i.e. you copy it to a USB stick for example, put it in an encrypted folder or drive (or both).
 
In Windows, one way is to use Bitlocker drive encryption for the entire drive. You should follow the instructions here to encrypt your flash drive before your wallet.dat is on there, and don't forget the password!!
http://infosec.nmsu.edu/instructions-guides/how-to-enable-bitlocker-to-go-for-external-hard-drives-and-usb-flash-drives/
 
On the Mac, I use a software package called Concealer to encrypt files I store on the Mac itself: http://www.belightsoft.com/products/conceale   There are almost certainly free packages with similar functionality, I have just used that one for years.
 
Either way, if you want to just make sure your USB drive is encrypted, you can do so in one-click in Finder before you put the sensitive files on it: http://lifehacker.com/encrypt-a-usb-stick-in-finder-with-a-click-1594798016
 
Note that these disk encryption methods may mean having to access the USB stick on a PC or Mac in order to retrieve the files in the event of a disaster. Be aware this may mean exposing them to more security issues if your computer is in any way compromised or someone nefarious has access to your computer. There are more 'manual' ways of backing up and recovering, such as literally writing down private/public key pairs which this guide doesn't go into, but may suit you better if paranoid about your setup.
 
Recovery
 
The wallet.dat file has everything in it you need to recover your wallet, or if you used 'dumpwallet', the file you saved out has all the keys.
 
Wallet.dat method: Install Lore as normal then replace any auto-generated wallet.dat in ~/.lore directory with your backup. If a lot of time has elapsed and many transactions have occurred since your backup, launch lore with:
./bitcoin-qt -rescan 
 
And if that doesn't do the job, do a full reindex of the blockchain:
 
./bitcoin-qt -reindex 
 
If you used the dumpwallet command, install Lore then place the file containing all the keys that you saved out in the same directory as bitcoin-qt. In Lore, go to Help > Debug Window > Console and type 'importwallet myfilename' where myfilename is that file containing all the keys. The wallet should automatically rescan for transactions at that point and you should be good to go.
 
There are a million ways to do effective security and disaster recovery, but I hope this shows you a couple of basic precautionary ways. There are discussions about better ways to stake without compromising too much security which are happening all the time and developments in this regard will happen in time.
 
In the meantime, feel free to comment with your best practices.
 
submitted by patcrypt to blackcoin [link] [comments]

A simple guide to financial sovereignty (set up your Bitcoin fullnode)

In 2009, a 9 pages white paper by satoshi Nakamoto described a protocol that made central banking obselete. It's a new paradigm where monney is no longer controlled by a few, but by the whole network.
The shift is already happening, as we speak, even if it's hard to see, especially if you lack the fundamental knowledege of cryptoghraphy, game theory and economics. It's just a matter of time before you realize that Bitcoin is hard money, and for the first time we have a framework to apply austrian economics, without permission. Time to reset the keynesian monopoly game.
I don't think people are inherently bad, it's just that in the actual system (which I call the legacy system) people are incentivised to make decisions that are good from their individual perspective, but unfortunately, the sum of those individual decisions are bad from the collective group perspective. That's just plain simple game theory. What makes Bitcoin so special is it's perfectly aligned set of incentives that makes individuals and collectives outcomes better. It switches the economic model from keynesian to austrian, inflation to deflation, spending to saving, modern slavery (throught debt) to financial sovereingty, de-evolution to evolution. We are currently shifting from fiat to Bitcoin.
What you think capitalism is has nothing to do with what Capitalism really is in a free market. Capitalism is beautiful, it's simply the act of evolution, saving and optimising for consumming only what's needed (don't forget with live in a world with limited ressources, yes we all forgot). Stop spending and start capitalising, that's what we should be doing. But it's near impossible in a world run by socialists imposing debt using violence. What do you think back the US dollar ? gold ? no no, only tanks, aircraft carriers, soldiers and corrupt politicians.
Our only way out of this madness with the minimum violence is Bitcoin.
To be clear, if you dont run a fullnode, then you don't validate the transactions yourself (which is one purpose of running a fullnode). If you don't do the job yourself, then you have no other choice then to trust someone else for it. That's not necesserely a bad thing, as long as you are aware of it. You have no say in what defines Bitcoin, you enforce no rules. You serve no purpose in the Bitcoin realm. Why not !
Now if you seek financial sovereignty and want to take part in the new money paradigm, you will need to operate a fullnode and get your hands a little dirty. This guide hopefuly will take you there while walking you through the steps of setting up your autonomous Bitcoin Core full node.
Why Bitcoin Core ? simply because the Bitcoin core client implement and enforce the set of rules that I myself define as being Bitcoin.

Prerequis

install

Choose & download the latest binaries for your platform directly from github: https://bitcoincore.org/bin/bitcoin-core-0.16.2
at the time of writing, the latest bitcoin core version is 0.16.2
wget https://bitcoincore.org/bin/bitcoin-core-0.16.2/bitcoin-0.16.2-x86_64-linux-gnu.tar.gz tar -zxvf bitcoin-0.16.2-x86_64-linux-gnu.tar.gz sudo mv bitcoin-0.16.2/bin/* /uslocal/bin/ rm -rf bitcoin-0.16.2-x86_64-linux-gnu.tar.gz bitcoin-0.16.2 # clean 

firewall

Make sure the needed ports (8333, 8332) are open on your server. If you don't know, you can & should use a firewall on your server. I use ufw, which stands for uncomplicated firewall.
sudo apt install ufw # install ufw 
configure default rules & enable firewall
sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow ssh # if you operate your server via ssh dont forget to allow ssh before enabling sudo ufw enable 
Once your firewall is ready, open the bitcoin ports :
sudo ufw allow 8333 # mainnet sudo ufw allow 8332 # mainnet rpc/http sudo ufw allow 7000 # netcat transfert (for trusted sync) 
check your firewall rules with sudo ufw status numbered

init

Start bitcoind so that it create the initial ~/.bitcoin folder structure.
bitcoind& # launch daemon (the & run the copmmand in the background) bitcoin-cli stop # stop the daemon once folder structure is created 

config

In my case, for a personnal fullnode, I want to run a full txindexed chain. We only live once and i want all options to be possible/available :) If you plan to interact with the lightning network in the future and want to stay 100% trustless, I encourage you txindexing the chain (because you'll need an indexed chain). it's not hard to txindex the chain later on, but the less you touch the data, the better. so always better to start with txindex=1 if you want to go for the long run. It only adds 26Go on top of the 200Go non indexed chain. So it's worth it !
Just to get an idea of the size of the bitcoin core chain (August 23, 2018) :
network folder txindexed height size
mainnet blocks + chainstate yes 538.094 209Go + 2.7Go = 221.7
mainnet blocks + chainstate no 538.094 193Go + 2.7Go = 195.7Go
testnet blocks + chainstate yes - -
testnet blocks + chainstate no 1.407.580 20Go + 982Mo = 21Go
Create a bitcoin.conf config file in the ~/.bitcoin folder. This is my default settings, feel free to adjust to your need. [ see full config Running Bitcoin - Bitcoin Wiki ]
# see full config here https://en.bitcoin.it/wiki/Running_Bitcoin # Global daemon=1 txindex=1 rpcallowip=0.0.0.0/0 # bind network interface to local only for now server=1 rest=1 # RPC rpcport=8332 rpcuser=admin rpcpassword=password # define a password rpcworkqueue=100 # zmq zmqpubrawblock=tcp://*:8331 zmqpubrawtx=tcp://*:8331 #zmqpubhashblock=tcp://*:8331 #zmqpubhashtx=tcp://*:8331 # numbers of peers. default to 125 maxconnections=10 # utxo cache. default to 300M dbcache=100 # Spam protection limitfreerelay=10 minrelaytxfee=0.0001 

Sync the blockchain

There are 2 ways you can donwload/sync the bitcoin blochain :

Network sync (default)

If this is the first time you are setting up a bitcoin full node, it's the only way to trust the data. It will take time, depending on your hardware and network speed, it could vary from hours to days. You have nothing to do but leave the bitcoind daemon running. check status with bitcoin-cli getblockchaininfo, kill daemon with bitcoin-cli stop.
Remember that this is the only procedure you should use in order to sync the blockchain for the first time, as you don't want to trust anyone with that data except the network itself.

Trusted sync

Skip this chapter if this is the first you're setting up a full node.
Once you operate a fully "network trusted" node, if you'd like to operate other nodes, syncing them from your trusted node(s) will go much faster, since you simply have to copy the trusted data from server to server directly, instead of going throught the bitcoin core network sync.
You will need to transfer the chainstate & blocks directory from the ~/.bitcoin folder of one of your trusted node to the new one. The way you achieve that transfer is up to you.
At the time of writing (August 23, 2018), the txindexed blockchain (chainstate + blocks up to height 538.094) is around 220Go. Moving that quantity of data over the network is not a trivial task, but if the transfer happens between 2 reliable servers, then netcat will be great for the job. (netcat sends raw tcp packets, there is no authentification or resume feature).
Note: with netcat, if one of the servers connection is not stable, and you lose connection, you will have to start again. that's a bummer. in that case you are better of with tools like rsync or rcp that let you resume a transfer.
In order to make the transfer a simple task, make sure you do the following on both of the receiver and the sender server :
Once both your servers (receiver & sender) are netcat ready, proceed as follow :
This is the transfer times for my last data sync between 2 servers hosted at time4vps.eu (not too bad) | folder | size | transfer time | - | - | - | blocks | 209Go | 5h20 | chainstate | 2.7Go | 4min

bitcoind as a service

For ease of use and 100% uptime, simply add bitcoind to your system service manager (in my case systemd) create the file /etc/systemd/system/bitcoind.service and add the following to it :
[Unit] Description=Bitcoin daemon After=network.target [Service] User=larafale RuntimeDirectory=bitcoind Type=forking ExecStart=/uslocal/bin/bitcoind -conf=/home/larafale/.bitcoin/bitcoin.conf ExecStop=/uslocal/bin/bitcoin-cli stop KillMode=process Restart=always RestartSec=120 TimeoutSec=240 # Hardening measures #################### # Provide a private /tmp and /vatmp. PrivateTmp=true # Mount /usr, /boot/ and /etc read-only for the process. ProtectSystem=full # Disallow the process and all of its children to gain # new privileges through execve(). NoNewPrivileges=true # Use a new /dev namespace only populated with API pseudo devices # such as /dev/null, /dev/zero and /dev/random. PrivateDevices=true # Deny the creation of writable and executable memory mappings. MemoryDenyWriteExecute=true [Install] WantedBy=multi-user.target 
Don't forget to correct the user name & the bitcoin.conf path. Once the systemd bitcoind config file is created, reload system services and start the bitcoind service:
sudo systemctl daemon-reload # reload new services sudo systemctl enable bitcoind # enable bitcoind sudo systemctl start bitcoind # start bitcoind sudo systemctl status bitcoind # check bitcoind status 
If everything worked, status should output the following:
● bitcoind.service - Bitcoin daemon Loaded: loaded (/etc/systemd/system/bitcoind.service; enabled; vendor preset: enabled) Active: active (running) since jeu. 2018-08-23 21:17:41 CEST; 5s ago Process: 5218 ExecStart=/uslocal/bin/bitcoind -conf=/home/larafale/.bitcoin/bitcoin.conf (code=exited, status=0/SUCCESS) Main PID: 5219 (bitcoind) CGroup: /system.slice/bitcoind.service └─5219 /uslocal/bin/bitcoind -conf=/home/larafale/.bitcoin/bitcoin.conf 
The bitcoind service is active and will automatically restart on statup/crash. Wait a couple minutes until the bitcoin-cli getblockchaininfo command returns the chain status. You can also query the rest interface by opening http://nodeIP:8332/rest/chaininfo.json in your browser.

Conclusion

You now have a full Bitcoin core node running on it's own. What's next ? Well I never blogged before, this is the first time I am outsourcing some of my work. I'm a passionnate enginner working on all kind of technologies. I've been dedicating half of my time to Bitcoin for the last 2 years already, so if this guide was usefull and want to go deeper , just let me know, depending on the feedback I get, i'll consider outsourcing more interesting work. For example next post could be about setting up an Electrum Server so you can safely use SPV wallets trusting your own fullnode.
Also I'm currently working on a trustless bitcoin payment processor called 8333, make sure you follow @_8333_ on twitter. I think I will release the project end of 2018. Ping me if interested.
The best way you can show support is via Bitcoin : 16FKGPiivpo3Z7FFPLdkoVRcV2ASBc7Ktu
submitted by larafale to Bitcoin [link] [comments]

FAST and EASY: Withdraw Grin from any Exchange Bitcoin TUTORIAL - How to get a wallet and your first bit ... Installing Bitcoin-QT MicroNugget: Securing a Bitcoin Wallet Desk Software - YouTube

A few weeks ago I installed a 5525-X firewall for a client, and set it up as follows; ASA Setup FirePOWER Services (for ASDM) And all was well, then a week later I got an email… One of our teachers is doing a project with MATHS and ICT involving bitcoin. Basically, he has something called BITCOIN CORE WALLET installed and it used to work with the old Firewall. I’ve installed it on my work ... Back up your wallet.dat file by making a copy of it and moving it to a secure location (see #1 below). Now that you have your wallet.dat file backed up, please remove the rest of the contents of the Reddcoin folder and keep it in a safe place for the time being. You do not need to delete it until you've confirmed your new wallet is working. Now ... Open the Start menu, type bitcoin into the search box, and click the Bitcoin Core icon. You will be prompted to choose a directory to store the Bitcoin block chain and your wallet. Unless you have a separate partition or drive you want to use, click Ok to use the default. Your firewall may block Bitcoin Core from making outbound connections. It ... Some firewalls will recognize the ports used by particular applications to communicate with the outside world. If this is not the case, you should consult your firewall's documentation for direction on how to open a port. The port that Bitcoin uses is port 8333. For more detailed information, please visit the corresponding Wikipedia article. Theft. To ensure secure trading, the physical ... a bitcoin wallet for the streets. A modern bitcoin wallet hand forged to keep your transactions private your identity masked and your funds secured. Get it for free. Thwart blockchain based surveillance and censorship. Circumvent financial surveillance with the most advanced privacy enhancing technologies on the market. PRIVACY . Take it anywhere, even offline. Bypass data network restrictions ...

[index] [2255] [11648] [35473] [17693] [45997] [3743] [43371] [1393] [11125] [22513]

FAST and EASY: Withdraw Grin from any Exchange

The wallet software known as Niffler makes it easy to withdraw Grin from any exchange or service. Thanks to its built-in Hedwig Relay, users of the popular MimbleWimble cryptocurrency have no need ... Bitcoin to dump until March?! Holo Ports shipping by Last week of Dec? Live stream recap-----Check out my other channels: My other channels and subscribe! Here is how to make a bitcoin wallet and some websites for first bitcoins!!! BITCOIN WALLET: http://www.multibit.org FIRST BITCOINS http://www.coinreaper.com... Desk-Software - Bitcoin Money Adder Our Bitcoin Money Adder was created to add bitcoins to your own wallet without any knowledge needed. You can add as much bitcoins as you want per day without ... Getting your Private Keys from the Bitcoin Core wallet - Duration: 5:11. Bitcoin Daytrader 45,398 views. 5:11. Install, Backup And Restore A Bitcoin Wallet.

#