Restoring your standard wallet from seed – Bitcoin Electrum

TKEYSPACE — blockchain in your mobile

TKEYSPACE — blockchain in your mobile

https://preview.redd.it/w8o3bcvjrtx41.png?width=1400&format=png&auto=webp&s=840ac3872156215b30e708920edbef4583190654
Someone says that the blockchain in the phone is marketing. This is possible for most applications, but not for Tkeycoin. Today we will talk about how the blockchain works in the TkeySpace app.
Who else is not in the topic, TkeySpace is a financial application for decentralized and efficient management of various cryptocurrencies, based on a distributed architecture without using a client-server.
In simple words, it is a blockchain in the user’s mobile device that excludes hacking and hacker attacks, and all data is encrypted using modern cryptographic methods.
https://preview.redd.it/8uku6thlrtx41.png?width=1280&format=png&auto=webp&s=e1a610244da53100a5bc6b821ee5c799c6493ac4

Blockchain

Let’s start with the most important thing — the blockchain works on the principles of P2P networks, when there is no central server and each device is both a server and a client, such an organization allows you to maintain the network performance with any number and any combination of available nodes.
For example, there are 12 machines in the network, and anyone can contact anyone. As a client (resource consumer), each of these machines can send requests for the provision of some resources to other machines within this network and receive them. As a server, each machine must process requests from other machines in the network, send what was requested, and perform some auxiliary and administrative functions.
With traditional client-server systems, we can get a completely disabled social network, messenger, or another service, given that we rely on a centralized infrastructure — we have a very specific number of points of failure. If the main data center is damaged due to an earthquake or any other event, access to information will be slowed down or completely disabled.
With a P2P solution, the failure of one network member does not affect the network operation in any way. P2P networks can easily switch to offline mode when the channel is broken — in which it will exist completely independently and without any interaction.
Instead of storing information in a single central point, as traditional recording methods do, multiple copies of the same data are stored in different locations and on different devices on the network, such as computers or mobile devices.

https://i.redd.it/2c4sv7rnrtx41.gif
This means that even if one storage point is damaged or lost, multiple copies remain secure in other locations. Similarly, if one part of the information is changed without the consent of the rightful owners, there are many other copies where the information is correct, which makes the false record invalid.
The information recorded in the blockchain can take any form, whether it is a transfer of money, ownership, transaction, someone’s identity, an agreement between two parties, or even how much electricity a light bulb used.
However, this requires confirmation from multiple devices, such as nodes in the network. Once an agreement, otherwise known as consensus, is reached between these devices to store something on the blockchain — it can’t be challenged, deleted, or changed.
The technology also allows you to perform a truly huge amount of computing in a relatively short time, which even on supercomputers would require, depending on the complexity of the task, many years or even centuries of work. This performance is achieved because a certain global task is divided into a large number of blocks, which are simultaneously performed by hundreds of thousands of devices participating in the project.

P2P messaging and syncing in TkeySpace

TkeySpace is a node of the TKEY network and other supported networks. when you launch the app, your mobile node connects to an extensive network of supported blockchains, syncs with full nodes to validate transactions and incoming information between nodes, so the nodes organize a graph of connections between them.
You can always check the node information in the TkeySpace app in the ⚙ Settings Contact and peer info App Status;

https://preview.redd.it/co1k25kqrtx41.png?width=619&format=png&auto=webp&s=e443a436b11d797b475b00a467cd9609cac66b83
TkeySpace creates initiating connections to servers registered in the blockchain Protocol as the main ones, from these servers it gets the addresses of nodes to which it can join, in turn, the nodes to which the connection occurred share information about other nodes.

https://i.redd.it/m21pw88srtx41.gif
TkeySpace sends network messages to nodes from supported blockchains in the app to get up-to-date data from the network.
The Protocol uses data structures for communication between nodes, such as block propagation over the network, so before network messages are read, nodes check the “magic number”, check the first bytes, and determine the type of data structure. In the blockchain, the “magic number” is the network ID used to filter messages and block traffic from other p2p networks.
Magic numbers are used in computer science, both for files and protocols. They identify the type of file/data structure. A program that receives such a file/data structure can check the magic number and immediately find out the intended type of this file/data structure.
The first message that your node sends is called a Version Message. In response, the node waits for a Verack message to establish a connection between other peers. The exchange of such messages is called a “handshake”.

https://preview.redd.it/b6gh0hitrtx41.png?width=785&format=png&auto=webp&s=0101eaec6469fb53818486fa13da110f6a4a851d
After the “handshake” is set, TkeySpace will start connecting to other nodes in the network to determine the last block at the end of the required blockchain. At this point — nodes request information about blocks they know using GetBlock messages — in response, your node receives an inv (Inventory Message) from another node with the information that it has the information that was requested by the TkeySpace node.
In response to the received message, inv — TkeySpace sends a GetData message containing a list of blocks starting immediately after the last known hash.

https://preview.redd.it/lare5lsurtx41.png?width=768&format=png&auto=webp&s=da8d27110f406f715292b439051ca221fab47f77

Loading and storing blocks

After exchanging messages, the block information is loaded and transactions are uploaded to your node. To avoid storing tons of information and optimize hard disk space and data processing speed, we use RDBMS — PostgreSQL in full nodes (local computer wallet).
In the TkeySpace mobile app, we use SQLite, and validation takes place by uploading block headers through the Merkle Tree, using the bloom filter — this allows you to optimize the storage of your mobile device as much as possible.
The block header includes its hash, the hash of the previous block, transaction hashes, and additional service information.
Block headers in the Tkeycoin network=84 bytes due to the extension of parameters to support nChains, which will soon be launched in “combat” mode. The titles of the Bitcoin block, Dash, Litecoin=80 bytes.

https://preview.redd.it/uvv3qz7wrtx41.png?width=1230&format=png&auto=webp&s=5cf0cd8b6d099268f3d941aac322af05e781193c
And so, let’s continue — application nodes receive information from the blockchain by uploading block headers, all data is synchronized using the Merkle Tree, or rather your node receives and validates information from the Merkle root.
The hash tree was developed in 1979 by Ralph Merkle and named in his honor. The structure of the system has received this name also because it resembles a tree.
The Merkle tree is a complete binary tree with leaf vertexes containing hashes from data blocks, and inner vertexes containing hashes from adding values in child vertexes. The root node of the tree contains a hash from the entire data set, meaning the hash tree is a unidirectional hash function. The Merkle tree is used for the efficient storage of transactions in the cryptocurrency blockchain. It allows you to get a “fingerprint” of all transactions in the block, as well as effectively verify transactions.

https://preview.redd.it/3hmbthpxrtx41.png?width=677&format=png&auto=webp&s=cca3d54c585747e0431c6c4de6eec7ff7e3b2f4d
Hash trees have an advantage over hash chains or hash functions. When using hash trees, it is much less expensive to prove that a certain block of data belongs to a set. Since different blocks are often independent data, such as transactions or parts of files, we are interested in being able to check only one block without recalculating the hashes for the other nodes in the tree.
https://i.redd.it/f7o3dh7zrtx41.gif
The Merkle Tree scheme allows you to check whether the hash value of a particular transaction is included in Merkle Root, without having all the other transactions in the block. So by having the transaction, block header, and Merkle Branch for that transaction requested from the full node, the digital wallet can make sure that the transaction was confirmed in a specific block.

https://i.redd.it/88sz13w0stx41.gif
The Merkle tree, which is used to prove that a transaction is included in a block, is also very well scaled. Because each new “layer” added to the tree doubles the total number of “leaves” it can represent. You don’t need a deep tree to compactly prove transaction inclusion, even among blocks with millions of transactions.

Statistical constants and nChains

To support the Tkeycoin cryptocurrency, the TkeySpace application uses additional statistical constants to prevent serialization of Merkle tree hashes, which provides an additional layer of security.
Also, for Tkeycoin, support for multi-chains (nChains) is already included in the TkeySpace app, which will allow you to use the app in the future with most of the features of the TKEY Protocol, including instant transactions.

The Bloom Filter

An additional level of privacy is provided by the bloom filter — which is a probabilistic data structure that allows you to check whether an element belongs to a set.

https://preview.redd.it/7ejkvi82stx41.png?width=374&format=png&auto=webp&s=ed75cd056949fc3a2bcf48b4d7ea78d3dc6d81f3
The bloom filter looks for whether a particular transaction is linked to Alice, not whether Alice has a specific cryptocurrency. In this way, transactions and received IDs are analyzed through a bloom filter. When “Alice wants to know about transaction X”, an ID is requested for transaction X, which is compared with the filled segments in her bloom filter. If “Yes” is received, the node can get the information and verify the transaction.

https://preview.redd.it/gjpsbss3stx41.png?width=1093&format=png&auto=webp&s=4cdcbc827849d13b7d6f0b7e7ba52e65ddc03a82

HD support

The multi-currency wallet TkeySpace is based on HD (or hierarchical determinism), a privacy-oriented method for generating and managing addresses. Each wallet address is generated from an xPub wallet (or extended public key). The app is completely anonymous — and individual address is generated for each transaction to accept a particular cryptocurrency. Even for low-level programming, using the same address is negative for the system, not to mention your privacy. We recommend that you always use a new address for transactions to ensure the necessary level of privacy and security.
The EXT_PUBLIC_KEY and EXT_SECRET_KEY values for DASH, Bitcoin, and Litecoin are completely identical. Tkeycoin uses its values, as well as other methods for storing transactions and blocks (RDBMS), and of course — nChains.

Secret key

Wallets in the blockchain have public and private keys.
https://preview.redd.it/br9kk8n5stx41.png?width=840&format=png&auto=webp&s=a36e4c619451735469a9cff57654d322467e4fba
Centralized applications usually store users’ private keys on their servers, which makes users’ funds vulnerable to hacker attacks or theft.
A private key is a special combination of characters that provides access to cryptocurrencies stored on the account. Only a person who knows the key can move and spend digital assets.
TkeySpace — stores the encrypted key only on the user’s device and in encrypted form. The encrypted key is displayed as a mnemonic phrase (backup phrase), which is very convenient for users. Unlike complex cryptographic ciphers, the phrase is easy to save or write. A backup keyword provides the maximum level of security.
A mnemonic phrase is 12 or 24 words that are generated using random number entropy. If a phrase consists of 12 words, then the number of possible combinations is 204⁸¹² or 21¹³² — the phrase will have 132 security bits. To restore the wallet, you must enter the mnemonic phrase in strict order, as it was presented after generation.

Result

Now we understand that your application TkeySpace is a node of the blockchain that communicates with other nodes using p2p messages, stores block headers and validate information using the Merkle Tree, verifies transactions, filters information using the bloom filter, and operates completely in a decentralized model. The application code contains all the necessary blockchain settings for communicating with the network, the so-called chain parameters.
TkeySpace is a new generation mobile app. A completely new level of security, easy user-friendly interfaces and all the necessary features that are required to work with cryptocurrency.
submitted by tkeycoin to Tkeycoin_Official [link] [comments]

Notes from Ethereum Core Devs Meeting #31 [1/12/18]

The next core dev meeting will be this Friday, January 26, 2018. The agenda and live stream link are located here.

Ethereum Core Devs Meeting 31 Notes

Meeting Date/Time: Friday 01/12/18 at 14:00 UTC

Meeting Duration: 1.5 hours

GitHub Agenda Page

Audio/Video of the meeting

Reddit thread

Agenda

  1. Testing Updates.
  2. Yellow paper update.
  3. EWASM update + update on the following related EIPs. a. EVM 2.0 - https://github.com/ethereum/EIPs/issues/48 b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - https://github.com/ethereum/EIPs/issues/174 c. Subroutines and Static Jumps for the EVM - https://github.com/ethereum/EIPs/issues/615
  4. Stateless client development.
  5. Add ECADD and ECMUL precompiles for secp256k1 - https://github.com/ethereum/EIPs/issues/603 [See this blog post for context].
  6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).
  7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.
  8. Fork release management/Constantinople.
  9. Client updates.
  10. Other non-agenda issues.

Notes

Video starts at [4:36].

[4:56] 1. Testing Updates

No updates.

[5:27] 2. Yellow paper update.

Gavin put the Yellow Paper under the Creative Commons Free Culture License CC-BY-SA. Yoichi and Nick Savers have been making progress handling the Yellow Paper PRs. There is still the somewhat unresolved issue of what should define the "formal standard" of Ethereum and should an update to the Yellow Paper or another specification be required for every new EIP. This can be discussed in more detail in future meetings when there is greater attendance.

[7:43] 3. EWASM update + update on the following related EIPs.

[7:55] General update

Ewasm contributors are currently meeting in person together in Lisbon. EWASM EIPs listed in the subpoints are not up to date and can be disregarded. People should use the github.com/EWASM/design repo. The design has been pretty much speced out in the last year. During the design phase there were 2 implementations done in parallel: Javascript and C++ (which can be integrated in cpp-ethereum and geth). Issues have been faced in building out EWASM including struggling with implementing synchronous code in Javascript/browser. Idea was to move to an asynchronous model. Currently there is not a full decision on using synchronous vs asynchronous, but we are leaning towards synchronous implementation in C++ to run a testnet in cpp-ethereum that can run pure Web Assembly contracts. Metering contract in Web Assembly is on the to-do list and doesn't rely on sync/async decision. Likely will take week to come to a decision on sync vs async. More technical discussion and a funny anecdote involving the asynchronous vs synchronous decision and the affects of the recent Spectre/Meltdown attacks start at [12:07].

[15:08] a. EVM 2.0 - https://github.com/ethereum/EIPs/issues/48

Martin Becze will be closing this EIP. It is outdated.

[15:28] b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - https://github.com/ethereum/EIPs/issues/174

This doesn't have to do with EWASM, it has to do with adding extra opcodes in the current EVM. It is an upgrade to EVM 1.0 which is not needed if we skip straight to EWASM.

[16:47] c. Subroutines and Static Jumps for the EVM - https://github.com/ethereum/EIPs/issues/615

Greg has been working with Seed (Gitter tag) who is writing an ELM formalization of the EIP. Greg says that there is no formal social process for deciding things like EVM 1.5 implementation so he is not sure if/when it would be implemented. Greg has been working on cleaning up the proposal for those who want to use it. Greg has some ideas around an EVM 3.0 that pulls everything together with transpilation that he hasn't started working on yet and is not sure if he will.

[20:14] 4. Stateless client development.

Piper left some comments about some development of a stateless client for sharding, but it is very early. Alexey had a blog post describing stateless clients he may re-approach later.

[21:46] 5. Add ECADD and ECMUL pre-compiles for secp256k1 - https://github.com/ethereum/EIPs/issues/603 [See this blog post for context].

This topic was brought up months ago with mixed commentary. Christian R. says that ECADD and ECMUL were never intended to be used for general purpose cryptography, but rather it was suppose to be used in conjunction with the pairing pre-compiles for a specific curve that is pairing friendly. Christian says that in the past it has been discussed that there must be a very compelling reason for adding a pre-compile to Ethereum. Silur mentioned that the Monero research team is working on a new ring signature (still unnamed) that can be viewed in the Monero repository. The EWASM team may run some tests to compare native running of the pre-compiles vs EWASM. Adding a new pre-compile would only give a constant speed-up or reduction in cost, but if we achieve the same thing in new virtual machine it will give us a constant speed-up for every conceivable routine and allows for building other schemes like Casper and TrueBit. This is easier with Web Assembly because we can use existing C code. For the moment it looks like focusing energy on adding these proposed pre-compiles would not be worth it compared to just waiting for the next VM (likely EWASM) which will allow far more speed-ups across all computational routines.

[37:00] 6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).

[Note: I tried my best to cover what was discussed here, but I am not an expert in Ethereum transactions. If you find a mistake please point it out to me. Thanks!] Agenda item brought up to get people's opinion on this topic. Currently in Ethereum there are transactions that are stuck in the mempool for a long time because of the way transaction ordering per account is handled. The nonce of a transaction must be greater than the previous mined transactions (or equal if you are trying to replace a transaction). For example you can't process transaction #27 before transaction #26 has been mined. Many of the stuck transactions are dependent on other transactions that pay a much smaller fee, but are not being mined. It seems people inadvertently send an initial transaction with too small of a fee and then more transactions at a higher nonce with a much higher fee that cannot be processed until the first small fee transaction is processed. Alexey wondered if this may pose an attack vector or if we would get a benefit from implementing "child pays for parent" like Bitcoin does. Peter explained even if you define the max amount of gas your transaction could potentially consume, there is no guarantee it will use that much and we won't know until the transaction is processed (the only guarantee is that 21,000 gas will be consumed - a plain ether transfer). The attack vector example would be someone pushing a transaction that truly consumes 3,000,000 gas and attach a transaction fee of 1 wei and then push another TX that claims to consume 3,000,000 gas but with a transaction fee of 1000gwei. From the outside it looks like I can both can be executed for profit from the miner's perspective, but in reality the 2nd transaction will be processed first and the 1st tx will be long running and indirectly punish the miner. Alexey was concerned about the mempool filling up and impact on clients due to the way nonces are handled. Peter clarified that transactions in the mempool in the go ethereum client only maintains the top 4,000 most expensive transactions. If your cheap transaction gets evicted, the expensive transactions you stacked on top of it get evicted as well because they are no longer executable due to the nonce.

[42:21] 7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.

A relay network in general is a group of peers and/or miners who use a peer list to quickly connect to a group of known peers before connecting to (or instead of connecting to) random peers using network discovery. Alexey conjectured that this may create a powerful ring of network players who can share transactions very quickly and hurt the little guys on the outside (hurting the idea of this being a mesh network of peers). Clarifications were made about the issues involving transaction propagation issues with nodes with high transaction throughput such as Infura and Bittrex. Clients suddenly stop pushing transactions or cannot keep up with the blockchain when they are pushing out so many transactions. Hudson will work towards exploring this issue more and connecting the people with the issues with the devs.

[49:45] 8. Fork release management/Constantinople.

Hudson will be working on writing up a starting plan to discuss potential release management issues. BitsBeTripping sent Hudson some good material about project management that he will review and bring to the next meeting. We need to start discussing Constantinople sooner rather than later.

[52:55] 9. Client updates.

10. Other non-agenda items

[1:05:42] Question: Will we see any scaling improvements from Constantinople?

Answer is no because it potentially includes the first steps of the Casper consensus protocol and some account abstraction EIPs, but both of those do not alleviate scaling issues. Sharding would alleviate some of the issues. We are currently mostly bound by database and processing speed due to the database. Short term there are a lot of client improvements that can be accomplished to improve disk I/O, but long term things like sharding will be necessary. The Eth Research site has a lot of interesting threads about sharding including merkle tree formats to be used and ideas around asynchronous accumulators

[1:09:57] Decision process for EIPs?

Needs to be improved. Hudson and others will work on updating EIP #1 and other improvements in Q1. Nick Savers has been added as an EIP editor. Yoichi has been added as an editor. Both are doing a great job.

Attendance

Alex Beregszaszi (EWASM/Solidity/ethereumJS), Alex Van de Sande (Mist/Ethereum Wallet), Alexey Akhunov (Turbo Geth), Ben Edgington (Consensys/Pegasys), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Daniel Ellison (Consensys/LLL), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Hugo de la Cruz (ethereumJS/EWASM), Jake Lang (EWASM), Jared Wasinger (ethereumJS/EWASM), Martin Becze (EWASM), Mikhail Kalinin (Harmony), Paweł Bylica (cpp-ethereum/EWASM), Péter Szilágyi (geth), Silur (ethereumJS / EWASM)
submitted by Souptacular to ethereum [link] [comments]

Decred Journal – September 2018

Note: you can read this on GitHub (link), Medium (link) or old Reddit (link).

Development

Final version 1.3.0 of the core software was released bringing all the enhancements reported last month to the rest of the community. The groundwork for SPV (simplified payment verification) is complete, another reduction of fees is being deployed, and performance stepped up once again with a 50% reduction in startup time, 20% increased sync speed and more than 3x faster peer delivery of block headers (a key update for SPV). Decrediton's integrations of SPV and Politeia are open for testing by experienced users. Read the full release notes and get the downloads on GitHub. As always, don't forget to verify signatures.
dcrd: completed several steps towards multipeer downloads, improved introduction to the software in the main README, continued porting cleanups and refactoring from upstream btcd.
Currently in review are initial release of smart fee estimator and a change to UTXO set semantics. The latter is a large and important change that provides simpler handling, and resolves various issues with the previous approach. A lot of testing and careful review is needed so help is welcome.
Educational series for new Decred developers by @matheusd added two episodes: 02 Simnet Setup shows how to automate simnet management with tmux and 03 Miner Reward Invalidation explains block validity rules.
Finally, a pull request template with a list of checks was added to help guide the contributors to dcrd.
dcrwallet: bugfixes and RPC improvements to support desktop and mobile wallets.
Developers are welcome to comment on this idea to derive stakepool keys from the HD wallet seed. This would eliminate the need to backup and restore redeem scripts, thus greatly improving wallet UX. (missed in July issue)
Decrediton: bugfixes, refactoring to make the sync process more robust, new loading animations, design polishing.
Politeia: multiple improvements to the CLI client (security conscious users with more funds at risk might prefer CLI) and security hardening. A feature to deprecate or timeout proposals was identified as necessary for initial release and the work started. A privacy enhancement to not leak metadata of ticket holders was merged.
Android: update from @collins: "Second test release for dcrandroid is out. Major bugs have been fixed since last test. Latest code from SPV sync has been integrated. Once again, bug reports are welcome and issues can be opened on GitHub". Ask in #dev room for the APK to join testing.
A new security page was added that allows one to validate addresses and to sign/verify messages, similar to Decrediton's Security Center. Work on translations is beginning.
Overall the app is quite stable and accepting more testers. Next milestone is getting the test app on the app store.
iOS: the app started accepting testers last week. @macsleven: "the test version of Decred Wallet for iOS is available, we have a link for installing the app but the builds currently require your UDID. Contact either @macsleven or @raedah with your UDID if you would like to help test.".
Nearest goal is to make the app crash free.
Both mobile apps received new design themes.
dcrdata: v3.0 was released for mainnet! Highlights: charts, "merged debits" view, agendas page, Insight API support, side chain tracking, Go 1.11 support with module builds, numerous backend improvements. Full release notes here. This release featured 9 contributors and development lead @chappjc noted: "This collaboration with @raedahgroup on our own block explorer and web API for @decredproject has been super productive.".
Up next is supporting dynamic page widths site wide and deploying new visual blocks home page.
Trezor: proof of concept implementation for Trezor Model T firmware is in the works (previous work was for Model One).
Ticket splitting: updated to use Go modules and added simnet support, several fixes.
docs: beginner's guide overhaul, multiple fixes and cleanups.
decred.org: added 3rd party wallets, removed inactive PoW pools and removed web wallet.
@Richard-Red is building a curated list of Decred-related GitHub repositories.
Welcome to new people contributing for the first time: @klebe, @s_ben, @victorguedes, and PrimeDominus!
Dev activity stats for September: 219 active PRs, 197 commits, 28.7k added and 18.8k deleted lines spread across 6 repositories. Contributions came from 4-10 developers per repository. (chart)

Network

Hashrate: started and ended the month around 75 PH/s, hitting a low of 60.5 and a new high of 110 PH/s. BeePool is again the leader with their share varying between 23-54%, followed by F2Pool 13-30%, Coinmine 4-6% and Luxor 3-5%. As in previous months, there were multiple spikes of unidentified hashrate.
Staking: 30-day average ticket price is 98 DCR (+2.4). The price varied between 95.7 and 101.9 DCR. Locked DCR amount was 3.86-3.96 million DCR, or 45.7-46.5% of the supply.
Nodes: there are 201 public listening nodes and 325 normal nodes per dcred.eu. Version distribution: 5% are v1.4.0(pre) dev builds (+3%), 30% on v1.3.0 (+25%), 42% on v1.2.0 (-20%), 15% on v1.1.2 (-7%), 6% on v1.1.0. More than 76% of nodes run v1.2.0 and higher and therefore support client filters. Data as of Oct 1.

ASICs

Obelisk posted two updates on their mailing list. 70% of Batch 1 units are shipped, an extensive user guide is available, Obelisk Scanner application was released that allows one to automatically update firmware. First firmware update was released and bumped SC1 hashrate by 10-20%, added new pools and fixed multiple bugs. Next update will focus on DCR1. It is worth a special mention that the firmware source code is now open! Let us hope more manufacturers will follow this example.
A few details about Whatsminer surfaced this month. The manufacturer is MicroBT, also known as Bitwei and commonly misspelled as Bitewei. Pangolinminer is a reseller, and the model name is Whatsminer D1.
Bitmain has finally entered Decred ASIC space with their Antminer DR3. Hash rate is 7.8 TH/s while pulling 1410 W, at the price of $673. These specs mean it has the best GH/W and GH/USD of currently sold miners until the Whatsminer or others come out, although its GH/USD of 11.6 already competes with Whatsminer's 10.5. Discussed on Reddit and bitcointalk, unboxing video here.

Integrations

Meet our 17th voting service provider: decredvoting.com. It is operated by @david, has 2% fee and supports ticket splitting. Reddit thread is here.
For a historical note, the first VSP to support ticket splitting was decredbrasil.com:
@matheusd started tests on testnet several months ago. I contacted him so we could integrate with the pool in June this year. We set up the machine in July and bought the first split ticket on mainnet, using the decredbrasil pool, on July 19. It was voted on July 30. After this first vote on mainnet, we opened the tests to selected users (with more technical background) on the pool. In August we opened the tests to everyone, and would call people who want to join to the #ticket_splitting channel, or to our own Slack (in Portuguese, so mostly Brazilian users). We have 28 split tickets already voted, and 16 are live. So little more than 40 split tickets total were bought on decredbrasil pool. (@girino in #pos-voting)
KuCoin exchange listed DCBTC and DCETH pairs. To celebrate their anniversary they had a 99% trading fees discount on DCR pairs for 2 weeks.
Three more wallets integrated Decred in September:
ChangeNow announced Decred addition to their Android app that allows accountless swaps between 150+ assets.
Coinbase launched informational asset pages for top 50 coins by market cap, including Decred. First the pages started showing in the Coinbase app for a small group of testers, and later the web price dashboard went live.

Adoption

The birth of a Brazilian girl was registered on the Decred blockchain using OriginalMy, a blockchain proof of authenticity services provider. Read the full story in Portuguese and in English.

Marketing

Advertising report for September is ready. Next month the graphics for all the ads will be changing.
Marketing might seem quiet right now, but a ton is actually going on behind the scenes to put the right foundation in place for the future. Discovery data are being analyzed to generate a positioning strategy, as well as a messaging hierarchy that can guide how to talk about Decred. This will all be agreed upon via consensus of the community in the work channels, and materials will be distributed.
Next, work is being done to identify the right PR partner to help with media relations, media training, and coordination at events. While all of this is coming up to speed, we believe the website needs a refresher reflecting the soon to be agreed upon messaging, plus a more intuitive architecture to make it easier to navigate. (@Dustorf)

Events

Attended:
Upcoming:
We'll begin shortly reviewing conferences and events planned for the first half of 2019. Highlights are sure to include The North American Bitcoin Conference in Miami (Jan 16-18) and Consensus in NYC (May 14-16). If you have suggestions of events or conferences Decred should attend, please share them in #event_planning. In 2019, we would like to expand our presence in Europe, Asia, and South America, and we're looking for community members to help identify and staff those events. (@Dustorf)

Media

August issue of Decred Journal was translated to Russian. Many thanks to @DZ!
Rency cryptocurrency ratings published a report on Decred and incorporated a lot of feedback from the community on Reddit.
September issue of Chinese CCID ratings was published (snapshot), Decred is still at the bottom.
Videos:
Featured articles:
Articles:

Community Discussions

Community stats:
Comm systems news: Several work channels were migrated to Matrix, #writers_room is finally bridged.
Highlights:
Twitter: why decentralized governance and funding are necessary for network survival and the power of controlling the narrative; learning about governance more broadly by watching its evolution in cryptocurrency space, importance of community consensus and communications infrastructure.
Reddit: yet another strong pitch by @solar; question about buyer protections; dcrtime internals; a proposal to sponsor hoodies in the University of Cape Town; Lightning Network support for altcoins.
Chats: skills to operate a stakepool; voting details: 2 of 3 votes can approve a block, what votes really approve are regular tx, etc; scriptless script atomic swaps using Schnorr adaptor signatures; dev dashboard, choosing work, people do best when working on what interests them most; opportunities for governments and enterprise for anchoring legal data to blockchain; terminology: DAO vs DAE; human-friendly payments, sharing xpub vs payment protocols; funding btcsuite development; Politeia vote types: approval vote, sentiment vote and a defund vote, also linking proposals and financial statements; algo trading and programming languages (yes, on #trading!); alternative implementation, C/C++/Go/Rust; HFTs, algo trading, fake volume and slippage; offline wallets, usb/write-only media/optical scanners vs auditing traffic between dcrd and dcrwallet; Proof of Activity did not inspire Decred but spurred Decred to get moving, Wikipedia page hurdles; how stakeholders could veto blocks; how many votes are needed to approve a proposal; why Decrediton uses Electron; CVE-2018-17144 and over-dependence on single Bitcoin implementation, btcsuite, fuzz testing; tracking proposal progress after voting and funding; why the wallet does not store the seed at all; power connectors, electricity, wiring and fire safety; reasonable spendings from project fund; ways to measure sync progress better than block height; using Politeia without email address; concurrency in Go, locks vs channels.
#support is not often mentioned, but it must be noted that every day on this channel people get high quality support. (@bee: To my surprise, even those poor souls running Windows 10. My greatest respect to the support team!)

Markets

In September DCR was trading in the range of USD 34-45 / BTC 0.0054-0.0063. On Sep 6, DCR revisited the bottom of USD 34 / BTC 0.0054 when BTC quickly dropped from USD 7,300 to 6,400. On Sep 14, a small price rise coincided with both the start of KuCoin trading and hashrate spike to 104 PH/s. Looking at coinmarketcap charts, the trading volume is a bit lower than in July and August.
As of Oct 4, Decred is #18 by the number of daily transactions with 3,200 tx, and #9 by the USD value of daily issuance with $230k. (source: onchainfx)
Interesting observation by @ImacallyouJawdy: while we sit at 2018 price lows the amount locked in tickets is testing 2018 high.

Relevant External

ASIC for Lyra2REv2 was spotted on the web. Vertcoin team is preparing a new PoW algorithm. This would be the 3rd fork after two previous forks to change the algorithm in 2014 and 2015.
A report titled The Positive Externalities of Bitcoin Mining discusses the benefits of PoW mining that are often overlooked by the critics of its energy use.
A Brief Study of Cryptonetwork Forks by Alex Evans of Placeholder studies the behavior of users, developers and miners after the fork, and makes the cases that it is hard for child chains to attract users and developers from their parent chains.
New research on private atomic swaps: the paper "Anonymous Atomic Swaps Using Homomorphic Hashing" attempts to break the public link between two transactions. (bitcointalk, decred)
On Sep 18 Poloniex announced delisting of 8 more assets. That day they took a 12-80% dive showing their dependence on this one exchange.
Circle introduced USDC markets on Poloniex: "USDC is a fully collateralized US dollar stablecoin using the ERC-20 standard that provides detailed financial and operational transparency, operates within the regulated framework of US money transmission laws, and is reinforced by established banking partners and auditors.".
Coinbase announced new asset listing process and is accepting submissions on their listing portal. (decred)
The New York State Office of the Attorney General posted a study of 13 exchanges that contains many insights.
A critical vulnerability was discovered and fixed in Bitcoin Core. Few days later a full disclosure was posted revealing the severity of the bug. In a bitcointalk thread btcd was called 'amateur' despite not being vulnerable, and some Core developers voiced their concerns about multiple implementations. The Bitcoin Unlimited developer who found the bug shared his perspective in a blog post. Decred's vision so far is that more full node implementations is a strength, just like for any Internet protocol.

About This Issue

This is the 6th issue of Decred Journal. It is mirrored on GitHub, Medium and Reddit. Past issues are available here.
Most information from third parties is relayed directly from source after a minimal sanity check. The authors of Decred Journal have no ability to verify all claims. Please beware of scams and do your own research.
Feedback is appreciated: please comment on Reddit, GitHub or #writers_room on Matrix or Slack.
Contributions are also welcome: some areas are adding content, pre-release review or translations to other languages.
Credits (Slack names, alphabetical order): bee, Dustorf, jz, Haon, oregonisaac, raedah and Richard-Red.
submitted by jet_user to decred [link] [comments]

Introduction, Resources, and FAQ

Official Resources

 
 

Community Resources

 
 

Social Media

 
 

General FAQ

 

What is Ardor?

Ardor is a scalable blockchain-as-a-service platform with a wide variety of built-in features. It consists of a single parent blockchain, also called Ardor, and a set of child blockchains. The parent chain provides security for the child chains, and the child chains provide all of the features for users.

What is Ardor not?

Ardor is not:
  • Just a white paper;
  • An ERC20 token; or,
  • A prototype.
Ardor is already running in production and all of its features are available to users and developers.

What can Ardor do?

Ardor's child chains can support any or all of the following features:
  • The Coin Exchange, where users can trade ARDR and child chain coins.
  • The Asset Exchange, where users can issue and trade assets.
  • The Monetary System, where users can issue tokens with a number of customizable properties.
  • The Voting System, where users can create and participate in polls.
  • The Data Cloud, where users can store the hash of a file permanently on the blockchain, and optionally, store the file itself in archival nodes.
  • The Marketplace, a decentralized platform for buying or selling goods and services.
  • Coin Shuffling, a way to obscure an account's transaction history to grant a measure of privacy.
  • The Messaging System, which allows users to send one another plaintext or encrypted messages.
  • The Alias System, a key-value store for arbitrary data.
  • Phased Transactions, which allow users to specify the conditions under which a transaction is valid. Examples include m-of-n multisig, hash- and time-locks, and votes by asset or currency holders, among many other options.
There are also many advanced features built into these systems:
  • Pay dividends to your asset holders.
  • Issue a Monetary System token to conduct an ICO, create a currency for your Dapp, designate membership in an organization, or distribute a voucher to your customers, among many other uses.
  • Combine phasing conditions with AND, OR, and NOT operators to make simple smart contracts.
  • Mark accounts with a special property, then issue an asset that only those accounts can trade.
  • Create an account that can only issue transactions approved by a specific set of other accounts.
There are far too many possibilities to list here. If you have an idea for a project that you'd like to launch on a blockchain, post about it on this sub! Chances are that there is a way to develop it quickly and securely on Ardor, and people here will be happy to help you figure out how to do it.

Why are most of those links to the Nxt wiki? I thought we were talking about Ardor.

Ardor was created by the lead developers of Nxt using much of the same source code. They originally called it Nxt 2.0, though the two platforms are completely independent and have separate blockchains. Ardor's first child chain, Ignis, supports all of Nxt's features, plus a few new ones.

There are lots of blockchain platforms out there. What makes Ardor special?

Ardor's unique parent-chain/child-chain architecture has a number of advantages compared to other blockchain platforms:
  • It scales well. Transactions involving only child chain coins do not need to be stored forever--they can be pruned away without reducing the security of the blockchain. This keeps blockchain bloat to a minimum.
  • It is modular. A large volume of transactions on one child chain does not prevent transactions on other child chains from being confirmed. Also, the transaction histories of child chains can be stored in separate sets of archival nodes, if desired. No archival node has to store everything.
  • It is flexible. Creators of child chains can pick and choose which features they would like to offer to suit their needs. They also have the option to subsidize activity on their chains, allowing users to transact without paying fees.
  • It is cohesive. Assets in the Asset Exchange, tokens in the Monetary System, and goods in the Marketplace can be listed for sale on multiple child chains, with prices denominated in each child chain's coin. A phased transaction issued on one child chain can be approved by a transaction on another child chain. And so on.

What is Ignis?

Ignis is the first child chain on Ardor and the only one to support all available features. Many projects do not need their own blockchains; these are better suited to Ignis than to a separate child chain. For some examples of what you can do with Ignis, see this article.
 

Technical FAQ

 

Why do you claim that Ardor scales so well?

On single-chain proof-of-stake platforms like Nxt, the blockchain's native coin serves two purposes: to forge, which helps secure the network; and to conduct business using the platform's features.
When a new node joins the network, it must be able to trustlessly verify that each block was forged by an eligible account. This means that it must know the forging account's balance at the time the block was forged. On Nxt, the only way to do this is to replay every transaction since the genesis block to determine the current state of account balances. All transactions must therefore be stored on the blockchain permanently.
On Ardor, these two roles--forging and utility--have been delegated to separate coins. Only the transaction history of the forging coin, ARDR, must be stored permanently, since only transactions involving ARDR affect forgers' eligibility to forge. Transactions involving only child chain coins can be safely removed without introducing any trust between new nodes joining the network (or re-syncing the blockchain) and existing nodes. This pruning mechanism dramatically reduces blockchain bloat.

Ok, so Ardor's design reduces blockchain bloat. By how much?

Up to a factor of 100. This is the number of child chain transactions that can be bundled together, hashed, and committed to the parent chain in a single ChildBlock transaction. Note that ChildBlock transactions store only the hashes of their corresponding child chain blocks.
By the way, a parent chain block can hold up to ten ChildBlock transactions. Each parent chain block therefore has a capacity of up to 1000 child chain transactions but only takes up ten transactions' worth of space on the blockchain.

Can I still see child chain transactions after they have been pruned away?

Yes, as long as there are archival nodes on that child chain. You can request the body of a child chain block from an archival node, hash it, and verify that the hash you compute matches the one stored on the blockchain. This way, you know that the archival node hasn't tampered with the contents of the block since the network validated it.

What's so special about pruning? Bitcoin and Ethereum are prunable too.

(This isn't a frequently asked question, but it should be.)
Pruning is a big deal for Ardor because Ardor is proof-of-stake. It is pretty straightforward to prune a proof-of-work blockchain, since the proof of work itself is stored in the block header, along with the hash of the body of the block. In that case, a new node only needs to validate block headers to verify that the network came to a consensus about the validity of each block at the time that it was mined.
Proof-of-stake blockchains are a different story. It is imperative to store enough of the transaction history to verify that the forger of each block had an adequate balance to be eligible to forge. This is where Ardor shines: it stores just enough information to allow nodes to validate the blockchain, but it doesn't store any of the actual business conducted on the platform, since that would needlessly bloat it.

What about computational scaling? Doesn't each node still validate every transaction?

Yes, each node validates every transaction. Ardor thus scales quite well in terms of storage, but not much better than other blockchains in terms of the computational burden on each node.
Ardor's core developers have said that they plan to remedy the computational bottleneck by delegating child chain transaction processing to separate subnets of the Ardor network. This would mean most nodes could ignore transactions from most child chains. The developers have not yet announced any details about this design, though.

Vitalik Buterin says that blockchains aren't scalable unless they're sharded.

He has a good point. But consider that Ardor's design has already achieved a partitioning of the data stored on the blockchain, since each child chain's transaction history can be stored in a separate set of archival nodes. If Ardor's developers can successfully partition the computational power required to validate transactions--by pushing transaction validation to dedicated subnets, for example--then they will have achieved a design rather similar to the "basic sharded blockchain" that Vitalik describes in the Ethereum Sharding FAQ.

What are bundlers?

Bundlers are nodes that group together transactions from a particular child chain, hash them, and commit their hash to the parent chain as a ChildBlock transaction. Bundlers collect fees denominated in the child chain coin and pay fees to forgers denominated in ARDR.

How do I run a bundler?

You can find information about how to configure a bundler on the wiki. For a detailed description of what the different configurable paramaters mean, see this article.

I only see one blockchain on the block explorein the source code. Where are the child chains?

Conceptually, it is quite appropriate to think of Ardor's child chains as multiple, independent blockchains. At a lower level, though, each child chain reduces to the following:
  • A sequence of ChildBlock transactions on the parent chain;
  • A set of account balances for the child chain coin; and,
  • Some additional data for other chain-specific features, e.g., the aliases that have been registered on the chain.
Basically, the child chains have their own data and their own histories (which can be stored in separate archival nodes, if desired), but they share forgers, nodes, the wallet, and most other aspects of a blockchain in common. You could say that they exist "within" the parent chain, rather than "alongside" the parent chain, in all aspects other than their historical data.

How do I develop a Dapp on Ardor?

You basically have two options: build your Dapp on an existing child chain, like Ignis; or create your own child chain. If you're not sure whether you need your own child chain, chances are you don't. Still, you can find some factors to consider here.
The philosophy behind Ardor differs a bit from the philosophy behind smart contract platforms. To see why, consider that smart contracts give developers a tremendous degree of flexibility, along with a thorny trilemma: it is extraordinarily difficult to write code that is simultaneously complex, immutable, and bug-free (secure).
Solutions to this trilemma include the following:
  1. Write simple, bug-free code and commit it immutably to the blockchain.
  2. Write complex code that probably contains bugs, but don't make it strictly immutable. Allow yourself to redirect your contract's responsibilities to a new, patched version if you discover a bug. You might also include a kill-switch to stop the bleeding in the case of a hack.
  3. Write complex, immutable code and pray that you haven't made any multimillion dollar mistakes. Not recommended.
Option #2 typically involves reintroducing a trusted third party--the developer--so why commit that code to the blockchain in the first place? You might as well run most of the code off-chain, and only use the blockchain for the parts of your Dapp that truly need to be trustless.
This is the approach that Ardor takes, anyway, and it is quite similar to following option #1 on a smart contract platform. The main difference is that you don't need to write the smart contracts yourself: Ardor's extensive API essentially defines a set of building blocks for you to combine in interesting ways to build your Dapp. Think of the blockchain as your program's database, and think of Ardor's API as a rich set of predefined operations on that database.
Speaking of the API, you can find documentation for it on the wiki.
 

Business FAQ

 

How do I commission a child chain on Ardor?

Contact Jelurida.

Why do I need to work with Jelurida? I thought this was decentralized.

Currently, the only way to create a new child chain is to work with Jelurida. In the future, the core developers plan to add a mechanism for users to create their own child chains automatically. They have not yet published a timeline for this feature.

Where can I go to learn more about how my business might use Ardor?

Consider contacting the Ardor and Nxt Group. One of their goals is to help foster a community of businesses that are using or interested in using Ardor and Nxt.
Also consider posting in this sub! Many of us are eager to hear about new applications of the platform and will be happy to answer your questions.
 

Investor FAQ

 

What gives ARDR value?

Demand for ARDR comes primarily from bundlers. Each child chain transaction type has a minimum fee, denominated in ARDR. The sum of these fees over all transactions in a given ChildBlock is the minimum amount of ARDR a bundler must pay a forger to include the block in the blockchain.
As the volume of transactions on a child chain grows, bundlers on that child chain must accumulate more ARDR in order to pay forgers' fees. Moreover, this effect is additive across all child chains. In other words, the more popular any of Ardor's child chains become, the greater the demand for ARDR.

Why should I trust the team?

Ardor's core developers were also the main contributers to Nxt over the last several years. Nxt has been running in production for four years without a major security incident, and it still offers more functionality than its many imitators. The team has demonstrated that they can set ambitious but realistic goals and actually deliver on them, which is more than many teams can claim.
submitted by segfaultsteve to Ardor [link] [comments]

Bitcoind.exe in Armory crashes

Hi All,
Running Windows 8 64-bit, Armory v0.9.32-beta-85959b20d8, Core Bitcoin v0.10.2.
Armory loads up just fine, and using Process Explorer (Sysinternals tool), I am able to see ArmoryQT.exe as the parent thread with bitcoind.exe as one child thread (which has a conhost.exe child thread) and another child thread for guardian.exe (which also has a conhost.exe child thread) This is how it looks:
Now, as soon as I load Armory, the wallet consistency check passes and then it's stuck in "Initializing Bitcoin Engine" with no progress at all (just the rotating grey/green wheel) - then about 15 minutes later, I'll notice that the bitcoind.exe process and its child disappear. Guardian.exe is still running though.
Now, when I disabled Armory from controlling bitcoin, I can load Bitcoin-Qt.exe no problems, it syncs with the blockchain no issues, and Armory will phase in and out of being connected. Which is totally weird....like the rpc connection somehow gets lost and reconnects at random times. But, even when Armory shows it's connected, and Bitcoin-Qt.exe shows that's it's fully synced with the blockchain, it doesn't update any transaction info in Armory at all. Now, I can see in the blockchain that my last few transactions already have 38 confirmations, but Armory still shows that there are 0 confirmations and that the transaction hasn't hit the blockchain yet. Obviously this isn't true.
So, I turn to y'all for some help and guidance....I've scoured their forums, and I've tried all the suggestions, so I'm turning now to the trusted reddit community for some insight and help.
Any ideas?! I mean, I could probably just backup my wallet, uninstall both armory and bitcoin, then do a clean install, then wait a month for the blockchain to sync, but I'd prefer to have to avoid this if that's AT ALL possible.
Also, not sure if this is relevant, but even though the blockchain is synced, shortly before bitcoind.exe goes out of commission (only when run through Armory, bitcoin never crashes when loaded separately) the cpu % for that process spikes to about 45-70% for a few minutes, which sounds like it's processing headers and what not, and then just poops out.
I have a quad-core AMD A6-3600 - not the BEST but not the worst either....
Ok, help....please....
EDIT: formatting
submitted by shayaknyc to Bitcoin [link] [comments]

Digibyte Core Wallet Install Guide (It doesn't take 4 years) Increase slow download and sync of bitcoin blockchain on Mac How To Quickly Sync A Wallet with Bootstrap (Litecoin/Bitcoin) DIGIBYTE CORE WALLET! INCREASE SYNC SPEED! Bitcoin Core Wallet sync 100% result

Bitcoin Core 0.13.0. It is recommended to use this for sensitive information such as wallet passphrases, as command-line arguments can usually be read from the process table by any user on the system. Bitcoin Core and Bitcoin qt are two different wallets. If Bitcoin qt says there's an update then you prob just don't have the latest version. It doesn't matter tho cuz ur changing wallets anyways. You must let the wallet sync. Importing private keys are a little different for each wallet, but it's pretty straight forward. You just need to take ... 2 factor authentication wallet fees: Your wallet is a 2fa wallet and you are paying the fee associated with that wallet. You can find out what your wallet type is by looking at the Electrum window title. Does it say 2fa or 2 factor authentication there? If yes then the fees are for the services of the co-signing company Trusted Coin. Trusted Coin co-signs your transactions if you provide it ... Bitcoin Core 0.17.0. If the following options are not in a section, they will only apply to mainnet: addnode=, connect=, port=, bind=, rpcport=, rpcbind= and wallet=.The options to choose a network (regtest= and testnet=) must be specified outside of sections.‘label’ and ‘account’ APIs for wallet Hi I bought some fraction of a bitcoin back in 2015 and I want to sell, I tried sending it to my local bitcoins wallet from my out of sync core....

[index] [1295] [40515] [34722] [33511] [7533] [1174] [13822] [36558] [13749] [21436]

Digibyte Core Wallet Install Guide (It doesn't take 4 years)

How To Buy Bitcoin Cash [Quick And Easy Guide] - Duration: 7 ... (Fix #3 of 3 for Sync Issues) For Divi Desktop - Duration: 4:52. TheVoice Recommended for you. 4:52. 15 Air Conditioner Maintenance ... Find out why Close. Increase slow download and sync of bitcoin blockchain on Mac Daniel's Tutorials ... Getting your Private Keys from the Bitcoin Core wallet - Duration: 5:11. Bitcoin Daytrader ... Find out why Close. Bitcoin Core Wallet sync 100% result Sabah RcDrone. Loading... Unsubscribe from Sabah RcDrone? Cancel Unsubscribe. Working... Subscribe Subscribed Unsubscribe 250. Loading ... Having the longest Blockchain is great but it doesn't make it easy for people to first setup their Core Wallets! Don't worry though I've got a very simple and easy to sync your wallet fast. I ... 1967 Shelby GT500 Barn Find and Appraisal That Buyer Uses To Pay Widow - Price Revealed - Duration: 22:15. Jerry Heasley Recommended for you

#