network - Is Chromecast's UPnP requirement "a security ...

Best General RenVM Questions | November 2019

Best General RenVM Questions | November 2019

‌*These questions are sourced directly from Telegram

Q: My Hardware wallet (Via MetaMask) is having some issues when interacting with ChaosDEX and the Command Center, can you help?
A: Be sure MetaMask and the Hardware wallet are up to date, and then be sure your contract data is turned on!

Q: Why are there so many steps when submitting a trade for ChaosDEX?
A: We purposely left those in there so developers could see what is happening in the background. For any real consumer-facing app that uses RenVM, these steps can and likely will be hidden.

Q: How is zBTC (RenVM's shifted bitcoin), different than wBTC?
A: WBTC requires people to go through approved merchants (only merchants can mint/burn) and the reserves are held by a centralized entity (BitGo). KYC is also involved when dealing with merchants.
zBTC mint/burn, on the other hand, is completely permissionless and the funds are held in a trustless/decentralized network (RenVM). Anyone (dApps included) can mint and burn at any time.

Q: Can you tell us more about GAS Station integration? What is it and where does the GAS come from? If I do BTC/ZEC exchange-will this GAS be free for me?
A: It’s not free, because Ethereum always needs gas. But, we can still hide the gas. So, if you trade BTC/ZEC, we take a little bit of the BTC/ZEC and turn it into ETH. Just enough to pay for gas. This way, as someone trading BTC/ZEC you don’t need any ETH. You’d don’t even need an Ethereum address of any kind! It’s all about user experience.

Q: What's the plan with SAI to MCD transition for RenVM?
A: We’ll be taking the slower transition approach with regards to MCD. We’ll wait a week or so, see how everything goes, then provide an update (on specifics) for the community in the November Developer Update. In the meantime, there is no action required for those who have provided liquidity to ChaosDEX.

Q: Hi there, I was wondering if you had any more documentation on the ZKP setup you guys are using over sMPC. I didn’t find anything on it in your docs.
A: ZKPs within RenVM are used to verify the compute done by each Darknode (they need to know they’ve done the correct compute, without revealing their secret shares to each other). We have partnered with AZTEC in order to be able to support privacy for tokens once they are on Ethereum. We are also beginning to explore the exact design of bridging ZEC (and other privacy tokens) to Ethereum without compromising privacy. It’s certainly possible, but the design is not settled. Their expertise certainly helps here.

Q: Loong, how come in your tweet you said the 100 transactions were mainly made of people testing BTC <-> DAI swaps, yet the command center shows nothing fee-wise for DAI?
A: Because DAI doesn’t need to cross a blockchain boundary. DAI is also not counted in the Value Locked stats so in reality Value Locked is double that of what's shown.

Q: Why is the exchange rate on ChaosDEX so bad?
A: With lower liquidity, the slippage is exaggerated. This is how Uniswap based exchanges are designed, for more info go here: https://docs.renproject.io/chaosnet/chaosdex.If you like to add liquidity, you can do so by going here: https://chaosdex.renproject.io/?send=BTC&receive=DAI

Q: Btw, what is your current approach for ChaosDex? Will you somehow incentivize people to use it or you think it would be better for users just to get familiar with it and wait for the dapps from mainnet?
A: Tough question. Ultimately, Chaosnet and ChaosDEX are about testing RenVM in the wild. But, lots of use is the best way to get that testing. We will continue to promote it, and also promote testing via the release of challenges (for people earn $ which is always effective). If it begins to gain significant traction we will also look at more serious support for it as a product. But, we plan more than anything to integrate with the existing DeFi apps and DEXs not necessarily compete.

Q: Can someone summarize or point to the definitions of "last cycle, current cycle, change next epoc, and subzero core" please? Just want a better understanding of the numbers they're reporting on the CC 🙂
A: RenVM breaks time down into discrete chunks, called epochs or cycles. This is the time increment at which everything happens: new nodes pending registration will finish registering and become active, existing nodes pending deregistration will leave the network, and payments earned will be distributed

Q: Is 0x a competitor or could they eventually use RenVM to bring cross-chain transactions to their tech?
A: It’s more likely we would see integration with 0x. 0x in itself is not attempting to create cross-chain but could definitely benefit from it.

Q: I wonder why they don't make a docker image instead of having to implement each cloud service?
A: A cloud provider environment is more-or-less identical to using Docker when you aren’t trying to do any kind of orchestration. Even with Docker, you’d have to have the CLI updated on a provider-by-provider basis because they each have different ways of turning on machines. The setup ultimately ends up more complex, because you need to configure UPnP and storage. And, you also end up paying a small (but noticeable) performance hit.

Q: It would be good to be able to see prices/stats without metamask.
A: Yep, agreed! We’ll be adding that.

Q: Do or did ZKPs in Ren require a trusted setup ceremony as well?
A: Yes, but we are also exploring using STARKs at the moment (which don’t need a trusted setup).

Q: I had some issues with signing Darknode contract previously. I had to unregisteregister the ledger every time I wanted to sign a transaction. Now I sent some ether to a metamask account that doesn't use a hardware wallet and it worked. Now, I'm not sure where the DAI will go. I guess to the address that signed the transaction?
A: It will go to the address that was connected at the time the transaction was initiated: eg the hardware wallet.

Q: For BTC withdrawals, how much collusion can be tolerated before it would be considered insecure? In the docs, it mentions The safety and liveliness of RenVM assumes that less than 1/3rd of Darknodes are colluding adversaries. Does this apply for BTC withdrawals? Or would it be a different number? I guess it is an acknowledged issue that (b) must be less than (a) and the requirement for 2/3 of tokens would make the attack a lot harder to carry out. Suppose a single party obtains 1/3 of tokens, and obtains the private key for existing BTC deposit addresses is it possible for the tokens to be unbonded, sold after 3 months, then withdraw the BTC in the addresses?
A: No, by that time, the current keys are rotated. The timings are such that any Darknode that is disbonded no longer holds shares of an active key. It’s worth pointing out, collusion in RenVM is a little harder than in some existing networks because the act of attempting collusion can cause your bond to be slashed. To collude, you need to reveal your shares of a secret. This share can be revealed to the blockchain by the person with whom you’re attempting to collude to slash your bond. So realistically, this collusion has to be between very few parties that trust each other.

Q: Seems GAS usage for RenVM trades are a bit higher than normal?
A: The BTC to DAI swap does technically consists of 4 ERC-20 Transfers (per Etherscan), so the GAS cost is a bit more than a single ETH transaction. We have designed the ChaosDEX to be clear and easy to read, not optimized at all (for example, there are more ERC20 transactions than necessary). To be clear though, interop transactions are always going to need more “gas” than normal transactions. Because you need to pay BTC fees as well as ETH fees as well as RenVM fees. We believe we can keep these low enough that the value gain (being able to use BTC on DeFi) is still worth it.

Q: How safe are the Darknode contracts during Chaosnet?
A: Darknode Registry contracts (the ones in charge of your REN during registration) have been audited previously by ChainSecurity. They’re being reviewed again right now, alongside all of the other contracts/consensus algorithm / sMPC algorithm. The risk is confined almost entirely to users, very little to behaving Darknodes (which is why we encourage people not to trade huge quantities on ChaosDEX in a single go).

Q: Given the security parameters of RenVM, is there a hard cap on how much can be locked in RenVM Chaosnet?
A: At the moment, it’s not a hard limit. This is something enforced by the users (don’t shift if it’s not safe). This is a theoretical limit, it is a lower bound above which an adversary might be able to profit from attacking the network (if they pull the attack of perfectly)

Q: Is there a reason all the info on Darknode via the Command Center is public?
A: It’s the blockchain. All this information is public, not displaying it in the UI might lead people to believe that some information is private that actually isn’t. This information actually needs to be public in order for the system to function as expected.

Q: What's the difference between ChaosDEX and RenVM Chaosnet?
A: RenVM Chaosnet and ChaosDEX are very different things.
RenVM Chaosnet has no understanding of “what the application is” that it’s minting ZBTC for. It accepts BTC on Bitcoin and mints ZBTC on Ethereum (and vice versa). What happens while the ZBTC is on Ethereum is completely opaque to RenVM Chaosnet.
The ChaosDEX is an application. It’s deployed to Ethereum Mainnet and uses RenVM Chaosnet to gain access to Bitcoin Mainnet. When you transfer BTC to ChaosDEX what’s actually happening is:
  1. BTC transaction is sent on Bitcoin.
  2. RenVM Chaosnet sees it and creates an authorizing signature to mint ZBTC. 3. The user submits this authorizing signature to the ChaosDEX smart contract on Ethereum. This triggers a big (but single) transaction that does multiple things at once.
Let’s assume you are selling BTC. Then (a) mints ZBTC, (b) sends that ZBTC to the swapping engine inside ChaosDEX smart contract, (c) sends the resulting DAI to your nominated address. This is all one single Ethereum transaction so the user *feels* like they never touched ZBTC.
But, what if you’re buying BTC? Well, (a) sends the DAI to the swapping engine, (b) gets back ZBTC, (c) immediately burns the ZBTC (and RenVM automatically sees this and sends BTC to your nominated address). Again, this is all one single Ethereum transaction so the user *feels* like they never touched ZBTC. The reality is that ZBTC is still being used, but RenVM is designed to allow apps to hide it from users for the best possible UX.
At the end of the day, on Ethereum, smart contracts only ever see/interact with ZBTC. It’s RenVM that takes care of all the other messy non-ERC20 details.
Another way to think about it: RenVM has its own “WBTC” (called ZBTC), anyone can mint/burn it (unlike WBTC), and there’s no central custodian (unlike WBTC). It just happens to have some nice hooks so that all the minting/burning/interacting-with-DEX/DeFi can all be done in one go. I hope that helps!
https://docs.renproject.io/darknodes/community/monthly-community-faq
submitted by RENProtocol to RenProject [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]

Simplified explanation for setting up a UASF Full Node on your Raspberry Pi 3.

I decided to undertake an effort to run a full node on my Raspberry Pi. I followed this tutorial, but still found it was too detailed/complicated, so I reduced it down to the basic steps needed to make it happen.
This tutorial will install the UASF binaries to enforce BIP148 on August 1st. Don't be fooled thinking that the recent Barry Silbert agreement has resolved the ongoing scaling issue. Activating Segwit is necessary and UASF is the way to make that happen. Your support is needed.
This tutorial assumes that you are running Raspian, your RaspPi has internet connectivity, you have an external USB hard drive connected formatted as FAT32 and your Linux username is "pi".
IMPORTANT: For your security, you should change your username to something different than "pi" (also choose a strong password. As you will see below, you should enable UPnP or port forward 8333 on your router to your Raspberry Pi, but this creates a security risk.
These instructions will install Bitcoin Core without wallet functionality.
Create a directory that will act as a mount point for the USB drive:
[email protected]~$ mkdir ~/bitcoinData 
With your USB drive connected, run this command to confirm that your drive is recognized as /dev/sd1:
[email protected]~$ sudo blkid 
In order to tell your Raspberry Pi to mount your USB drive automatically so that anything we put in the bitcoinData directory will be going onto the USB drive we need to edit the /etc/fstab file:
[email protected]~$ sudo nano /etc/fstab 
Add the following line to the fstab file. The following assumes that the drive was /dev/sd1:
/dev/sda1 /home/pi/bitcoinData vfat uid=pi,gid=pi,umask=0022,sync,auto,nosuid,rw,nouser 0 0 
Save the fstab file and reboot. When re-started, navigate with the File Manager to /home/pi/bitcoinData and make sure the folder size corresponds to the approximate size of your external drive. This is important, otherwise, the blockchain will be saved to the micro SD card. Unless your card is 256GB, it won't fit.
Enlarge the swap file, by editing the dphys-swapfile:
[email protected]~/bin/bitcoin$ sudo nano /etc/dphys-swapfile 
Change "CONF_SWAPSIZE=100" to "CONF_SWAPSIZE=1000". Save the file, then exit. Now run:
[email protected]~$ sudo dphys-swapfile setup [email protected]~$ sudo dphys-swapfile swapon 
Update your Raspbian:
[email protected]~$ sudo apt-get update [email protected]~$ sudo apt-get upgrade -y 
Install some packages:
[email protected]~$ sudo apt-get install autoconf libevent-dev libtool libssl-dev libboost-all-dev libminiupnpc-dev -y [email protected]~$ sudo apt-get install qt4-dev-tools libprotobuf-dev protobuf-compiler libqrencode-dev -y 
Make a directory and change to that directory:
[email protected]~$ mkdir ~/bin [email protected]~$ cd ~/bin 
Install Bitcoin:
[email protected]~/bin$ git clone https://github.com/UASF/bitcoin.git -b 0.14-BIP148 [email protected]~/bin$ cd bitcoin/ [email protected]~/bin/bitcoin$ ./autogen.sh [email protected]~/bin/bitcoin$ ./configure --enable-upnp-default --disable-wallet [email protected]~/bin/bitcoin$ make -j2 
It will take about 2 hours for the "make -j2" to finish. Once done, run:
[email protected]~/bin/bitcoin$ sudo make install 
Now, create a bitcoin.conf file:
[email protected]~/bin/bitcoin$ cd ~/bitcoinData [email protected]~/bitcoinData$ nano bitcoin.conf 
Let's run this bad boy:
[email protected]~$ bitcoin-qt 
On the first start, choose the blockchain data directory as "/home/pi/bitcoinData". Expect that it will take 2 to 3 weeks to fully sync the blockchain.
The step that includes "enable-upnp-default" is intended to open the necessary port (8333) in your router. Either way, you may want to consider port-forwarding port 8333 to your Pi.
You should now go to https://bitnodes.21.co/ and click the ‘CHECK NODE’ button to see how your node appears to other nodes on the network. This is important as it lets your node contribute to the network and adds to the UASF support on node statistics.
Enjoy!
submitted by iftodaywasurlastday to Bitcoin [link] [comments]

Simplified explanation for setting up a Bitcoin 0.15 Full Node on your Raspberry Pi 3.

I decided to undertake an effort to run a full node on my Raspberry Pi. I followed this tutorial, but still found it was too detailed/complicated, so I reduced it down to the basic steps needed to make it happen.
This tutorial assumes that you are running Raspian, your RaspPi has internet connectivity, you have an external USB hard drive connected formatted as FAT32 and your Linux username is "pi".
IMPORTANT: For your security, you should change your username to something different than "pi" (also choose a strong password. As you will see below, you should enable UPnP or port forward 8333 on your router to your Raspberry Pi, but this creates a security risk.
These instructions will install Bitcoin Core without wallet functionality.
Create a directory that will act as a mount point for the USB drive:
[email protected]~$ mkdir ~/bitcoinData 
With your USB drive connected, run this command to confirm that your drive is recognized as /dev/sd1:
[email protected]~$ sudo blkid 
In order to tell your Raspberry Pi to mount your USB drive automatically so that anything we put in the bitcoinData directory will be going onto the USB drive we need to edit the /etc/fstab file:
[email protected]~$ sudo nano /etc/fstab 
Add the following line to the fstab file. The following assumes that the drive was /dev/sd1:
/dev/sda1 /home/pi/bitcoinData vfat uid=pi,gid=pi,umask=0022,sync,auto,nosuid,rw,nouser 0 0 
Save the fstab file and reboot.
When re-started, navigate with the File Manager to /home/pi/bitcoinData and make sure the folder size corresponds to the approximate size of your external drive. This is important, otherwise, the blockchain will be saved to the micro SD card. Unless your card is 256GB, it won't fit.
Enlarge the swap file, by editing the dphys-swapfile:
[email protected]~/bin/bitcoin$ sudo nano /etc/dphys-swapfile 
Change "CONF_SWAPSIZE=100" to "CONF_SWAPSIZE=1000". Save the file, then exit. Now run:
[email protected]~$ sudo dphys-swapfile setup [email protected]~$ sudo dphys-swapfile swapon 
Update your Raspbian:
[email protected]~$ sudo apt-get update [email protected]~$ sudo apt-get upgrade -y 
Install some packages:
[email protected]~$ sudo apt-get install autoconf libevent-dev libtool libssl-dev libboost-all-dev libminiupnpc-dev -y [email protected]~$ sudo apt-get install qt4-dev-tools libprotobuf-dev protobuf-compiler libqrencode-dev -y 
Make a directory and change to that directory:
[email protected]~$ mkdir ~/bin [email protected]~$ cd ~/bin 
Install Bitcoin:
[email protected]~/bin$ git clone https://github.com/bitcoin/bitcoin bitcoin [email protected]~/bin$ cd bitcoin/ [email protected]~/bin/bitcoin$ ./autogen.sh [email protected]~/bin/bitcoin$ ./configure --enable-upnp-default --disable-wallet [email protected]~/bin/bitcoin$ make -j2 
It will take about 2 hours for the "make -j2" to finish. Once done, run:
[email protected]~/bin/bitcoin$ sudo make install 
Now, create a bitcoin.conf file:
[email protected]~/bin/bitcoin$ cd ~/bitcoinData [email protected]~/bitcoinData$ nano bitcoin.conf 
Let's run this bad boy:
[email protected]~$ bitcoin-qt 
On the first start, choose the blockchain data directory as "/home/pi/bitcoinData". Expect that it will take 2 to 3 weeks to fully sync the blockchain.
The step that includes "enable-upnp-default" is intended to open the necessary port (8333) in your router. Either way, you may want to consider port-forwarding port 8333 to your Pi.
You should now go to https://bitnodes.21.co/ and click the ‘CHECK NODE’ button to see how your node appears to other nodes on the network. This is important as it lets your node contribute to the network and adds to the UASF support on node statistics.
Enjoy!
submitted by iftodaywasurlastday to Bitcoin [link] [comments]

Simplified explanation for setting up a UASF Full Node on your Raspberry Pi 3.

I decided to undertake an effort to run a full node on my Raspberry Pi. I followed this tutorial, but still found it was too detailed/complicated, so I reduced it down to the basic steps needed to make it happen.
This tutorial will install the UASF 1.0 binaries to enforce BIP148 on August 1st.
This tutorial assumes that you are running Raspian, your RaspPi has internet connectivity, you have an external USB hard drive connected formatted as FAT32 and your Linux username is "pi".
IMPORTANT: For your security, you should change your username to something different than "pi" (also choose a strong password. As you will see below, you should enable UPnP or port forward 8333 on your router to your Raspberry Pi, but this creates a security risk.
These instructions will install Bitcoin Core without wallet functionality.
Create a directory that will act as a mount point for the USB drive:
[email protected]~$ mkdir ~/bitcoinData 
With your USB drive connected, run this command to confirm that your drive is recognized as /dev/sd1:
[email protected]~$ sudo blkid 
In order to tell your Raspberry Pi to mount your USB drive automatically so that anything we put in the bitcoinData directory will be going onto the USB drive we need to edit the /etc/fstab file:
[email protected]~$ sudo nano /etc/fstab 
Add the following line to the fstab file. The following assumes that the drive was /dev/sd1: /dev/sda1 /home/pi/bitcoinData vfat uid=pi,gid=pi,umask=0022,sync,auto,nosuid,rw,nouser 0 0 Save the fstab file and reboot.
When re-started, navigate with the File Manager to /home/pi/bitcoinData and make sure the folder size corresponds to the approximate size of your external drive. This is important, otherwise, the blockchain will be saved to the micro SD card. Unless your card is 256GB, it won't fit.
Enlarge the swap file, by editing the dphys-swapfile:
[email protected]~/bin/bitcoin$ sudo nano /etc/dphys-swapfile 
Change "CONF_SWAPSIZE=100" to "CONF_SWAPSIZE=1000". Save the file, then exit. Now run:
[email protected]~$ sudo dphys-swapfile setup [email protected]~$ sudo dphys-swapfile swapon 
Update your Raspbian:
[email protected]~$ sudo apt-get update [email protected]~$ sudo apt-get upgrade -y 
Install some packages:
[email protected]~$ sudo apt-get install autoconf libevent-dev libtool libssl-dev libboost-all-dev libminiupnpc-dev -y [email protected]~$ sudo apt-get install qt4-dev-tools libprotobuf-dev protobuf-compiler libqrencode-dev -y 
Make a directory and change to that directory:
[email protected]~$ mkdir ~/bin [email protected]~$ cd ~/bin 
Install Bitcoin:
[email protected]~/bin$ git clone https://github.com/UASF/bitcoin.git bitcoin [email protected]~/bin$ cd bitcoin/ [email protected]~/bin/bitcoin$ ./autogen.sh [email protected]~/bin/bitcoin$ ./configure --enable-upnp-default --disable-wallet [email protected]~/bin/bitcoin$ make -j2 
It will take about 2 hours for the "make -j2" to finish. Once done, run:
[email protected]~/bin/bitcoin$ sudo make install 
Now, create a bitcoin.conf file:
[email protected]~/bin/bitcoin$ cd ~/bitcoinData [email protected]~/bitcoinData$ nano bitcoin.conf 
Let's run this bad boy:
[email protected]~$ bitcoin-qt 
On the first start, choose the blockchain data directory as "/home/pi/bitcoinData". Expect that it will take 2 to 3 weeks to fully sync the blockchain.
The step that includes "enable-upnp-default" is intended to open the necessary port (8333) in your router. Either way, you may want to consider port-forwarding port 8333 to your Pi.
You should now go to https://bitnodes.21.co/ and click the ‘CHECK NODE’ button to see how your node appears to other nodes on the network. This is important as it lets your node contribute to the network and adds to the UASF support on node statistics.
Enjoy!
submitted by iftodaywasurlastday to Bitcoin [link] [comments]

Bitcoin Core 0.14.2 released | Wladimir J. van der Laan | Jun 17 2017

Wladimir J. van der Laan on Jun 17 2017:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.14.2 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.14.2/
Or by torrent:
magnet:?xt=urn:btih:b4fc7820df95b8b39603ad246c241272ec403619&dn;=bitcoin-core-0.14.2&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on April 8th, 2014,
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes

miniupnp CVE-2017-8798
Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error
(present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers
(within the LAN) to cause a denial of service or possibly have unspecified
other impact.
This only affects users that have explicitly enabled UPnP through the GUI
setting or through the -upnp option, as since the last UPnP vulnerability
(in Bitcoin Core 0.10.3) it has been disabled by default.
If you use this option, it is recommended to upgrade to this version as soon as
possible.
Known Bugs

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin
control and smart fee estimation does not reflect any change in target from the
smart fee slider. It will only present an approximate fee calculated using the
default target. The fee calculated using the correct target is still applied to
the transaction and shown in the final send confirmation dialog.
0.14.2 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

P2P protocol and network code

Build system

Miscellaneous

GUI

Wallet

Credits

Thanks to everyone who directly contributed to this release:
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCgAGBQJZRRTMAAoJEB5K7WKYbNJdqk0IANF5Q49ID3B77b0CwSKzjTxk
Ktp0qgvtig0ZMnzVlgjULUsRW8EbecWCQwmgRo8uUoCGmNS2u7u+s28kIIkicELE
BpWcW4eC6NdCCjB1CSnmX/tno4gFwOZutVj/XUXJCBEuBbo6fIK0cVDas5vw8UVa
gXL5ytwXeCws3z9f3iiD1Nl0k+J+dRb0sJ2u0A1+XqoMFfInMUFiP/fa9XWaimKo
62jD07IJDKtH4PEKG8v+FLZounRP7t1lhU0AiQ0Uj67mBmllwWD0KeZi0f4SokMX
aezEH+2UIW3Ph/QbG+ktZYUzbDALnRIHEBP4GQUuWiUPZKo3vAS3yhvh1nvYUW4=
=VBdE
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014597.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Unplug UPnP - Security Now 389 - YouTube Security Now - YouTube Here Comes 2019! - Security Now 696 Security Now 315: Off The Grid Security Now 456: Harvesting Entropy

Notable changes Fix buffer overflow in bundled upnp. Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in the XML parser during initial network discovery. Security is a much bigger thing now than it was in 2011 (that's about the time when the first iPad was released), so vendors are more aware of security issues. For older routers, if they were vulnerable in the first place, a firmware update has probably been released long ago. Millions of routers throughout the world have the Universal Plug and Play (UPnP) networking protocol enabled on internet-facing ports, which exposes them to external attack. This week's Security Now! podcast is titled "Windows 7 - R.I.P.," not because there's much that we haven't already said about the fact, but that it happens TODAY; and that, given the still massive install base of Windows 7, it's significant that all of those machines will now be going without any clearly needed security updates. Security Now 395 March 13, 2013 Leo Laporte, Steve Gibson Q&A #163; Security Now 389 January 30, 2013 Leo Laporte, Steve Gibson Q&A #159 & UPnP Exposure Disaster; Security Now 388 January 23, 2013 Leo Laporte, Steve Gibson Memory Hard Problems; Security Now 387 January 16, 2013 Leo Laporte, Steve Gibson Q&A #159; Security Now 386 January 9, 2013

[index] [31554] [9171] [22667] [28246] [31208] [28878] [19392] [16512] [16570] [2820]

Unplug UPnP - Security Now 389 - YouTube

Hosts:Steve Gibson with Leo Laporte Caesar Cipher, Playfair Cipher, going off the grid and more. Download or subscribe to this show at twit.tv/sn. We invite you to read, add to, and amend our show ... The Top Security Stories of 2019 (So Far) -- The NSA announces the forthcoming release of an internal powerful reverse-engineering tool for examining and understanding other people's code ... Unplug UPnP - Security Now 389 - Duration: 1:34:49. Security Now 41,786 views. 1:34:49 "IT'S A COUP" KEN STARR DISMANTLES ADAM SCHIFF AND ENTIRE DEMOCRATS - Duration: 12:16. Hosts:Steve Gibson with Tom Merritt A critical Microsoft vulnerability, The differences between open and closed source software, A number of questions around BitCoin, and more. Download or ... You can submit a question to Security Now! at the GRC Feedback Page. ... Unplug UPnP - Security Now 389 - Duration: ... The Story of Bitcoin - Duration: 57:35. Security Now 4,066 views. 57:35.

#