bitcoin-testnet-box/Dockerfile at master · freewil/bitcoin ...

[Request Tutorial] Testnet Lightning Network node on my PC without the use of a Cloud service, Docker, etc. /r/Bitcoin

[Request Tutorial] Testnet Lightning Network node on my PC without the use of a Cloud service, Docker, etc. /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Docker container with bitcoin testnet network with pregenerated coins for testing and apps development

Docker container with bitcoin testnet network with pregenerated coins for testing and apps development submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Ethereum 2.0-proof-of-stake testnet is live

Ethereum 2.0-proof-of-stake testnet is live submitted by juxtaposezen to ethtrader [link] [comments]

Docker-compose bitcoind looses 8% of progress on a restart.

Howdy folks,
So I'm prototyping a new lightning centric social media concept. For dev work I'm leveraging docker-compose to handle the stack infrastructure, but whenever I kill or restart the bitcoin (testnet) node it looses 8% of progress and has to resync.
It's not a huge pain/will go away in the production environment, but I thought I'd ask if anybody has seen similar / knows how to get bitcoind to (more) gracefully exit.
submitted by DJBunnies to Bitcoin [link] [comments]

Having Trouble with Regtest Running Inside a Docker Container

Hello everyone. First of all, thanks in advance for any help.
I'm running a BTCPay server using BTCPay server docker. If I understand it correctly, it exposes the regtest Bitcoin core through a Tor network.
I followed the instructions on the [BTCPay Server docs to Connect Wasabi to BTCPay Server Full Node. Unfortunately, after following these instructions, the bottom-left corner of Wasabi Wallet still reads "Connecting...".
My logs.txt reveals:
2020-03-29 20:34:51 INFO Program (44) Wasabi GUI started (14879af3-85dd-42aa-9d41-674d87a5dd77). 2020-03-29 20:34:52 INFO Global (164) Config is successfully initialized. 2020-03-29 20:34:52 INFO TransactionStore (28) ConfirmedStore.InitializeAsync finished in 4 milliseconds. 2020-03-29 20:34:52 INFO TransactionStore (28) MempoolStore.InitializeAsync finished in 12 milliseconds. 2020-03-29 20:34:52 INFO Global (401) Fake AddressManager is initialized on the RegTest. 2020-03-29 20:34:52 INFO AllTransactionStore (27) InitializeAsync finished in 16 milliseconds. 2020-03-29 20:34:52 INFO IndexStore (43) InitializeAsync finished in 40 milliseconds. 2020-03-29 20:34:52 INFO BitcoinStore (39) InitializeAsync finished in 43 milliseconds. 2020-03-29 20:34:52 INFO TorProcessManager (249) Starting Tor monitor... 2020-03-29 20:34:52 INFO Global (230) TorProcessManager is initialized. 2020-03-29 20:34:52 INFO HostedServices (49) Started Software Update Checker. 2020-03-29 20:34:52 INFO TorProcessManager (66) Tor is already running. 2020-03-29 20:34:53 ERROR Global (328) System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (61): Connection refused [::ffff:127.0.0.1]:18444 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(Exception source) at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult) at NBitcoin.Protocol.Connectors.SocketExtensions.<>c.b__0_0(IAsyncResult iar) --- End of stack trace from previous location where exception was thrown --- at NBitcoin.Extensions.WithCancellation[T](Task`1 task, CancellationToken cancellationToken) at NBitcoin.Protocol.Connectors.DefaultEndpointConnector.ConnectSocket(Socket socket, EndPoint endpoint, NodeConnectionParameters nodeConnectionParameters, CancellationToken cancellationToken) at NBitcoin.Protocol.Node.ConnectAsync(Network network, EndPoint endpoint, NetworkAddress peer, NodeConnectionParameters parameters) at WalletWasabi.Gui.Global.InitializeNoWalletAsync() 2020-03-29 20:34:53 INFO Global (349) Start connecting to nodes... 2020-03-29 20:34:53 INFO Global (373) Start synchronizing filters... 2020-03-29 20:34:53 INFO MainWindow.xaml (74) UiConfig is successfully initialized. 2020-03-29 20:34:57 ERROR PeriodicRunner (72) System.NotSupportedException: Invalid StatusLine: ?. - System.IndexOutOfRangeException: Index was outside the bounds of the array. at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) --- End of inner exception stack trace --- at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) at System.Net.Http.HttpResponseMessageExtensions.CreateNewAsync(Stream responseStream, HttpMethod requestMethod) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpRequestMessage request, CancellationToken cancel) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpMethod method, String relativeUri, HttpContent content, CancellationToken cancel) at TorHttpClientExtensions.SendAndRetryAsync(ITorHttpClient client, HttpMethod method, HttpStatusCode expectedCode, String relativeUri, Int32 retry, HttpContent content, CancellationToken cancel) at WalletWasabi.WebClients.Wasabi.WasabiClient.GetVersionsAsync(CancellationToken cancel) at WalletWasabi.WebClients.Wasabi.WasabiClient.CheckUpdatesAsync(CancellationToken cancel) at WalletWasabi.Services.UpdateChecker.ActionAsync(CancellationToken cancel) at WalletWasabi.Bases.PeriodicRunner.ExecuteAsync(CancellationToken stoppingToken) 2020-03-29 20:35:01 ERROR WasabiSynchronizer (305) System.NotSupportedException: Invalid StatusLine: ?. - System.IndexOutOfRangeException: Index was outside the bounds of the array. at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) --- End of inner exception stack trace --- at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) at System.Net.Http.HttpResponseMessageExtensions.CreateNewAsync(Stream responseStream, HttpMethod requestMethod) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpRequestMessage request, CancellationToken cancel) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpMethod method, String relativeUri, HttpContent content, CancellationToken cancel) at TorHttpClientExtensions.SendAndRetryAsync(ITorHttpClient client, HttpMethod method, HttpStatusCode expectedCode, String relativeUri, Int32 retry, HttpContent content, CancellationToken cancel) at WalletWasabi.WebClients.Wasabi.WasabiClient.GetSynchronizeAsync(uint256 bestKnownBlockHash, Int32 count, Nullable`1 estimateMode, CancellationToken cancel) at System.Threading.Tasks.TaskExtensions.WithAwaitCancellationAsync[T](Task`1 me, CancellationToken cancel, Int32 waitForGracefulTerminationMilliseconds) at WalletWasabi.Services.WasabiSynchronizer.<>c__DisplayClass60_0.<b__0>d.MoveNext()
while my config.json is:
json { "Network": "RegTest", "MainNetBackendUriV3": "http://wasabiukrxmkdgve5kynjztuovbg43uxcbcxn6y2okcrsg7gb6jdmbad.onion/", "TestNetBackendUriV3": "http://testwnp3fugjln6vh5vpj7mvq3lkqqwjj3c2aafyu7laxz42kgwh2rad.onion/", "MainNetFallbackBackendUri": "https://wasabiwallet.io/", "TestNetFallbackBackendUri": "https://wasabiwallet.co/", "RegTestBackendUriV3": "http://oqaqivyaxctrp2gix5id4bbd7mav2xt5n4fzqsnwtrhtsmgjhg7sneqd.onion:8333/", "UseTor": true, "StartLocalBitcoinCoreOnStartup": false, "StopLocalBitcoinCoreOnShutdown": true, "LocalBitcoinCoreDataDir": "/Users/my-name-here/Library/Application Support/Bitcoin", "TorSocks5EndPoint": "127.0.0.1:9050", "MainNetBitcoinP2pEndPoint": "127.0.0.1:8333", "TestNetBitcoinP2pEndPoint": "127.0.0.1:18333", "RegTestBitcoinP2pEndPoint": "127.0.0.1:8333", "MixUntilAnonymitySet": 50, "PrivacyLevelSome": 2, "PrivacyLevelFine": 21, "PrivacyLevelStrong": 50, "DustThreshold": "0.00005" }
The environment in which bitcoind runs is here: https://gist.github.com/AryanJ-NYC/78c770f3e918d06e62301f1ebc6fba31 (I would copy and paste but quite long).
I'm 98% sure the error lies in this line of the log: 2020-03-29 20:34:53 ERROR Global (328) System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (61): Connection refused [::ffff:127.0.0.1]:18444. However, I haven't a clue what port regtest normally runs on.
FWIW, main and testnet connect just fine (both nodes also running on my local machine).
submitted by TheWebDevCoach to WasabiWallet [link] [comments]

Groestlcoin 6th Anniversary Release

Introduction

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

UPDATED - Groestlcoin Core 2.18.2

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

How to Upgrade?

Windows
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

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

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

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

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

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

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

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

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

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

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

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

Features

Download

Source

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

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

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

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

Features

Download

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

Source

ALL NEW! – Electrum Personal Server

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

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

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

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

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

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

I'm trying to put together a list of what's coming out this year. Have this very simple list so far. Anyone care to add anything or suggest some better dates?

Latest News (most recent first) - Instant channels enable safe Lightning payments with unconfirmed funding Beta - Feb 10, 2019 - Voyager, New trading app from Uber & E-Trade execs announce launch date - Feb 9, 2019 - bumi/blockstream_satellite ruby gem for the Blockstream Satellite API - Feb 8, 2019 - New Zap Desktop 0.3.4 is out. New features, massive performance - Feb 8, 2019 - New release: @lightning desktop app v0.4.0-alpha - Feb 8, 2019 - valerio-vaccaro/Liquid-dashboard - Feb 7, 2019 - Japanese SBI Holdings will allow trading of coins - March 2019 - lnd v0.5.2-beta released - Feb 6, 2019 - Koala studios launches online LN gaming platform - Feb 6, 2019 - Independent Reserve has become the first #crypto exchange in Australia to be insured, with coverage underwritten by Lloyd's of London. - Feb 6, 2019 - Coinbase announces BTC support for their mobile (keep your own keys) wallet - Feb 6, 2019 - Blockstream published a new open source Proof of Reserves tool. - Feb 5, 2019 - RTL release v0.1.14-alpha - Feb 5, 2019 - dr-orlovsky/typhon-spec spec for new trestles side chain published - Feb 5, 2019 - Payment requests coming soon to BTCPay. - Feb 5th, 2019 - Kraken Acquires Futures Startup In Deal Worth At Least $100 Million - Feb 5th, 2019 - Next Blockchain cruise scheduled for June 9-13 - Feb 4, 2019 - Work on a GoTenna plugin to Electrum wallet in progress - Feb 4, 2019 - Bitcoin Candy Dispensers being open sourced - Feb 4, 2019 - New release of JoinMarket v0.5.3 - Feb 4, 2019 - Prime Trust won’t charge its clients to custody digital assets any longer. - Feb 4, 2019 - nodogsplash/nodogsplash wifi access using LN - Feb 3, 2019 - @tippin_me Receive tips using Lightning Network adds message feature - Feb 3, 2019 - Bitcoin-for-Taxes Bill in NH Unanimously Approved by House Subcommittee - Feb 3, 2019 - Full support for native segwit merged into bitcoinj - Feb 3, 2019 - Bitfury is partnering with financial services firm Final Frontier! - Feb 2, 2019 - Now you can open #LightningNetwork channels in @LightningJoule - Feb 2, 2019 - Integrating Blockstream’s Liquid payments on SideShift AI - Feb 1, 2019 - Wyoming legislature passes bill to recognize cryptocurrency as money - Feb 1, 2019 - Casa is open sourcing the code for the Casa Node - Feb 1, 2019 - Casa Browser Extension released - v0.5.2-beta-rc6 of lnd, full release getting very close now - Feb 1, 2019 - Tallycoin adds subscriptions and paywall features in bid to rival Patreon - Jan 31, 2019 - Static channel backup PR merged into LN - Jan 31, 2019 - The NYDFS grants another Bitlicense to ATM operator - Jan 31, 2019 - @pwuille currently proposing the “MiniScript” language to describe BTC output locking conditions for practical composition - Jan 31, 2019 - Fidelity is in the “final testing” phase for its new digital asset business - Jan 31, 2019 - Hardware wallet PR #109 just got merged so that @Trezor no longer requires user interaction for PIN - Jan 31, 2019 - CBOE, VanEck & SolidX filed a new & improved bitcoin ETF proposal. - Jan 31, 2019 - Casa Node code is now open sourced - Jan 31, 2019 - Next Bitoin halving in roughly 497 days - Jan 31, 2019 - BTCPay released 1.0.3.53 - Jan 31, 2019 - @binance now lets users purchase cryptos using Visa and Mastercard credit. - Jan 31, 2019 - Bitfury to Launch Bitcoin Operations in Paraguay - Jan 31, 2019 - Coinbase introduces very generous affiliate program - Jan 30, 2019 - DOJO Trusted Node bitcoin full node. Coming Early 2019 - Jan 30, 2019 - FastBitcoins.com Enables Cash-for-Bitcoin Exchange Via the Lightning Network - Jan 30, 2019 - TD Ameritrade says clients want cryptocurrency investment options - company plans major announcement in 'first half of 2019' - Jan 30, 2019 - Storage component of Fidelity's @DigitalAssets live, with some assets under management, @nikhileshde - Jan 29, 2019 - lightning mainnet has reached 600 BTC capacity - Jan 29, 2019 - Drivechain shows picture of Grin side chain and suggests might be ready in 2 month - Jan 29, 2019 - Lightning labs iOS neutrino wallet in testing stage now - Jan 29, 2019 - Aliant offering cryptocurrency processing free-of-charge - Jan 29, 2019 - Chainstone’s Regulator product to manage assets on the way - Jan 29, 2019 - Fidelity Investments’ new crypto custody service may officially launch in March. - Jan 29, 2019 - Gemini's becomes FIRST crypto EXCHANGE and CUSTODIAN to complete a SOC 2 Review by Deloitte - Jan 29, 2019 - Iran has lifted the ban on Bitcoin and cryptocurrency - Jan 29, 2019 - Confidential Transactions being added into Litecoin announcement - Jan 28, 2019 - http://FastBitcoins.com Enables Cash-for-Bitcoin Exchange Via the Lightning Network - Jan 28, 2019 - Germany’s largest online food delivery platform now accepts btc - Jan 27, 2019 - Launching a Bitcoin Developers School in Switzerland - Jan 27, 2019 - RTL release v0.1.13-alpha Lightning Build repository released - Jan 27, 2019 - The first pay-per-page fantasy novel available to Lightning Network. - Jan 27, 2019 - Numerous tools become available to write messages transmitted with Blockstream Satellite - Jan 26, 2019; - BTCPay 1.0.3.47 released - Jan 26,2019 - WordPress + WooCommerce + BTCPay Plugin is now live - Jan 25, 2019 - Juan Guaido has been promoting #Bitcoin since 2014 is new interim president of Venezuela - Jan 25, 2019 - Morgan Creek funds @RealBlocks - Jan 25, 2019 - Coinbase integrates TurboTax - Jan 25, 2019 - Robinhood received Bitlicense - Jan 25, 2019 - Anchor Labs launches custody - Jan 25, 2019 - NYSE Arca files w/ @BitwiseInvest for BTC ETF approval - Jan 25, 2019 - South Korea, Seoul, Busan & Jeju Island currently working to create pro crypto economic zones. - Jan 25, 2019 - valerio-vaccaro/Liquid-dashboard - Jan 25, 2019 - Bermuda to launch crypto friendly bank - Jan 25, 2019 - Mobile Bitcoin Wallet BRD Raises $15 Million, Plans for Expansion in Asia - Jan 25, 2019 - BullBitcoin rolling out alpha access of platform - Jan 25, 2019 - Electrum Wallet Release 3.3.3 - Jan 25, 2019 - Bitrefill, purchase Bitcoin and have it delivered directly over LN - Jan 25, 2019 - South Korean crypto exchange Bithumb looking to go public in USA - Jan 24, 2019 - Bitcoin Exchanges Don’t Need Money Transmitter Licenses in Pennsylvania - Jan 24, 2019 - US; New Hampshire Bill Aims to Legalize Bitcoin for State Payments in 2020 - Jan 24, 2019 - Robinhood, LibertyX Receive Licenses from New York Regulators - Jan 24, 2019 - Bakkt Bitcoin futures contract details released - Jan 24, 2019 - Blockstream CryptoFeed V3 now includes 30+ venues and 200M+ updates per day - Jan 24, 2019 - Binance Jersey – The Latest Binance European Exchange - Jan 2019
Commit Activity
Nodes and Market Dominance
Bitcoin
Financial
Lightning:
ASIC Miners:
Will update this section when I hear new developments
Wallets:
Hardware wallets:
LN
LN Apps:
LN Extensions / Launchers
LN Desktop wallets:
LN Mobile wallets:
LN Network:
LN Nodes:
LN Plugins:
LN Services:
Liquid Network
Rgulatory:
Exchanges:
Payments:
Please comment if you have any ideas on dates. Many of these dates are placeholders waiting for me to update. If you comment then I will update the post.
submitted by kolinHall to Bitcoin [link] [comments]

Function X: A Concept Paper introducing the f(x) ecosystem, a universal decentralized internet powered by blockchain technology and smart devices

Function X: A Concept Paper introducing the f(x) ecosystem, a universal decentralized internet powered by blockchain technology and smart devices

https://preview.redd.it/yylq6k0yqrv21.png?width=633&format=png&auto=webp&s=089ffe83e18baeceb87d465ca6fad184939490e4

Prologue

This is a Concept Paper written to introduce the Function X Ecosystem, which includes the XPhone. It also addresses the relationship between the XPOS and Function X.
Pundi X has always been a community-driven project. We have lived by the mission of making sure the community comes first and we are constantly learning from discussions and interactions on social media and in real-life meetings.
As with all discussions, there is always background noise but we have found gems in these community discussions. One such example is a question which we found constantly lingering at the back of our mind, “Has blockchain changed the world as the Internet did in the ’90s, and the automobile in the ‘20s?”. Many might argue that it has, given the rise of so many blockchain projects with vast potential in different dimensions (like ours, if we may add). But the question remains, “can blockchain ever become what the Internet, as we know it today, has to the world?”
Function X, a universal decentralized internet which is powered by blockchain technology and smart devices.
Over the past few months, in the process of implementing and deploying the XPOS solution, we believe we found the answer to the question. A nimble development team was set up to bring the answer to life. We discovered that it is indeed possible to bring blockchain to the world of telephony, data transmission, storage and other industries; a world far beyond financial transactions and transfers.
This is supported by end-user smart devices functioning as blockchain nodes. These devices include the XPOS and XPhone developed by Pundi X and will also include many other hardware devices manufactured by other original equipment manufacturers.
The vision we want to achieve for f(x) is to create a fully autonomous and decentralized network that does not rely on any individual, organization or structure.
Due to the nature of the many new concepts introduced within this Concept Paper, we have included a Q&A after each segment to facilitate your understanding. We will continuously update this paper to reflect the progress we’re making.

Function X: The Internet was just the beginning

The advent of the Internet has revolutionized the world. It created a communications layer so robust that it has resulted in TCP/IP becoming the network standard.
The Internet also created a wealth of information so disruptive that a company like Amazon threatened to wipe out all the traditional brick-and-mortar bookstores. These bookstores were forced to either adapt or perish. The same applies to the news publishing sector: the offerings of Google and Facebook have caused the near extinction of traditional newspapers.
The digitalization of the world with the Internet has enabled tech behemoths like Apple, Amazon, Google and Facebook to dominate and rule over traditional companies. The grip of these tech giants is so extensive that it makes you wonder if the choices you make are truly your own or influenced by the data they have on you as a user.
We see the blockchain revolution happening in three phases. The first was how Bitcoin showed the world what digital currency is. The second refers to how Ethereum has provided a platform to build decentralized assets easily. The clearest use case of that has come in the form of the thousands of altcoins seen today that we all are familiar with. The third phase is what many blockchain companies are trying to do now: 1) to bring the performance of blockchain to a whole new level (transaction speed, throughput, sharding, etc.) and 2) to change the course of traditional industries and platforms—including the Internet and user dynamics.
Public blockchains allow trustless transactions. If everything can be transacted on the blockchain in a decentralized manner, the information will flow more efficiently than traditional offerings, without the interception of intermediators. It will level the playing field and prevent data monopolization thus allowing small innovators to develop and flourish by leveraging the resources and data shared on the blockchain.

The Blockchain revolution will be the biggest digital revolution

In order to displace an incumbent technology with something new, we believe the change and improvement which the new technology has to bring will have to be at least a tenfold improvement on all aspects including speed, transparency, scalability and governance (consensus). We are excited to say that the time for this 10-times change is here. It’s time to take it up 10x with Function X.
Function X or f(x) is an ecosystem built entirely on and for the blockchain. Everything in f(x) (including the application source code, transmission protocol and hardware) is completely decentralized and secure. Every bit and byte in f(x) is part of the blockchain.
What we have developed is not just a public chain. It is a total decentralized solution. It consists of five core components: Function X Operating System (OS); Function X distributed ledger (Blockchain); Function X IPFS; FXTP Protocol and Function X Decentralized Docker. All five components serve a single purpose which is to decentralize all services, apps, websites, communications and, most importantly, data.
The purpose of Function X OS is to allow smart hardware and IoTs to harness the upside and potential utility of the decentralization approach. We have built an in-house solution for how mobile phones can leverage Function X OS in the form of the XPhone. Other companies can also employ the Function X OS and further customize it for their own smart devices. Every smart device in the Function X ecosystem can be a node and each will have its own address and private key, uniquely linked to their node names. The OS is based on the Android OS 9.0, therefore benefiting from backward compatibility with Android apps. The Function X OS supports Android apps and Google services (referred to as the traditional mode), as well as the newly developed decentralized services (referred to as the blockchain mode). Other XPhone features powered by the Function X OS will be elaborated on in the following sections.
Using the Function X Ecosystem (namely Function X FXTP), the transmission of data runs on a complex exchange of public and private key data and encryption but never through a centralized intermediary. Hence it guarantees communication without interception and gives users direct access to the data shared by others. Any information that is sent or transacted over the Function X Blockchain will also be recorded on the chain and fully protected by encryption so the ownesender has control over data sharing. And that is how a decentralized system for communications works.
For developers and users transitioning to the Function X platform, it will be a relatively seamless process. We have intentionally designed the process of creating and publishing new decentralized applications (DApps) on Function X to be easy, such that the knowledge and experience from developing and using Android will be transferable. With that in mind, a single line of code in most traditional apps can be modified, and developers can have their transmission protocol moved from the traditional HTTP mode (centralized) to a decentralized mode, thus making the transmission “ownerless” because data can transmit through the network of nodes without being blocked by third parties. How services can be ported easily or built from scratch as DApps will also be explained in the following sections, employing technologies in the Function X ecosystem (namely Function X IPFS, FXTP Protocol and Decentralized Docker).

f(x) Chain

f(x) chain is a set of consensus algorithms in the form of a distributed ledger, as part of the Function X ecosystem. The blockchain is the building block of our distributed ledger that stores and verifies transactions including financials, payments, communications (phone calls, file transfers, storage), services (DApps) and more.
Will Function X launch a mainnet?
Yes. The f(x) chain is a blockchain hence there will be a mainnet.
When will the testnet be launched?
Q2 2019 (projected).
When will the mainnet be launched?
Q3 2019 (projected).
How is the Function X blockchain designed?
The f(x) chain is designed based on the philosophy that any blockchain should be able to address real-life market demand of a constantly growing peer-to-peer network. It is a blockchain with high throughput achieved with a combination of decentralized hardware support (XPOS, XPhone, etc.) and open-source software toolkit enhancements.
What are the physical devices that will be connected to the Function X blockchain?
In due course, the XPOS OS will be replaced by the f(x) OS. On the other hand, the XPhone was designed with full f(x) OS integration in mind, from the ground up. After the f(x) OS onboarding, and with adequate stability testings and improvements, XPOS and XPhone will then be connected to the f(x) Chain.
What are the different elements of a block?
Anything that is transmittable over the distributed network can be stored in the block, including but not limited to phone call records, websites, data packets, source code, etc. It is worth noting that throughout these processes, all data is encrypted and only the owner of the private key has the right to decide how the data should be shared, stored, decrypted or even destroyed.
Which consensus mechanism is used?
Practical Byzantine Fault Tolerance (PBFT).
What are the other implementations of Practical Byzantine Fault Tolerance (PBFT)?
Flight systems that require very low latency. For example, SpaceX’s flight system, Dragon, uses PBFT design philosophy. [Appendix]
How do you create a much faster public chain?
We believe in achieving higher speed, thus hardware and software configurations matter. If your hardware is limited in numbers or processing power, this will limit the transaction speed which may pose security risks. The Ethereum network consists of about 25,000 nodes spread across the globe now, just two years after it was launched. Meanwhile, the Bitcoin network currently has around 7,000 nodes verifying the network. As for Pundi X, with the deployment plan (by us and our partners) for XPOS, XPhone and potentially other smart devices, we anticipate that we will be able to surpass the number of Bitcoin and Ethereum nodes within 1 to 2 years. There are also plans for a very competitive software implementation of our public blockchain, the details for which we will be sharing in the near future.

f(x) OS

The f(x) OS is an Android-modified operating system that is also blockchain-compatible. You can switch seamlessly between the blockchain and the traditional mode. In the blockchain mode, every bit and byte is fully decentralized including your calls, messages, browsers and apps. When in traditional mode, the f(x) OS supports all Android features.
Android is the most open and advanced operating system for smart hardware with over 2 billion monthly active users. Using Android also fits into our philosophy of being an OS/software designer and letting third-party hardware makers produce the hardware for the Function X Ecosystem.
What kind of open source will it be?
This has not been finalized, but the options we are currently considering are Apache or GNU GPLv3.
What kind of hardware will it work on?
The f(x) OS works on ARM architecture, hence it works on most smartphones, tablet computers, smart TVs, Android Auto and smartwatches in the market.
Will you build a new browser?
We are currently using a modified version of the Google Chrome browser. The browser supports both HTTP and FXTP, which means that apart from distributed FXTP contents, users can view traditional contents, such ashttps://www.google.com.
What is the Node Name System (NNS)?
A NNS is a distributed version of the traditional Domain Name System. A NNS allows every piece of Function X hardware, including the XPhone, to have a unique identity. This identity will be the unique identifier and can be called anything with digits and numbers, such as ‘JohnDoe2018’ or ‘AliceBob’. More on NNS in the following sections.
Will a third-party device running the f(x) OS be automatically connected to the f(x) blockchain?
Yes, third-party devices will be connected to the f(x) blockchain automatically.

f(x) FXTP

A transmission protocol defines the rules to allow information to be sent via a network. On the Internet, HTTP is a transmission protocol that governs how information such as website contents can be sent, received and displayed. FXTP is a transmission protocol for the decentralized network.
FXTP is different from HTTP because it is an end-to-end transmission whereby your data can be sent, received and displayed based on a consensus mechanism rather than a client-server based decision-making mechanism. In HTTP, the server (which is controlled by an entity) decides how and if the data is sent (or even monitored), whereas in FXTP, the data is sent out and propagates to the destination based on consensus.
HTTP functions as a request–response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. FXTP functions as a propagation protocol via a consensus model. A node that propagates the protocol and its packet content is both a “client” and a “server”, hence whether a packet reaches a destination is not determined by any intermediate party and this makes it more secure.

f(x) IPFS

IPFS is a protocol and network designed to store data in a distributed system. A person who wants to retrieve a file will call an identifier (hash) of the file, IPFS then combs through the other nodes and supplies the person with the file.
The file is stored on the IPFS network. If you run your own node, your file would be stored only on your node and available for the world to download. If someone else downloads it and seeds it, then the file will be stored on both your node the node of the individual who downloaded it (similar to BitTorrent).
IPFS is decentralized and more secure, which allows faster file and data transfer.

f(x) DDocker

Docker is computer program designed to make it easier to create, deploy, and run applications. Containers allow a developer to package up an application including libraries, and ship it all out as a package.
As the name suggests, Decentralized Docker is an open platform for developers to build, ship and run distributed applications. Developers will be able to store, deploy and run their codes remote in different locations and the codes are secure in a decentralized way.

XPhone

Beyond crypto: First true blockchain phone that is secured and decentralized to the core
XPhone is the world’s first blockchain phone which is designed with innovative features that are not found on other smartphones.
Powered by Function X, an ecosystem built entirely on and for the blockchain, XPhone runs on a new transmission protocol for the blockchain age. The innovation significantly expands the use of blockchain technology beyond financial transfers.
Unlike traditional phones which require a centralized service provider, XPhone runs independently without the need for that. Users can route phone calls and messages via blockchain nodes without the need for phone numbers.
Once the XPhone is registered on the network, for e.g., by a user named Pitt, if someone wants to access Pitt’s publicly shared data or content, that user can just enter FXTP://xxx.Pitt. This is similar to what we do for the traditional https:// protocol.
Whether Pitt is sharing photos, data, files or a website, they can be accessed through this path. And if Pitt’s friends would like to contact him, they can call, text or email his XPhone simply by entering “call.pitt”, “message.pitt”, or “mail.pitt”.
The transmission of data runs on a complex exchange of public and private key data with encryption. It can guarantee communication without interception and gives users direct access to the data shared by others. Any information that is sent or transacted over the Function X Blockchain will also be recorded on the chain.
Toggle between now and the future
Blockchain-based calling and messaging can be toggled on and off on the phone operating system which is built on Android 9.0. XPhone users can enjoy all the blockchain has to offer, as well as the traditional functionalities of an Android smartphone.
We’ll be sharing more about the availability of the XPhone and further applications of Function X in the near future.

DApps

DApps for mass adoption
So far the use of decentralized applications has been disappointing. But what if there was a straightforward way to bring popular, existing apps into a decentralized environment, without rebuilding everything? Until now, much of what we call peer-to-peer or ‘decentralized’ services continue to be built on centralized networks. We set out to change that with Function X; to disperse content now stored in the hands of the few, and to evolve services currently controlled by central parties.
Use Cases: Sharing economy
As seen from our ride-hailing DApp example that was demonstrated in New York back in November 2018, moving towards true decentralization empowers the providers of services and not the intermediaries. In the same way, the XPhone returns power to users over how their data is being shared and with whom. Function X will empower content creators to determine how their work is being displayed and used.
Use Cases: Free naming
One of the earliest alternative cryptocurrencies, Namecoin, wanted to use a blockchain to provide a name registration system, where users can register their names to create a unique identity. It is similar to the DNS system mapping to IP addresses. With the Node Name System (NNS) it is now possible to do this on the blockchain.
NNS is a distributed version of the traditional Domain Name System. A NNS allows every piece of Function X hardware, including the XPhone, to have a unique identifier that can be named anything with digits and numbers, such as ‘JohnDoe2018’ or ‘AliceBob’.
Use Cases: Mobile data currency
According to a study, mobile operator data revenues are estimated at over $600 billion USD by 2020, equivalent to $50 billion USD per month [appendix]. Assuming users are able to use services such as blockchain calls provided by XPhone (or other phones using Function X) the savings will be immense and the gain from profit can be passed on to providers such as DApp developers in Function X. In other words, instead of paying hefty bills to a mobile carrier for voice calls, users can pay less by making blockchain calls, and the fees paid are in f(x) coins. More importantly users will have complete privacy over their calls.
Use Cases: Decentralized file storage
Ethereum contracts claim to allow for the development of a decentralized file storage ecosystem, “where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.” However, they do not necessarily have the hardware to back this up. With the deployment of XPOS, smart hardware nodes and more, Function X is a natural fit for Decentralized File Storage. In fact, it is basically what f(x) IPFS is built for.
These are just four examples of the many use cases purported, and there can, will and should be more practical applications beyond these; we are right in the middle of uncharted territories.

Tokenomics

Decentralized and autonomous
The f(x) ecosystem is fully decentralized. It’s designed and built to run autonomously in perpetuity without the reliance or supervision of any individual or organization. To support this autonomous structure, f(x) Coin which is the underlying ‘currency’ within the f(x) ecosystem has to be decentralized in terms of its distribution, allocation, control, circulation and the way it’s being generated.
To get the structure of f(x) properly set up, the founding team will initially act as ‘initiators’ and ‘guardians’ of the ecosystem. The role of the team will be similar to being a gatekeeper to prevent any bad actors or stakeholders playing foul. At the same time, the team will facilitate good players to grow within the ecosystem. Once the f(x) ecosystem is up and running, the role of the founding team will be irrelevant and phased out. The long term intention of the team is to step away, allowing the ecosystem to run and flourish by itself.

Utility

In this section, we will explore the utility of the f(x) Coin. f(x) Coin is the native ‘currency’ of the Function X blockchain and ecosystem. All services rendered in the ecosystem will be processed, transacted with, or “fueled” by the f(x) Coin. Some of the proposed use cases include:
  • For service providers: Getting paid by developers, companies and consumers for providing storage nodes, DDocker and improvement of network connections. The role of service providers will be described in greater detail in the rest of the paper.
  • For consumers: Paying for service fees for the DApps, nodes, network resources, storage solutions and other services consumed within the f(x) ecosystem.
  • For developers: Paying for services and resources rendered in the ecosystem such as smart contract creation, file storage (paid to IPFS service provider), code hosting (paid to DDocker service provider), advertisements (paid to other developers) and design works. Developers can also get paid by enterprises or organizations that engaged in the developer’s services.
  • For enterprises or organizations: Paying for services provided by developers and advertisers. Services provided to consumers will be charged and denominated in f(x) Coin.
  • For phone and hardware manufacturers: Paying for further Function X OS customizations. It is worth noting that Pundi X Labs plan to only build a few thousand devices of the XPhone flagship handsets, and leave the subsequent market supply to be filled by third-party manufacturers using our operating system.
  • For financial institutions: receiving payments for financial services rendered in the ecosystem.
  • Applications requiring high throughput.
Hence f(x) Coin can be used as ‘currency’ for the below services,
  • In-app purchases
  • Blockchain calls
  • Smart contract creations
  • Transaction fees
  • Advertisements
  • Hosting fees
  • Borderless/cross-border transactions
We believe f(x) Coin utilization will be invariably higher than other coins in traditional chains due to the breadth of the f(x) ecosystem. This includes storage services and network resources on f(x) that will utilize the f(x) Coin as “fuel” for execution and validation of transactions.
Example 1: A developer creates a ride-hailing DApp called DUber.
DUber developer first uploads the image and data to IPFS (storage) and code to DDocker, respectively. The developer then pays for a decentralized code hosting service provided by the DDocker, and a decentralized file hosting service provided by the IPFS. Please note the storage hosting and code hosting services can be provided by a company, or by a savvy home user with smart nodes connected to the Function X ecosystem. Subsequently, a DUber user pays the developer.
Example 2: User Alice sends an imaginary token called ABCToken to Bob.
ABCToken is created using Function X smart contract. Smart nodes hosted at the home of Charlie help confirms the transaction, Charlie is paid by Alice (or both Alice and Bob).

The flow of f(x) Coin

Four main participants in f(x): Consumer (blue), Developer (blue), Infrastructure (blue), and Financial Service Provider (green)
Broadly speaking, there can be four main participants in the f(x) ecosystem, exhibited by the diagram above:
  • Consumer: Users enjoy the decentralized services available in the f(x) ecosystem
  • Infrastructure Service Provider: Providing infrastructures that make up the f(x) ecosystem such as those provided by mobile carriers, decentralized clouds services.
  • Developer: Building DApp on the f(x) network such as decentralized IT, hospitality and financial services apps.
  • Financial Service Provider: Providing liquidity for the f(x) Coin acting as an exchange.
The f(x) ecosystem’s value proposition:
  • Infrastructure service providers can offer similar services that they already are providing in other markets such as FXTP, DDocker and IPFS, to earn f(x) Coin.
  • Developers can modify their existing Android apps to be compatible with the f(x) OS environment effortlessly, and potentially earn f(x) Coin.
  • Developers, at the same time, also pay for the infrastructure services used for app creation.
  • Consumers immerse in the decentralized app environments and pay for services used in f(x) Coin.
  • Developer and infrastructure service providers can earn rewards in f(x) Coin by providing their services. They can also monetize it through a wide network of financial service providers to earn some profit, should they decide to do so.
Together, the four participants in this ecosystem will create a positive value flow. As the number of service providers grow, the quality of service will be enhanced, subsequently leading to more adoption. Similarly, more consumers means more value is added to the ecosystem by attracting more service providers,and creating f(x) Coin liquidity. Deep liquidity of f(x) Coin will attract more financial service providers to enhance the stability and quality of liquidity. This will attract more service providers to the ecosystem.
Figure: four main participants of the ecosystem The rationale behind f(x) Coin generation is the Proof of Service concept (PoS)
Service providers are crucial in the whole f(x) Ecosystem, the problem of motivation/facilitation has become our priority. We have to align our interests with theirs. Hence, we have set up a Tipping Jar (similar to mining) to motivate and facilitate the existing miners shift to the f(x) Ecosystem and become part of the infrastructure service provider or attract new players into our ecosystem. Income for service provider = Service fee (from payer) + Tipping (from f(x) network generation)
The idea is that the f(x) blockchain will generate a certain amount of f(x) Coin (diminishing annually) per second to different segments of service provider, such as in the 1st year, the f(x) blockchain will generate 3.5 f(x) Coin per second and it will be distributed among the infrastructure service provider through the Proof of Service concept. Every service provider such as infrastructure service providers, developers and financial service providers will receive a ‘certificate’ of Proof of Service in the blockchain after providing the service and redeeming the f(x) Coin.
Example: There are 3 IPFS providers in the market, and the total Tipping Jar for that specific period is 1 million f(x) Coin. Party A contributes 1 TB; Party B contributes 3 TB and Party C contributes 6 TB. So, Party A will earn 1/10 * 1 million = 100k f(x) Coin; Party B will earn 3/10 * 1 million = 300k f(x) Coin. Party C will earn 6/10 * 1 million = 600k f(x) Coin.
Note: The computation method of the distribution of the Tipping Jar might vary due to the differences in the nature of the service, period and party.
Figure: Circulation flow of f(x) Coin
The theory behind the computation.
Blockchain has integrated almost everything, such as storage, scripts, nodes and communication. This requires a large amount of bandwidth and computation resources which affects the transaction speed and concurrency metric.
In order to do achieve the goal of being scalable with high transaction speed, the f(x) blockchain has shifted out all the ‘bulky’ and ‘heavy duty’ functions onto other service providers, such as IPFS, FXTP, etc. We leave alone what blockchain technology does best: Calibration. Thus, the role of the Tipping Jar is to distribute the appropriate tokens to all participants.
Projected f(x) Coin distribution per second in the first year
According to Moore’s Law, the number of transistors in a densely integrated circuit doubles about every 18 -24 months. Thus, the performance of hardware doubles every 18-24 months. Taking into consideration Moore’s Law, Eric Schmidt said if you maintain the same hardware specs, the earnings will be cut in half after 18-24 months. Therefore, the normal Tipping Jar (reward) for an infrastructure service provider will decrease 50% every 18 months. In order to encourage infrastructure service providers to upgrade their hardware, we have set up another iteration and innovation contribution pool (which is worth of 50% of the normal Tipping Jar on the corresponding phase) to encourage the infrastructure service provider to embrace new technology.
According to the Andy-Bill’s law, “What Andy gives, Bill takes away”; software will always nibble away the extra performance of the hardware. The more performance a piece of hardware delivers, the more the software consumes. Thus, the developer will always follow the trend to maintain and provide high-quality service. The Tipping Jar will increase by 50% (based upon the previous quota) every 18 months.
Financial service providers will have to support the liquidation of the whole ecosystem along the journey, the Tipping Jar (FaaS) will increase by 50% by recognizing the contribution and encouraging innovation.
From the 13th year (9th phase), the Tipping Jar will reduce by 50% every 18 months. We are well aware that the “cliff drop” after the 12th year is significant. Hence, we have created a 3year (two-phase) diminishing transition period. The duration of each phase is 18 months. There are 10 phases in total which will last for a total of 15 years.
According to Gartner’s report, the blockchain industry is forecast to reach a market cap of
3.1 trillion USD in 2030. Hence, we believe a Tipping Jar of 15 years will allow the growth of Function X into the “mature life cycle” of the blockchain industry.

f(x) Coin / Token Allocation

Token allocation We believe great blockchain projects attempt to equitably balance the interests of different segments of the community. We hope to motivate and incentivize token holders by allocating a total of 65% of tokens from the Token Generation Event (TGE). Another 20% is allocated to the Ecosystem Genesis Fund for developer partnerships, exchanges and other such related purposes. The remaining 15% will go to engineering, product development and marketing. There will be no public or private sales for f(x) tokens.
NPXS / NPXSXEM is used to make crypto payments as easy as buying bottled water, while f(x) is used for the operation of a decentralized ecosystem and blockchain, consisting of DApps and other services. NPXS / NPXSXEM will continue to have the same functionality and purpose after the migration to the Function X blockchain in the future. Therefore, each token will be expected to assume different fundamental roles and grant different rights to the holders.
https://preview.redd.it/xohy6c6pprv21.png?width=509&format=png&auto=webp&s=a2c0bd0034805c5f055c3fea4bd3ba48eb59ff07
65% of allocation for NPXS / NPXSXEM holders is broken down into the following: 15% is used for staking (see below) 45% is used for conversion to f(x) tokens. (see below) 5% is used for extra bonus tasks over 12 months (allocation TBD).

https://preview.redd.it/6jmpfhmxprv21.png?width=481&format=png&auto=webp&s=c9eb2c124e0181c0851b7495028a317b5c9cd6b7
https://preview.redd.it/1pjcycv0qrv21.png?width=478&format=png&auto=webp&s=c529d5d99d760281efd0c3229edac494d5ed7750
Remarks All NPXS / NPXSXEM tokens that are converted will be removed from the total supply of NPXS / NPXSXEM; Pundi X will not convert company's NPXS for f(x) Tokens. This allocation is designed for NPXS/NPXSXEM long term holders. NPXS / NPXSXEM tokens that are converted will also be entitled to the 15% f(x) Token distribution right after the conversion.

Usage

Management of the Ecosystem Genesis Fund (EGF)
The purpose of setting up the Ecosystem Initialization Fund, is to motivate, encourage and facilitate service providers to join and root into the f(x) Ecosystem and, at the same time, to attract seed consumers to enrich and enlarge the f(x) Ecosystem. EIF comes from funds raised and will be used as a bootstrap mechanism to encourage adoption before the Tipping Jar incentives fully kicks in.
The EGF is divided into 5 parts:
  1. Consumer (10%): To attract consumers and enlarge the customer base;
  2. Developer (20%): To encourage developers to create DApps on the f(x) blockchain;
  3. Infrastructure Service Provider (20%): To set up or shift to the f(x) infrastructure;
  4. Financial Service Provider (20%): To create a trading platform for f(x) Coin and increase liquidity; and
  5. Emergency bridge reserve (30%): To facilitate or help the stakeholders in f(x) during extreme market condition
To implement the spirit of decentralization and fairness, the EGF will be managed by a consensus-based committee, called the f(x) Open Market Committee (FOMC).

Summary

Time moves fast in the technology world and even faster in the blockchain space. Pundi X’s journey started in October 2017, slightly over a year ago, and we have been operating at a lightning pace ever since, making progress that can only be measured in leaps and bounds. We started as a blockchain payment solution provider and have evolved into a blockchain service provider to make blockchain technology more accessible to the general public, thereby improving your everyday life.
The creation of Function X was driven by the need to create a better suited platform for our blockchain point-of sale network and through that process, the capabilities of Function X have allowed us to extend blockchain usage beyond finance applications like payment solutions and cryptocurrency.
The complete decentralized ecosystem of Function X will change and benefit organizations, developers, governments and most importantly, society as a whole.
The XPhone prototype which we have created is just the start to give everyone a taste of the power of Function X on how you can benefit from a truly decentralized environment. We envision a future where the XPOS, XPhone and other Function X-enabled devices work hand-in-hand to make the decentralized autonomous ecosystem a reality.
You may wonder how are we able to create such an extensive ecosystem within a short span of time? We are fortunate that in today’s open source and sharing economy, we are able to tap onto the already established protocols (such as Consensus algorithm, FXTP, etc), software (like Android, IPFS, PBFT, Dockers, etc.) and hardware (design knowledge from existing experts) which were developed by selfless generous creators. Function X puts together, aggregates and streamlines all the benefits and good of these different elements and make them work better and seamlessly on the blockchain. And we will pay it forward by making Function X as open and as decentralized as possible so that others may also use Function X to create bigger and better projects.
To bring Function X to full fruition, we will continue to operate in a transparent and collaborative way. Our community will continue to be a key pillar for us and be even more vital as we get Function X up and running. As a community member, you will have an early access to the Function X ecosystem through the f(x) token conversion.
We hope you continue to show your support as we are working hard to disrupt the space and re-engineer this decentralized world.

Reference

Practical Byzantine Fault Tolerance
http://pmg.csail.mit.edu/papers/osdi99.pdf
Byzantine General Problem technical paper
https://web.archive.org/web/20170205142845/http://lamport.azurewebsites.net/pubs/byz.pdf
Global mobile data revenues to reach $630 billion by 2020
https://www.parksassociates.com/blog/article/pr-07112016
NPXSXEM token supply
https://medium.com/pundix/a-closer-look-at-npxsxem-token-supply-843598d0e7b6
NPXS circulating token supply and strategic purchaser
https://medium.com/pundix/total-token-supply-and-strategic-investors-b41717021583
[total supply might differ from time to time due to token taken out of total supply aka “burn”]
ELC: SpaceX lessons learned (PBFT mentioned) https://lwn.net/Articles/540368/

Full: https://functionx.io/assets/file/Function_X_Concept_Paper_v2.0.pdf
submitted by crypt0hodl1 to PundiX [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]

Weekly Dev Update #17

THORChain Weekly Dev Update for Week 12–18 Nov 2019

![](https://miro.medium.com/max/2880/1*Fy-NCZAKhgbZmE-iEIQChQ.png)

Recent Changes

Some recent updates to the protocol:

Update to Emission

The first iteration of the block reward scheme was announced in the previous weekly update. An immediate concern raised from the community was that the emission was too aggressive in the initial year and rewards dropped off fast beyond the 5 year mark. Taking Bitcoin’s emission as an example, the emission curve has been updated to target 2% emission after 10 years.
![](https://miro.medium.com/max/2384/1*gqBLvJOl2G4n3IHW1rViKg.png)
The Block Reward equation is given by the following recurrence equation: g(n+2) = ((R - (g(n+1) + g(n))) / x) / y Which evaluates to: ![](https://miro.medium.com/max/1624/1*ttpsRd7HUs2-7hvDGO6elg.png) where: R = Reserve, x = 6 (Arbitrary Emission Factor) y = (seconds per day / seconds per block) / days per year y = (86400 / 5) * 365.2425 The final curve thus has a Day 0 emission of 25%, Year 1 emission of 20% and Year 10 emission of 2%.

ChaosNet

The original plan for BEPSwap (prior to the Yggdrasil liquidity breakthrough) was to have it as a separate mainnet before launching the real THORChain in 2020 with cross-chain support. Now THORChain has in-built cross-chain support and a clear roadmap to 99 nodes. This means the mainnet launch will have public, community-run nodes at the start. The community has been fielding many questions about how to run a node, and the mechanics in doing so. Since the THORChain team will not be running any nodes, it is necessary to have a full-rehearsal with the community at launch. As such, the plan is for a public ChaosNet on 03 January 2020. ChaosNet will have the following key differences: * Minimum bond of 100k RUNE. * Maximum of 12 Nodes. * Churn cycle of 1 day. * Maximum stake amount of 600k RUNE total. * 2.7m RUNE Protocol Reserve to emit Bond and Stake rewards. * Hard-coded Ragnorök at 6 weeks.
Any member who wishes to join ChaosNet to get accustomed to running a node can do so, and will receive Block Rewards roughly equivalent to mainnet (25%). They will be setting up nodes, churning in, servicing the network and earning rewards. The system will hold up to 600k Rune, at which point it will refund any additional staked amount. The community can stake small amounts of real assets, prepare arbitrage bots, set up telegram alert bots and more. In short, it is a public rehearsal with the entire community across all facets (nodes, stakers, traders) so that everyone will have access to the same information and not unfairly benefit when the real mainnet launches. Additionally, the system will be hard-coded to perform a Ragnorök 6 weeks later, which will refund all the remaining reserve as well as bonded and staked assets. This will go a long way in re-assuring the community that the system can tolerate all levels of risk, including black-swan events, and that funds are safe at all times.

Internal Arbitrage

A new feature will be launched that will allow users to use internal arbitrage. This is an asymmetrical withdrawal to Rune, then immediately followed by a asymmetrical stake of Rune in another pool. A trader may want to do this instead of doing transactional arbitrage in order to exploit price differences between two pools the fastest way possible. Instead of an outgoing transaction being processed, followed by another incoming transaction, Rune balances and stakeUnits are swapped internally, being completed inside of a few seconds.

Fee-based Transaction Prioritisation

Currently there is no prioritisation to the order of transactions, all transactions are simply processed in order of time received. In moments of high demand of network resources (such as when there are large arbitrage opportunities and users are racing to exploit them), transactions will queue in the mempool. If the system cannot respond fast enough, then the reason for high demand will persist (the large arbitrage opportunity). The solution is to remove the reason for high demand in the first place, which is the large arbitrage opportunity, at the same time as collecting the maximum revenue for the system. As such, in the checkTx method (which can triage the mempool), transactions will be sorted and ordered in the value of the fee of the swap transaction. Assuming rational actors, the following transactions will then be prioritised over all others: * A transaction from an impatient swapper who is willing to pay a large fee. * A transaction from a trader who is able to arbitrage out a price discrepancy (and still make a gain).
This then means the system can collect as much income as possible (good for the stakers) at the same time as prioritising transactions that can arbitrage out large price discrepancies quickly. This then means swaps from transient swappers will experience a market price that accurately matches the reference price at all times.

BEPSwap Development

The team are working on 4 parallel streams of effort. Cross-chain infrastructure has now been merged into a single repo called “THORNode”. * THORChain * Midgard Public API * Threshold Signature Scheme implementation * Front-end Integration for BEPSwap

THORChain

Bug fixes, refactoring, as well as more logic around Yggdrasil funding. Additionally, node churn and the first part of block rewards PR was merged. * Add admin config event, fix tx out events https://gitlab.com/thorchain/bepswap/thornode/merge_requests/255 * Resolve “Select a satellite pool to swap out” https://gitlab.com/thorchain/bepswap/thornode/merge_requests/253 * Include the thorcli volume for the signer. https://gitlab.com/thorchain/bepswap/thornode/merge_requests/261 * Rune Reserves, block rewards, bond units, oh my! https://gitlab.com/thorchain/bepswap/thornode/merge_requests/258 * Add mechanism to slash a node account bond or rewards https://gitlab.com/thorchain/bepswap/thornode/merge_requests/264 * Add add event https://gitlab.com/thorchain/bepswap/thornode/merge_requests/262 * Issue198 node churn https://gitlab.com/thorchain/bepswap/thornode/merge_requests/270 * Issue199 — fix signer doesn’t process multiple txout item https://gitlab.com/thorchain/bepswap/thornode/merge_requests/271 * issue194: only rune get refund for invalid memo https://gitlab.com/thorchain/bepswap/thornode/merge_requests/272 * Outbound — mark txout item out hash based on the coin as well https://gitlab.com/thorchain/bepswap/thornode/merge_requests/273

Midgard Public API

Database ported from influxdb to timescaledb (more maturity, better developer tooling). Endpoints built out include/pools and /stakers. * Feature/new endpoint format, refactors and general clean ups
The OpenApi Schema can be reviewed here:
https://testnet-api.bepswap.net/v1/doc

Threshold Signature Scheme

TSS was successfully implemented into the Genesis ceremony, with the focus now being on the key-gen and key-sign ceremonies. Multi-cast DNS was switched out for a distributed hash table to facilitate node discovery. * Issue4 — docker images and ci https://gitlab.com/thorchain/tss/multi-party-ecdsa-dockemerge_requests/5 * Fix a docker bug https://gitlab.com/thorchain/tss/multi-party-ecdsa-dockemerge_requests/6
A proof-of-concept is being prepared using BinanceChain TSS library, which was recently launched in order to make a decision whether to switch libraries. A go-based implementation is better for THORNode, since it is also written in Go.
https://github.com/binance-chain/tss-lib

Frontend Implementation

Bug-fixes and tweaks from community feedback. The frontend is now ready for implementation with the latest Midgard API. * Resolve “Write cypress e2e test for pool stake list view” https://gitlab.com/thorchain/bepswap/bepswap-react-app/merge_requests/164 * Resolve “Update rune token icon” https://gitlab.com/thorchain/bepswap/bepswap-react-app/merge_requests/165 * Resolve “Update confirmation modal” https://gitlab.com/thorchain/bepswap/bepswap-react-app/merge_requests/166 * Resolve “Update wallet view” https://gitlab.com/thorchain/bepswap/bepswap-react-app/merge_requests/167 * Resolve “Add tooltip for wallet connection” https://gitlab.com/thorchain/bepswap/bepswap-react-app/merge_requests/168

Timelines

The team are working for these milestones: * Feature Freeze: 20 November 2019 on-time * Audit: 20 December 2019 on-time * ChaosNet: 03 January 2020 on-time

Community

To keep up to date, please monitor community channels, particularly Telegram and Twitter: Twitter: https://twitter.com/thorchain_org Telegram Community: https://t.me/thorchain_org Telegram Announcements: https://t.me/thorchain Reddit: https://reddit.com/thorchain Github: https://github.com/thorchain Medium: https://medium.com/thorchain
submitted by thorchain_org to THORChain [link] [comments]

FUNCTION-X ECOSYSTEM: KEY COMPONENTS AND AMAZING THINGS YOU SHOULD KNOW ABOUT IT!

Good day crypto enthusiasts, for some time now I have been reviewing Function X and the technological innovations it has rendered. In my last publication, I discussed about Function X and how it employed block chain for it's smooth running operations. You may check the article here: Today, I shall discuss about the Key components of Function X and the Amazing things you should know about the Invention. Sit back and read on! Remember, I research, analyze, review and Invest!
COMPONENTS OF THE ECOSYSTEM Function-X Ecosystem is composed of five basic (core) constituents, namely: Function-X distributed ledger (Blockchain) Function-X OS Function-X IPFS Function-X TP Function-X Decentralized Docker
WHY ALL THESE COMPONENTS? All of the above components serve a sole purpose of decentralizing all service, websites, applications, communications, as well data (data is the most important of all).
WHAT IS THE FUNCTION-X DISTRIBUTED LEDGER (CHAIN)? The Function-X chain is a set of consensus algorithmic procedures or steps in the form of a decentralized ledger which lies in the Function-X Ecosystem. This distributed ledger is actually based or built on the Block-chain and it is designed to store and confirm transactions including: Financial activities Settlements of payments Communications (such as file transfers/storage and making of calls) Services (using the f(X) DApps)
The following are few facts (projections) on the f(x) chain: A mainnet: the chain, being Block-chain will have a mainnet that will be launched with it. Projected Mainnet launch date: 3rd quarter of year 2019 Projected testnet launch date: 2nd quarter of year 2019
DESIGN OF FUNCTION-X CHAIN Function-X chain is designed according to the philosophy that any Block-chain should be able to tackle market demand, in reality. It is designed to possess a big performance and processing rate. This is done by combining easily accessible hardware support (XPOS, iPhone, etc) and an open-source software-toolkit enhancements.
WHAT DEVICES WILL BE CONNECTED TO THE CHAIN? XPOS OS, which will eventually be substituted with the Function-X OS, and XPhone will be linked to the chain.
FUNCTIONALITY OF THE CHAIN'S BLOCK Meanwhile, each of this chain's block will be used to store anything that can be transmitted over the decentralized Network. These can include websites, data packets, source code, records of phone calls, among other things. These will form the elements of each block.
DATA SECURITY IN EACH BLOCK All data stored on a block is made secure by encryption such that only the person who has the private key will be able to choose how to go about data sharing, storage, decryption and even destruction. CONCENSUS MECHANISM The consensus mechanism Function-X will employ is 'Practical Byzantine Fault Tolerance (PBFT)
PLANS FOR FASTER CHAIN PERFORMANCE Pundi-X Ltd wants to a achieve a higher speed that will surpass that of Etherium and Bitcoin networks, through the special configuration of their hardware and software.
FUNCTION-X OPERATING SYSTEM- f(X) OS The Function-X OS is an Android-modified OS which is compatible with Block-chain. One can switch easily between the traditional (normal Android) mode and the Block-chain mode. As expected, the Block-chain mode is completely decentralized while the traditional mode will support all features of the normal Android OS.
TRANSMISSION PROTOCOL- f(X) FXTP A transmission/transfer protocol controls the rules that govern how information is sent through a network. How information on the internet, such as web contents is governed by the HTTP (HyperText Transfer Protocol). FXTP is a protocol for the Function-X Decentralized Network. FXTP is unlike in that it is an end-to-end transfer whereby data processing can be done on a consensus mechanism instead of a mechanism based on client-server-decision-making.
FUNCTION-X IPFS Storage of data or files NB in this distributed system is achieved using IPFS. Files are securely stored on this network such that anyone who needs a file can retrieve it by calling it's identifier (hash), then IPFS scans through other nodes in the network and provides the file.
FUNCTION-X DECENTRALIZED DOCKER- f(X) DDOCKER What is a Docker? It is any program on a computer that is used to make the creation, deployment and running of apps easier. According to it's name, f(X) Decentralized Docker is designed to operate in a decentralized Network.
Website: https://functionx.io/#/
submitted by Tina4real to IcoInvestor [link] [comments]

How To Set Up a Firewall Using FirewallD on CentOS 7

The majority of this definition is actually metadata. You will want to change the short name for the service within the tags. This is a human-readable name for your service. You should also add a description so that you have more information if you ever need to audit the service. The only configuration you need to make that actually affects the functionality of the service will likely be the port definition where you identify the port number and protocol you wish to open. This can be specified multiple times.
For our “example” service, imagine that we need to open up port 7777 for TCP and 8888 for UDP. By entering INSERT mode by pressing i , we can modify the existing data center in moldova definition with something like this:
/etc/firewalld/services/example.xml
  Example Service This is just an example service. It probably shouldn't be used on a real system.    
Press ESC , then enter :x to save and close the file.
Reload your firewall to get access to your new service:
sudo firewall-cmd --reload 
You can see that it is now among the list of available services:
firewall-cmd --get-services outputRH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync elasticsearch example freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kibana klogin kpasswd kshell ldap ldaps libvirt libvirt-tls managesieve mdns mosh mountd ms-wbt mssql mysql nfs nrpe ntp openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius rpc-bind rsh rsyncd samba samba-client sane sip sips smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server 
You can now use this service in your zones as you normally would.

Creating Your Own Zones

While the predefined zones will probably be more than enough for most users, it can be helpful to define your own zones that are more descriptive of their function server management in romania.
For instance, you might want to create a zone for your web server, called “publicweb”. However, you might want to have another zone configured for the DNS service you provide on your private network. You might want a zone called “privateDNS” for that.
When adding a zone, you must add it to the permanent firewall configuration. You can then reload to bring the configuration into your running session. For instance, we could create the two zones we discussed above by typing:
sudo firewall-cmd --permanent --new-zone=publicweb 
sudo firewall-cmd --permanent --new-zone=privateDNS
You can verify that these are present in your permanent configuration by typing:
sudo firewall-cmd --permanent --get-zones outputblock dmz drop external home internal privateDNS public publicweb trusted work 
As stated before, these won’t be available in the current instance of the firewall yet:
firewall-cmd --get-zones outputblock dmz drop external home internal public trusted work 
Reload the firewall to bring these new zones into the active configuration:
sudo firewall-cmd --reload 
firewall-cmd --get-zones outputblock dmz drop external home internal privateDNS public publicweb trusted work
Now, you can begin assigning the appropriate services and ports to your zones. It’s usually a good idea to adjust the web hosting in moldova active instance and then transfer those changes to the permanent configuration after testing. For instance, for the “publicweb” zone, you might want to add the SSH, HTTP, and HTTPS services:
sudo firewall-cmd --zone=publicweb --add-service=ssh 
sudo firewall-cmd --zone=publicweb --add-service=http sudo firewall-cmd --zone=publicweb --add-service=https sudo firewall-cmd --zone=publicweb --list-all outputpublicweb target: default icmp-block-inversion: no interfaces: sources: services: ssh http https ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Likewise, we can add the DNS service to our “privateDNS” zone:
sudo firewall-cmd --zone=privateDNS --add-service=dns 
sudo firewall-cmd --zone=privateDNS --list-all outputprivateDNS interfaces: sources: services: dns ports: masquerade: no forward-ports: icmp-blocks: rich rules:
We could then change iaas platform in romania our interfaces over to these new zones to test them out:
sudo firewall-cmd --zone=publicweb --change-interface=eth0 
sudo firewall-cmd --zone=privateDNS --change-interface=eth1
At this point, you have the opportunity to test your configuration. If these values work for you, you will want to add the same rules to the permanent configuration. You can do that by re-applying the rules with the --permanent flag:
sudo firewall-cmd --zone=publicweb --permanent --add-service=ssh 
sudo firewall-cmd --zone=publicweb --permanent --add-service=http sudo firewall-cmd --zone=publicweb --permanent --add-service=https sudo firewall-cmd --zone=privateDNS --permanent --add-service=dns
After permanently applying these your rules, you can restart your hourly kvm vps in europe network and reload your firewall service:
sudo systemctl restart network 
sudo systemctl reload firewalld
Validate that the correct zones were assigned:
firewall-cmd --get-active-zones outputprivateDNS interfaces: eth1 publicweb interfaces: eth0 
And validate that the appropriate services are available for both of the zones:
sudo firewall-cmd --zone=publicweb --list-services outputhttp https ssh sudo firewall-cmd --zone=privateDNS --list-services outputdns 
You have successfully set up your dedicated server in romania! If you want to make one of these zones the default for other interfaces, remember to configure that behavior with the --set-default-zone= parameter:
sudo firewall-cmd --set-default-zone=publicweb 

Conclusion

You should now have a windows remote desktop fairly good understanding of how to administer the firewalld service on your CentOS system for day-to-day use.
The firewalld service allows you to configure reseller kvm vps program maintainable rules and rule-sets that take into consideration your network environment. It allows you to seamlessly transition between different firewall policies through the use of zones and gives administrators the ability to abstract the port management into more friendly service definitions. Acquiring a working knowledge of this system will allow you to take advantage of the kvm virtual server flexibility and power that this tool provides.
submitted by namemk to u/namemk [link] [comments]

Weekly Dev Update #14

Weekly Dev Update #14

THORChain Weekly Dev Update for Week 22–28 Oct 2019

![](https://miro.medium.com/max/3352/1*TsS95GJsfPJqflMuTo6GLw.png)

BEPSwap Goes Cross-chain

BEPSwap is THORChain’s first go-to market product, built on a statechain to Binance Chain. BEPSwap was intended to only support BEP2 assets to minimise complexity with external chains. Two recent breakthroughs made by the THORChain development team in how to consider the cross-chain environment, as well as increasing the number of consensus participants, mean the team have now re-considered the scope of mainnet launch. Instead of launching the BEPSwap chain and decommissioning/hard-forking it into the THORChain mainnet, the team believe a network that supports cross-chain from the start can be built now. As such, THORChain will be launched, with support for Binance Chain, Bitcoin and Ethereum at Genesis. Binance Chain assets will be immediately supported, with Bitcoin and Ethereum enabled sometime in 2020. This will prevent large changes needing to occur post-mainnet launch. These two breakthroughs will be discussed in a future blog, but the team describe them as “Cross-chain Pools” and “Asynchronous Liquidity Delegation”.

Cross-chain Pools.

Cross-chain pools solve two key problems: 1. Security 2. User Experience. The first is that the network only holds assets that are in pools which are staked against Rune. This massively simpifies the attack surface of the network, since the network only needs to ensure that the amount of bonded Rune is always double the amount of staked Rune. This means that even if network participants could attack the network, they wouldn’t, because they can only steal 50% of what they bonded. Thus no rational actor would steal external assets. The second characteristic is the User Experience, in that neither pegged tokens, nor atomic swaps are used. Users who wish to swap BTC to ETH send in on-chain BTC, and will receive on-chain ETH immediately (and vice versa). The target speed for BTC->ETH will be 20 seconds. The target speed for ETH->BTC will be 10 minutes (1 block). Users who wish to stake, will stake on-chain BTC with on-chain Rune. Withdrawing their assets will mean they receive on-chain BTC and on-chain Rune. No pegging out, and no pegging in.

Asynchronous Liquidity Delegation.

The second breakthrough is how liquidity is managed in the system. The initial design had a single large Threshold Signature pool that held all the funds. While extremely secure, large committee memberships mean very long signing speeds (minutes for 67/100), which impacts the user experience. The team wish to target a signing speed of less than 5 seconds, which means TSS pools should be less than 11 participants. However, due to the incentive structure created by Cross-chain pools, no node has an incentive to steal assets — even if they were given individual custody of assets. This is because they are always bonding twice as much Rune as there is Rune staked in pools. A node that “exit-scams” the network is the equivalent to simply selling 50% of their bonded Rune to assets and leaving disorderly. The network can rebuild the pools by simply disbursing the node’s abandoned bond back into the pools, and churning in a new node. Thus it is resilient to even internal attacks. This setup even works for a node that goes offline — while offline they are unable to respond and they get “fined” from their bond for every transaction they couldn’t honour in a timely fashion. The final design is a large TSS pool that acts as a global custodian of bonded assets and incoming liquidity ( 22 of 33 is the initial target number), with 11 2 of 3 “satellite” pools which hold 50% of the staked assets. This means nodes can be delegated to asynchronously send out liquidity (swaps and withdrawals) with the signing speed of 2 of 3, but the security of 22 of 33. Over time, the team will target 200 of 300 nodes, with 100 2 of 3 satellite pools.

BEPSwap Development

The team are working on 4 parallel streams of effort. Cross-chain infrastructure has now been merged into a single repo called “THORNode”. 1. THORChain 2. Threshold Signature Scheme implementation 3. Front-end Integration for BEPSwap 4. Other development activities

StateChain

A lot of new work was done to make the statechain cross-chain, with agnostic treatment to chain data. The first three chains will be BNB, BTC and ETH. A global re-factor of naming conventions surrounding cross-chain assets was made. * Add chain to pools * Issue140 if the ticker and coin are the same , thus we don’t need to swap just refund * Issue150 add GAS result in a pool in suspended status * Auto-seed the development environment after a deploy. * Add Asset and Symbol common structs * Get stage seeding on nightly deploys. * Continue importing asset into thornode * Change coin.Denom to coin.Asset * Replace “Token” → “asset” * issue135 update stake logic to check ticker match coin * issue151 add cors support * Feature/docker compose updated build pipelines * Issue138 fix signer use wrong symbol issue , which cause issue with refund * Per chain gas policy * Remove binance specific logic * Choose rune asset based on mainnet vs testnet * Genesis ceremony * Added seed and smoke-test targets to .PHONY
![](https://miro.medium.com/max/3808/1*6HdyayI35M4ozW6s_eoGQQ.png) Assets will now be referred to as: CHAIN.SYMBOL

FrontEnd

Based on community feedback, the front-end is being refreshed. A lot of the past weeks updates were fixing small bugs and implementing the fresh design: * Resolve “Update theme variables and sizes” * Resolve “Update API endpoint with the prefix in the Front-End” * Resolve “Update Tab, Button, CoinButton component” * Resolve “BUG: Token amount selection doesn’t work properly in the Pool Stake” * Resolve “Update header, content layout” * Resolve “Build components for swap detail page” * Resolve “Implement Swap Detail Page” * Resolve “Fix issue for token amount input component”
![](https://miro.medium.com/max/4856/1*ozHbZXXLeCnvTGc0xNxNtQ.png) Swap Home Page
![](https://miro.medium.com/max/4784/1*8YY2dFqdCpO0opEICbQFtQ.png) Swap Detail View
![](https://miro.medium.com/max/2724/1*BYmhdcUgasfAmV9Yldu9bg.png) Swap Confirmation
![](https://miro.medium.com/max/3328/1*8pPD75MCcqaVFk1tZ4doCQ.png) Stake Detail View

Threshold Signature Scheme implementation

Work was done to clean up the code for peer-review, as well as implementing whitelisting for key-generation procedure. The TSS implementation is being integrated into the Statechain this week, in time to validate Asgard churn.

Whats Next?

To ship mainnet, the team are aiming for this:

Frontend:

Feature complete with excellent swapping and staking experience.

Chain Service:

Feature complete public RESTful API.

Statechain:

Feature complete with 22 of 33 Asgard, weekly churn, 2 of 3 satellite pools, asynchronous liquidity delegation and cross-chain support.

Timelines

The team are working for these milestones.

Other Development:

RUNEVault: July 2019 shipped Telegram Bot: August 2019 shipped Bep2Bot: August 2019 shipped

BEPSwap:

Testnet: August 2019 shipped Community Testing: shipped

THORChain:

Internal Freeze: 20 November 2019 on-time Audit: 20 December 2019 on-time Genesis: 03 January 2020 on-time

Community

To keep up to date, please monitor community channels, particularly Telegram and Twitter: * Twitter: https://twitter.com/thorchain_org * Telegram Community: https://t.me/thorchain_org * Telegram Announcements: https://t.me/thorchain * Reddit: https://reddit.com/thorchain * Github: https://github.com/thorchain * Medium: https://medium.com/thorchain
submitted by thorchain_org to THORChain [link] [comments]

Nidus: Risk Control Blockchain designed for speed, transparency and reliability

When designing Sparrow, we studied a variety of decentralized exchange implementations: on-chain order books, automated market makers, state channels, and hybrid off-chain order books. We frequently asked ourselves: Who do we ultimately serve? What are their concerns? What tradeoffs make the most sense for our users? How do we help them control their risk and bring confidence to a very young market?
After collecting feedback we learned that our users want options to be matched quickly, and once executed, their digital assets should be handled transparently and transferred reliably during settlement. We concluded that speed would be the most critical issue, followed closely by transparency and reliability.
We decided to base Sparrow on a hybrid off-chain approach coupled with a Proof-of-Authority (PoA) consensus algorithm built on Ethereum smart contracts, as this implementation would fundamentally provide the fastest transaction speeds for the users in the network and provide transparent and reliable handling of their digital assets. We aim to efficiently match orders at scale and quickly validate peer-to-peer transactions on the network.
Protocol Design
Sparrow is a secure token exchange based on smart contracts for peer-to-peer options trading. The protocol includes an (off-chain) order matching framework to provide optimal execution instances, coupled with a proprietary options pricing engine. Decentralized exchanges implemented with Ethereum smart contracts have mostly failed to generate significant volume due to inefficiencies in their design that impose high friction costs on market makers. In particular, these implementations place their order books on the blockchain, requiring market makers to spend gas each time they post, modify or cancel an order. In addition, maintaining an on-chain order book results in transactions that consume network bandwidth and bloat the blockchain without necessarily resulting in value transfer.
Nidus — The Ethereum Chain for Sparrow Options
Due to the nature of risk control and the needs of our users, Sparrow Exchange needs to be able to match orders quickly, even during periods when the Ethereum mainnet is extremely busy and manage settlement transparently and reliably. Sparrow Options will be implemented using Ethereum smart contracts and deployed onto an Ethereum Chain called Nidus. Nidus will be used exclusively for the deployment of Sparrow Options to maximize performance specific to the needs of our users — speed, transparency and reliability.
Nidus is a straight deployment of Ethereum chain on Parity node with minor modifications. This provides a guarantee that EVM of Nidus is exactly the same as that of Ethereum mainnet. While Nidus is Sparrow’s deployment of an Ethereum blockchain, nodes are able to freely connect to Nidus to verify its authority and authenticity, providing transparency to our settlement layer.
Nidus is a Proof of Authority (PoA) Ethereum blockchain.
Installable instances of Nidus are available as an open source client on our GitHub account.
https://github.com/sparrowex/nidus-docker
The stats of our testnet can be viewed at the following:
https://testnet-stats.sparrowexchange.com/
Fast Transactions
Nidus will have a short block time to allow for rapid processing on the settlement of smart contracts. This ensures speedy transactions even when other blockchains such as the Ethereum mainnet or Bitcoin network may be experiencing high traffic, allowing our customers to hedge against rapid price movements.
Orders are matched off-chain with automated market-making workflows orchestrated on Sparrow’s proprietary matching engine. This allows for flexible order-matching computations. The engine matches orders based on the parameters defined by the user and triggers machine-learning models to offer optimal prices for the contract. It also supports partially matches orders (when only a part of an order can be matched due to limited liquidity).
Once matched, the order gets published onto Nidus (a task within the matching service’s workflow) as a transaction in the form of a Smart Contract. Authoritative nodes then validate this transaction and secure it to the block as an immutable record. Each node within the network holds and maintains the latest copy of the ledger (replication and fault-tolerance). Smart contracts ensure that authors are verifiable, specifies control of the assets in exchange and authenticates all behaviour related to the functions defined in the document. Non-authoritative nodes are free to connect to Nidus to independently observe, validate and obtain a copy of the blockchain.
Maximum Transparency
Through Nidus, all deposits into Sparrow are published as SRC20 tokens, providing maximum transparency on the digital assets in our custody.
Pricing data would be published onto smart contracts on Nidus periodically. The data is published independently by Sparrow’s engine without knowledge on the options trading layer.
Options trading contracts are then settled fully on smart contracts published on Nidus based on the pricing data smart contracts. All settlement are done transparently on smart contracts, including but not limited to settling of options contract between the two parties, but also settlement of trading fees.
website: https://sparrowexchange.com/
submitted by maxibrainz to ICOAnalysis [link] [comments]

Comprehensive and honest user feedback from a Golem User

Hey everyone! Last week, a reporter approached us for words on Golem, and it was the first time a journalist actually also asked us to connect with a user for feedback. I told them to chat with PSVjasper99 and he provided super great feedback. He sent it to me and I shared it with our team, that appreciated it a lot. We consider your feedback extremely important, so posting here the report he prepared, and hoping to kick off a round of further feedback from all the Golem community. Thank you in advance!
__________________________________________________________
Experience Golem
Jasper V. 15-8-2018
I came across Golem around August of last year. A little background first:
I was starting my first semester at university that year and was already interested in the whole cryptocurrency world. At first, like many, I was full of scepticism. I mainly knew Bitcoin from being used on the darker side of transactions. Right as I started to learn about Golem, which was pretty much under pressure since their first major release Brass Beta was due summer 2017 and had not come out yet, I started my new study at the Technical University. One of my first major subjects required me to run tasks and complete FEM analyses on my university laptop (I study mechanical engineering and materials). These took days to complete. That was the point I bought my first Golem tokens. The use was to use these tokens if in the future, CAD renders and FEM analyses were to be implemented into Golem. Of course, the magic month December came and we all know what happened. I continued to hold on to my tokens and accumulated some more between March and now. Never sold nothing.
Of course this was at first all based around speculation. I first installed testnet in November (I think it was). What I first realised was that it was pretty spectacular the way it worked. The UI was clean and organized, instructions were clear and off rendering we went. This did not always go to plan however, because many of the tasks timed out. This was however, not a major problem since Golem allowed to use tGNT for testnet so we could attempt tasks as many times as we wanted. Updates came along every three weeks or so. The main files I rendered were demos that were also provided to test the capacity of the network. I had a success rate of about 25-35% estimated. A lot of tasks timed out or had a few ‘stripes’ not rendered correctly.
When Golem Brass Beta was launched about 4 months ago, I think the whole community was very excited. I only run Golem when I am actually using my PC. Running Golem whilst not using your PC would not only be very inefficient, but expensive too. It is not like mining. At the moment there is a clear deficit in requestors as opposed to providers. People should not expect when they launch Golem, that is computing the whole time (yet!). I have had days with tens of tasks with some good rewards, about 6 GNT per day, and days after which I had not had a single task ever since. Therefore, I often use Golems ability to change hardware allocation a lot. As I’m typing this, I offer 6 of my 8 threads to Golem. When I am gaming, I allocate 4 of my 8 threads and when I’m playing intensive games or VR, I allocate 2 of my 8 threads. My RAM and SSD space is always on full, since I have enough of that and it does not really impact performance that much.
I have now completed about 200 tasks across two nodes. Seeing how Golem actually worked was pretty cool and it has come a very long way since testnet and continues to improve. Golems UI is very smooth and I really like the vertical placement of the window. The application starts with a clear introduction, ability to protect your node with a password (access to wallets), and clearly tells you what to with port forwarding etc. This does not always go well, we see a huge surge of people on Reddit and the Golem Rocket Chat who have problems configuring their ports and connections. Thankfully, there are a lot of active team members and enthusiasts on the Rocket Chat who always find a solution. A major thing that has improved are the pop-up messages when hovering over items, and the understandeability of the whole application. Everything is well documented in the help document provided and the application works smooth without stuttering. Tips are provided as well for using the right settings when requesting a task on Golem, concerning task timeout, amount of subtasks etc. The price is basically determined via supply and demand, which is an advantage and could as well be a disadvantage. I hope Golem becomes large enough to not be influenced by big players making price agreements and who could, in theory, manipulate the market. However if this is not the case, this system ensures that the price paid for the computation is fair.
However, Golem certainly has its flaws. Not all of these were noticed by me, but I also talk to some enthusiasts and friends daily that always have Golem running. Most likely the team is working on these problems:
However, does this impact the implication of Golem in the real world? I have no idea. Golem currently only has Blender rendering POC on Mainnet and the target audience for requestors is not that huge. However, with the next release that should increase. Therefore, I don’t see an average Joe use Golem in the near future, but if more types of computation would be implemented, that could certainly change. If prices remain competitive, there is a huge (growing!) market available to Golem. Whether there is a hurdle for people to go to dApps from regular apps, probably. I think the majority of the projected users don’t quite yet see the added value of decentralization. Furthermore, I can imagine people disliking the fact to go to an exchange and exchange fiat for BTC or ETH, then to exchange for GNT, and then to transfer that GNT to Golems app. Golem is aware of this and I can see this (for many dApps) be the main factor contributing to the (not yet) mass adoption of dApps. Furthermore, the ever-changing value of these tokens is what might scare people off.
I am not a Blender artist and therefore I am not really able to use golem as a requestor. I can occasionally run some demo files. I have therefore not used any regular apps that provide the same service. Hopefully, this will change in the future, with the implementation of more use cases and the opportunity for the community to build on top of Golem.
So to conclude, will dApps ever replace regular apps? I see a few reasons as to why they might and a few reasons as to why they won’t. The main key is to improve the number of use cases, as well as the availability, keep the price competitive and the usability up. First, the issues above need to be solved for Golem specifically from my point of view. Some proper marketing could not hurt as well, trialling at universities and companies. If dApps are adopted by a few large(r) players (with the right use cases), domestic (mass) adoption could follow. However, I think it is hard to comment on this seen as the technology and development is still taking baby steps. I hope there is much more to come!
submitted by mariapaulafn to GolemProject [link] [comments]

Programming Bitcoin - YouTube RSK - Install a node with Docker Running Waves Node on testnet using Docker Improve English, Docker, Bitcoin and 5 Udemy Paid Courses For Free With Certificate Creating a Local Bitcoin Testnet / Regtest - Programming ...

I am testing some Bitcoin related code and in order to test it have installed bitcoin-testnet-box within a docker container. It's running fine, and, within the container I can execute commands and see the results. The Dockerfile is exposing port 19001, which I am mapping to port 49155 as the RPC port for one of the bitcond instances and I am trying to communicate with it using node-bitcoin. I ... Litecoin (LTC) Community Members are participating Testnet Installing the Docker and Doing the Rest October 8, 2020 Off By Steven Anderson . Assets need to prove themselves. Litecoin are doing all it takes to prove themselves. David Burkett, Litecoin MimbleWimble Lead Developer recently published that MWEB testnet is running. He stated that he is going to focus on different ways to make things ... "Bitcoin Core’s regression test mode (regtest mode) lets you instantly create a brand-new private block chain with the same basic rules as testnet — but one major difference: you choose when to create new blocks, so you have complete control over the environment." Docker is a software container technology. Welcome to the Chainlink documentation site. You'll find comprehensive guides and documentation to help you start working with Chainlink as quickly as possible, as well as support if you get stuck. In order to run a Chainlink node, it must be able to connect to an Ethereum client with an active websocket connection. T # bitcoin-testnet-box docker image # Ubuntu 14.04 LTS (Trusty Tahr) FROM ubuntu:14.04: LABEL maintainer= "Sean Lavine <[email protected]>" # add bitcoind from the official PPA # install bitcoind (from PPA) and make: RUN apt-get update && \ apt-get install --yes software-properties-common && \ add-apt-repository --yes ppa:bitcoin/bitcoin && \ apt-get update && \ apt-get install --yes bitcoind ...

[index] [12351] [6549] [47282] [40040] [18918] [46972] [6850] [24698] [19174] [40505]

Programming Bitcoin - YouTube

This video is unavailable. Watch Queue Queue. Watch Queue Queue UPDATE: a few specifics have changed, see below for up-to-date commands In this video we create a local bitcoin testnet within a docker container. Then we'll... The RSK network is the Smart Contract platform of Bitcoin, it offers the same capabilities of Ethereum, but the gas is paid with Bitcoin. When your applicati... UPDATE: a few specifics have changed, see below for up-to-date commands In this video we create a local bitcoin testnet within a docker container. Part 2. Using a simple bitcoind-ln node setup to mimic a Lightning network transaction on a private bitcoin blockchain (regtest). Github page - code and diag...

#