Using Oracle Wallet Manager

I got pwned: a cautionary tale

As background, I've been playing with a Digital Ocean instance for the past few months - getting DNS and Let's Encrypt set up, setting up nginx as a reverse proxy, and now setting up nextcloud.
Last week, I was pretty pleased with myself. I installed the Calendar plug-in and started syncing my calendar - independently of Google! Today I started getting from 500 errors popping up on my phone. I didn't think much of it - I figured something was weird with nextcloud, I had overlooked something, and I could figure it out when I got home. Unfortunately, I just found this in my database.
centos:~/src/nextcloud-config$ mysql -h 172.20.0.1 -P 3306 -u nextcloud -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 10 Server version: 10.4.8-MariaDB-1:10.4.8+maria~bionic mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | nextcloud | +--------------------+ 2 rows in set (0.00 sec) MariaDB [(none)]> USE nextcloud; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [nextcloud]> SHOW TABLES; +---------------------+ | Tables_in_nextcloud | +---------------------+ | WARNING | +---------------------+ 1 row in set (0.00 sec) MariaDB [nextcloud]> SELECT * FROM WARNING; +----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+------------------+ | id | warning | Bitcoin_Address | Email | +----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+------------------+ | 1 | To recover your lost Database and avoid leaking it: Send us 0.06 Bitcoin (BTC) to our Bitcoin address ieUD and contact us by Email with your Server IP or Domain name and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your Database is downloaded and backed up on our servers. Backups that we have right now: nextcloud . If we dont receive your payment in the next 10 Days, we will make your database public or use them otherwise. | ieUD | [email protected] | +----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+------------------+ 1 row in set (0.01 sec) 
I have no intention of paying the ransom. 1) They have a few calendar events and some example documents from me. 2) Even if I pay, there's no guarantee they would send me a copy of the data.
All things equal, I feel lucky this happened so soon ... I only lost like 3 calendar events, all of which I can recreate from memory. I guess I need to back up and re-evaluate my security assumptions (notably to make backups early).
In the hopes of detecting the root cause, here is my (redacted) nginx access.log from today: https://pastebin.com/JQ64ctcG Naturally my judgment is in question, ha ha, but I did see a few suspicious-looking entries (some suspicious-looking stuff in there (github.com/robertdavidgraham/masscan, some calls to /login and /wp-admin, some requests that look like binary data...). If anyone could help me understand how my server was compromised, it would be much appreciated.
Thanks all ... remember that weird shit like "entire Internet scanner" exists ... :-(
edit: Thank you all so much. Based on the ideas from the comments, the prevailing hypothesis about the root cause is:
- no firewall was active, either through the host admin panel (Digital Ocean) or in Linux itself
- In the course of troubleshooting, I had exposed port 3306 on my database container to anyone with access to my droplet, i.e. the whole Internet (via DNS). My intention was to expose the port only to other processes on my droplet, but I unintentionally exposed it publicly.
- I had an extremely weak root password
- With the "masscan" port-scanning tool, the vulnerability was detected by an attacker quite quickly, like within a week of me having this configuration active. Then a simple dictionary attack would have let them into root in my mariadb container.
Well ... knowledge is half the battle. Thanks again everyone ... I hope this thread will help a future lost soul who finds themselves in a similar circumstance.
submitted by silvertoothpaste to NextCloud [link] [comments]

February report on ConsenSys spoke developments

We've got a full report on what the spokes at ConsenSys have been up to. Check out more here.
EDIT: Fixed broken link (Infura - Investing in the Decentralization of Ethereum” - Thanks u/shazow!)

Alethio

A comprehensive suite of blockchain exploration, analysis, and forecasting products for the Ethereum network.

Allinfra

All infrastructure, for all — platform for the tokenization of large scale unlisted infrastructure.

Bounties Network

Freelance task fulfillment, paying out in any Ethereum token upon successful completion.

Decrypt Media

A daily news site covering all things crypto and the advent of the decentralized web.

Endjinn

Simulate your key token mechanisms to get on the awesome future usage timeline.

Fathom

A decentralized peer assessment protocol forming the foundation of a universal academic system.

Gitcoin

The easiest way to leverage the open source community to incentivize or monetize work.

Grid+

Leverages the public Ethereum blockchain to give consumers direct access to wholesale energy markets.

Helena

A decentralized platform for curated fundamental token research and analysis.

Infura

A scalable, standards-based, globally distributed cluster and API endpoint for Ethereum, IPFS, and other infrastructures.

Kaleido

An all-in-one enterprise SaaS platform that radically simplifies the creation and operation of secure blockchain networks and accelerates the journey from PoC to Production.

Kauri

The Ethereum community’s technical knowledge network.

Liquality

Swap cryptocurrencies without middlemen.

LitePaper

A simple knowledge base for the crypto-verse.

Meridio

A blockchain platform for creating, managing, and transferring fractional real estate ownership.

MetaMask

MetaMask is a browser extension that allows you to run Ethereum dApps right in your browser without running a full Ethereum node.

Nethereum

A .NET integration library for Ethereum allowing users to interact with Ethereum clients like Geth or Parity using RPC.

OpenLaw

A blockchain-based protocol for the creation and execution of legal agreements in a user-friendly, compliant way.

PegaSys

A protocol engineering team building Ethereum tech for the public chain community and leading enterprises.

Rhombus

Securely connects smart contracts with accurate, computable real-world data.

Truffle

A development environment, testing framework, and asset pipeline for Ethereum-based smart contracts and dapps.

TruSet

Building multi-sided marketplaces to collect, validate, publish, and commercialize business-critical reference data.

uPort

A self-sovereign identity management platform that allows users to register their own identity on Ethereum, send and request credentials, sign transactions, and securely manage keys and data.
submitted by ConsenSys_Socialite to ethereum [link] [comments]

Merkle Trees and Mountain Ranges - Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

Original link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
Unedited text and originally written by:

Peter Todd pete at petertodd.org
Tue May 17 13:23:11 UTC 2016
Previous message: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Next message: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
# Motivation

UTXO growth is a serious concern for Bitcoin's long-term decentralization. To
run a competitive mining operation potentially the entire UTXO set must be in
RAM to achieve competitive latency; your larger, more centralized, competitors
will have the UTXO set in RAM. Mining is a zero-sum game, so the extra latency
of not doing so if they do directly impacts your profit margin. Secondly,
having possession of the UTXO set is one of the minimum requirements to run a
full node; the larger the set the harder it is to run a full node.

Currently the maximum size of the UTXO set is unbounded as there is no
consensus rule that limits growth, other than the block-size limit itself; as
of writing the UTXO set is 1.3GB in the on-disk, compressed serialization,
which expands to significantly more in memory. UTXO growth is driven by a
number of factors, including the fact that there is little incentive to merge
inputs, lost coins, dust outputs that can't be economically spent, and
non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles and
timestamping.

We don't have good tools to combat UTXO growth. Segregated Witness proposes to
give witness space a 75% discount, in part of make reducing the UTXO set size
by spending txouts cheaper. While this may change wallets to more often spend
dust, it's hard to imagine an incentive sufficiently strong to discourage most,
let alone all, UTXO growing behavior.

For example, timestamping applications often create unspendable outputs due to
ease of implementation, and because doing so is an easy way to make sure that
the data required to reconstruct the timestamp proof won't get lost - all
Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
use-cases like using the UTXO set for key rotation piggyback on the uniquely
strong security and decentralization guarantee that Bitcoin provides; it's very
difficult - perhaps impossible - to provide these applications with
alternatives that are equally secure. These non-btc-value-transfer use-cases
can often afford to pay far higher fees per UTXO created than competing
btc-value-transfer use-cases; many users could afford to spend $50 to register
a new PGP key, yet would rather not spend $50 in fees to create a standard two
output transaction. Effective techniques to resist miner censorship exist, so
without resorting to whitelists blocking non-btc-value-transfer use-cases as
"spam" is not a long-term, incentive compatible, solution.

A hard upper limit on UTXO set size could create a more level playing field in
the form of fixed minimum requirements to run a performant Bitcoin node, and
make the issue of UTXO "spam" less important. However, making any coins
unspendable, regardless of age or value, is a politically untenable economic
change.


# TXO Commitments

A merkle tree committing to the state of all transaction outputs, both spent
and unspent, we can provide a method of compactly proving the current state of
an output. This lets us "archive" less frequently accessed parts of the UTXO
set, allowing full nodes to discard the associated data, still providing a
mechanism to spend those archived outputs by proving to those nodes that the
outputs are in fact unspent.

Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
type of deterministic, indexable, insertion ordered merkle tree, which allows
new items to be cheaply appended to the tree with minimal storage requirements,
just log2(n) "mountain tips". Once an output is added to the TXO MMR it is
never removed; if an output is spent its status is updated in place. Both the
state of a specific item in the MMR, as well the validity of changes to items
in the MMR, can be proven with log2(n) sized proofs consisting of a merkle path
to the tip of the tree.

At an extreme, with TXO commitments we could even have no UTXO set at all,
entirely eliminating the UTXO growth problem. Transactions would simply be
accompanied by TXO commitment proofs showing that the outputs they wanted to
spend were still unspent; nodes could update the state of the TXO MMR purely
from TXO commitment proofs. However, the log2(n) bandwidth overhead per txin is
substantial, so a more realistic implementation is be to have a UTXO cache for
recent transactions, with TXO commitments acting as a alternate for the (rare)
event that an old txout needs to be spent.

Proofs can be generated and added to transactions without the involvement of
the signers, even after the fact; there's no need for the proof itself to
signed and the proof is not part of the transaction hash. Anyone with access to
TXO MMR data can (re)generate missing proofs, so minimal, if any, changes are
required to wallet software to make use of TXO commitments.


## Delayed Commitments

TXO commitments aren't a new idea - the author proposed them years ago in
response to UTXO commitments. However it's critical for small miners' orphan
rates that block validation be fast, and so far it has proven difficult to
create (U)TXO implementations with acceptable performance; updating and
recalculating cryptographicly hashed merkelized datasets is inherently more
work than not doing so. Fortunately if we maintain a UTXO set for recent
outputs, TXO commitments are only needed when spending old, archived, outputs.
We can take advantage of this by delaying the commitment, allowing it to be
calculated well in advance of it actually being used, thus changing a
latency-critical task into a much easier average throughput problem.

Concretely each block B_i commits to the TXO set state as of block B_{i-n}, in
other words what the TXO commitment would have been n blocks ago, if not for
the n block delay. Since that commitment only depends on the contents of the
blockchain up until block B_{i-n}, the contents of any block after are
irrelevant to the calculation.


## Implementation

Our proposed high-performance/low-latency delayed commitment full-node
implementation needs to store the following data:

1) UTXO set

Low-latency K:V map of txouts definitely known to be unspent. Similar to
existing UTXO implementation, but with the key difference that old,
unspent, outputs may be pruned from the UTXO set.


2) STXO set

Low-latency set of transaction outputs known to have been spent by
transactions after the most recent TXO commitment, but created prior to the
TXO commitment.


3) TXO journal

FIFO of outputs that need to be marked as spent in the TXO MMR. Appends
must be low-latency; removals can be high-latency.


4) TXO MMR list

Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,
backed by a reference counted, cryptographically hashed object store
indexed by digest (similar to how git repos work). High-latency ok. We'll
cover this in more in detail later.


### Fast-Path: Verifying a Txout Spend In a Block

When a transaction output is spent by a transaction in a block we have two
cases:

1) Recently created output

Output created after the most recent TXO commitment, so it should be in the
UTXO set; the transaction spending it does not need a TXO commitment proof.
Remove the output from the UTXO set and append it to the TXO journal.

2) Archived output

Output created prior to the most recent TXO commitment, so there's no
guarantee it's in the UTXO set; transaction will have a TXO commitment
proof for the most recent TXO commitment showing that it was unspent.
Check that the output isn't already in the STXO set (double-spent), and if
not add it. Append the output and TXO commitment proof to the TXO journal.

In both cases recording an output as spent requires no more than two key:value
updates, and one journal append. The existing UTXO set requires one key:value
update per spend, so we can expect new block validation latency to be within 2x
of the status quo even in the worst case of 100% archived output spends.


### Slow-Path: Calculating Pending TXO Commitments

In a low-priority background task we flush the TXO journal, recording the
outputs spent by each block in the TXO MMR, and hashing MMR data to obtain the
TXO commitment digest. Additionally this background task removes STXO's that
have been recorded in TXO commitments, and prunes TXO commitment data no longer
needed.

Throughput for the TXO commitment calculation will be worse than the existing
UTXO only scheme. This impacts bulk verification, e.g. initial block download.
That said, TXO commitments provides other possible tradeoffs that can mitigate
impact of slower validation throughput, such as skipping validation of old
history, as well as fraud proof approaches.


### TXO MMR Implementation Details

Each TXO MMR state is a modification of the previous one with most information
shared, so we an space-efficiently store a large number of TXO commitments
states, where each state is a small delta of the previous state, by sharing
unchanged data between each state; cycles are impossible in merkelized data
structures, so simple reference counting is sufficient for garbage collection.
Data no longer needed can be pruned by dropping it from the database, and
unpruned by adding it again. Since everything is committed to via cryptographic
hash, we're guaranteed that regardless of where we get the data, after
unpruning we'll have the right data.

Let's look at how the TXO MMR works in detail. Consider the following TXO MMR
with two txouts, which we'll call state #0:

0
/ \
a b

If we add another entry we get state #1:

1
/ \
0 \
/ \ \
a b c

Note how it 100% of the state #0 data was reused in commitment #1. Let's
add two more entries to get state #2:

2
/ \
2 \
/ \ \
/ \ \
/ \ \
0 2 \
/ \ / \ \
a b c d e

This time part of state #1 wasn't reused - it's wasn't a perfect binary
tree - but we've still got a lot of re-use.

Now suppose state #2 is committed into the blockchain by the most recent block.
Future transactions attempting to spend outputs created as of state #2 are
obliged to prove that they are unspent; essentially they're forced to provide
part of the state #2 MMR data. This lets us prune that data, discarding it,
leaving us with only the bare minimum data we need to append new txouts to the
TXO MMR, the tips of the perfect binary trees ("mountains") within the MMR:

2
/ \
2 \
\
\
\
\
\
e

Note that we're glossing over some nuance here about exactly what data needs to
be kept; depending on the details of the implementation the only data we need
for nodes "2" and "e" may be their hash digest.

Adding another three more txouts results in state #3:

3
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \
/ \
/ \
3 3
/ \ / \
e f g h

Suppose recently created txout f is spent. We have all the data required to
update the MMR, giving us state #4. It modifies two inner nodes and one leaf
node:

4
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 4
/ \
/ \
/ \
4 3
/ \ / \
e (f) g h

If an archived txout is spent requires the transaction to provide the merkle
path to the most recently committed TXO, in our case state #2. If txout b is
spent that means the transaction must provide the following data from state #2:

2
/
2
/
/
/
0
\
b

We can add that data to our local knowledge of the TXO MMR, unpruning part of
it:

4
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 4
/ / \
/ / \
/ / \
0 4 3
\ / \ / \
b e (f) g h

Remember, we haven't _modified_ state #4 yet; we just have more data about it.
When we mark txout b as spent we get state #5:

5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ / \
/ / \
/ / \
5 4 3
\ / \ / \
(b) e (f) g h

Secondly by now state #3 has been committed into the chain, and transactions
that want to spend txouts created as of state #3 must provide a TXO proof
consisting of state #3 data. The leaf nodes for outputs g and h, and the inner
node above them, are part of state #3, so we prune them:

5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ /
/ /
/ /
5 4
\ / \
(b) e (f)

Finally, lets put this all together, by spending txouts a, c, and g, and
creating three new txouts i, j, and k. State #3 was the most recently committed
state, so the transactions spending a and g are providing merkle paths up to
it. This includes part of the state #2 data:

3
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ \
/ \ \
/ \ \
0 2 3
/ / /
a c g

After unpruning we have the following data for state #5:

5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ \ / \
/ \ / \
/ \ / \
5 2 4 3
/ \ / / \ /
a (b) c e (f) g

That's sufficient to mark the three outputs as spent and add the three new
txouts, resulting in state #6:

6
/ \
/ \
/ \
/ \
/ \
6 \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
6 6 \
/ \ / \ \
/ \ / \ 6
/ \ / \ / \
6 6 4 6 6 \
/ \ / / \ / / \ \
(a) (b) (c) e (f) (g) i j k

Again, state #4 related data can be pruned. In addition, depending on how the
STXO set is implemented may also be able to prune data related to spent txouts
after that state, including inner nodes where all txouts under them have been
spent (more on pruning spent inner nodes later).


### Consensus and Pruning

It's important to note that pruning behavior is consensus critical: a full node
that is missing data due to pruning it too soon will fall out of consensus, and
a miner that fails to include a merkle proof that is required by the consensus
is creating an invalid block. At the same time many full nodes will have
significantly more data on hand than the bare minimum so they can help wallets
make transactions spending old coins; implementations should strongly consider
separating the data that is, and isn't, strictly required for consensus.

A reasonable approach for the low-level cryptography may be to actually treat
the two cases differently, with the TXO commitments committing too what data
does and does not need to be kept on hand by the UTXO expiration rules. On the
other hand, leaving that uncommitted allows for certain types of soft-forks
where the protocol is changed to require more data than it previously did.


### Consensus Critical Storage Overheads

Only the UTXO and STXO sets need to be kept on fast random access storage.
Since STXO set entries can only be created by spending a UTXO - and are smaller
than a UTXO entry - we can guarantee that the peak size of the UTXO and STXO
sets combined will always be less than the peak size of the UTXO set alone in
the existing UTXO-only scheme (though the combined size can be temporarily
higher than what the UTXO set size alone would be when large numbers of
archived txouts are spent).

TXO journal entries and unpruned entries in the TXO MMR have log2(n) maximum
overhead per entry: a unique merkle path to a TXO commitment (by "unique" we
mean that no other entry shares data with it). On a reasonably fast system the
TXO journal will be flushed quickly, converting it into TXO MMR data; the TXO
journal will never be more than a few blocks in size.

Transactions spending non-archived txouts are not required to provide any TXO
commitment data; we must have that data on hand in the form of one TXO MMR
entry per UTXO. Once spent however the TXO MMR leaf node associated with that
non-archived txout can be immediately pruned - it's no longer in the UTXO set
so any attempt to spend it will fail; the data is now immutable and we'll never
need it again. Inner nodes in the TXO MMR can also be pruned if all leafs under
them are fully spent; detecting this is easy the TXO MMR is a merkle-sum tree,
with each inner node committing to the sum of the unspent txouts under it.

When a archived txout is spent the transaction is required to provide a merkle
path to the most recent TXO commitment. As shown above that path is sufficient
information to unprune the necessary nodes in the TXO MMR and apply the spend
immediately, reducing this case to the TXO journal size question (non-consensus
critical overhead is a different question, which we'll address in the next
section).

Taking all this into account the only significant storage overhead of our TXO
commitments scheme when compared to the status quo is the log2(n) merkle path
overhead; as long as less than 1/log2(n) of the UTXO set is active,
non-archived, UTXO's we've come out ahead, even in the unrealistic case where
all storage available is equally fast. In the real world that isn't yet the
case - even SSD's significantly slower than RAM.


### Non-Consensus Critical Storage Overheads

Transactions spending archived txouts pose two challenges:

1) Obtaining up-to-date TXO commitment proofs

2) Updating those proofs as blocks are mined

The first challenge can be handled by specialized archival nodes, not unlike
how some nodes make transaction data available to wallets via bloom filters or
the Electrum protocol. There's a whole variety of options available, and the
the data can be easily sharded to scale horizontally; the data is
self-validating allowing horizontal scaling without trust.

While miners and relay nodes don't need to be concerned about the initial
commitment proof, updating that proof is another matter. If a node aggressively
prunes old versions of the TXO MMR as it calculates pending TXO commitments, it
won't have the data available to update the TXO commitment proof to be against
the next block, when that block is found; the child nodes of the TXO MMR tip
are guaranteed to have changed, yet aggressive pruning would have discarded that
data.

Relay nodes could ignore this problem if they simply accept the fact that
they'll only be able to fully relay the transaction once, when it is initially
broadcast, and won't be able to provide mempool functionality after the initial
relay. Modulo high-latency mixnets, this is probably acceptable; the author has
previously argued that relay nodes don't need a mempool² at all.

For a miner though not having the data necessary to update the proofs as blocks
are found means potentially losing out on transactions fees. So how much extra
data is necessary to make this a non-issue?

Since the TXO MMR is insertion ordered, spending a non-archived txout can only
invalidate the upper nodes in of the archived txout's TXO MMR proof (if this
isn't clear, imagine a two-level scheme, with a per-block TXO MMRs, committed
by a master MMR for all blocks). The maximum number of relevant inner nodes
changed is log2(n) per block, so if there are n non-archival blocks between the
most recent TXO commitment and the pending TXO MMR tip, we have to store
log2(n)*n inner nodes - on the order of a few dozen MB even when n is a
(seemingly ridiculously high) year worth of blocks.

Archived txout spends on the other hand can invalidate TXO MMR proofs at any
level - consider the case of two adjacent txouts being spent. To guarantee
success requires storing full proofs. However, they're limited by the blocksize
limit, and additionally are expected to be relatively uncommon. For example, if
1% of 1MB blocks was archival spends, our hypothetical year long TXO commitment
delay is only a few hundred MB of data with low-IO-performance requirements.


## Security Model

Of course, a TXO commitment delay of a year sounds ridiculous. Even the slowest
imaginable computer isn't going to need more than a few blocks of TXO
commitment delay to keep up ~100% of the time, and there's no reason why we
can't have the UTXO archive delay be significantly longer than the TXO
commitment delay.

However, as with UTXO commitments, TXO commitments raise issues with Bitcoin's
security model by allowing relatively miners to profitably mine transactions
without bothering to validate prior history. At the extreme, if there was no
commitment delay at all at the cost of a bit of some extra network bandwidth
"full" nodes could operate and even mine blocks completely statelessly by
expecting all transactions to include "proof" that their inputs are unspent; a
TXO commitment proof for a commitment you haven't verified isn't a proof that a
transaction output is unspent, it's a proof that some miners claimed the txout
was unspent.

At one extreme, we could simply implement TXO commitments in a "virtual"
fashion, without miners actually including the TXO commitment digest in their
blocks at all. Full nodes would be forced to compute the commitment from
scratch, in the same way they are forced to compute the UTXO state, or total
work. Of course a full node operator who doesn't want to verify old history can
get a copy of the TXO state from a trusted source - no different from how you
could get a copy of the UTXO set from a trusted source.

A more pragmatic approach is to accept that people will do that anyway, and
instead assume that sufficiently old blocks are valid. But how old is
"sufficiently old"? First of all, if your full node implementation comes "from
the factory" with a reasonably up-to-date minimum accepted total-work
thresholdⁱ - in other words it won't accept a chain with less than that amount
of total work - it may be reasonable to assume any Sybil attacker with
sufficient hashing power to make a forked chain meeting that threshold with,
say, six months worth of blocks has enough hashing power to threaten the main
chain as well.

That leaves public attempts to falsify TXO commitments, done out in the open by
the majority of hashing power. In this circumstance the "assumed valid"
threshold determines how long the attack would have to go on before full nodes
start accepting the invalid chain, or at least, newly installed/recently reset
full nodes. The minimum age that we can "assume valid" is tradeoff between
political/social/technical concerns; we probably want at least a few weeks to
guarantee the defenders a chance to organise themselves.

With this in mind, a longer-than-technically-necessary TXO commitment delayʲ
may help ensure that full node software actually validates some minimum number
of blocks out-of-the-box, without taking shortcuts. However this can be
achieved in a wide variety of ways, such as the author's prev-block-proof
proposal³, fraud proofs, or even a PoW with an inner loop dependent on
blockchain data. Like UTXO commitments, TXO commitments are also potentially
very useful in reducing the need for SPV wallet software to trust third parties
providing them with transaction data.

i) Checkpoints that reject any chain without a specific block are a more
common, if uglier, way of achieving this protection.

j) A good homework problem is to figure out how the TXO commitment could be
designed such that the delay could be reduced in a soft-fork.


## Further Work

While we've shown that TXO commitments certainly could be implemented without
increasing peak IO bandwidth/block validation latency significantly with the
delayed commitment approach, we're far from being certain that they should be
implemented this way (or at all).

1) Can a TXO commitment scheme be optimized sufficiently to be used directly
without a commitment delay? Obviously it'd be preferable to avoid all the above
complexity entirely.

2) Is it possible to use a metric other than age, e.g. priority? While this
complicates the pruning logic, it could use the UTXO set space more
efficiently, especially if your goal is to prioritise bitcoin value-transfer
over other uses (though if "normal" wallets nearly never need to use TXO
commitments proofs to spend outputs, the infrastructure to actually do this may
rot).

3) Should UTXO archiving be based on a fixed size UTXO set, rather than an
age/priority/etc. threshold?

4) By fixing the problem (or possibly just "fixing" the problem) are we
encouraging/legitimising blockchain use-cases other than BTC value transfer?
Should we?

5) Instead of TXO commitment proofs counting towards the blocksize limit, can
we use a different miner fairness/decentralization metric/incentive? For
instance it might be reasonable for the TXO commitment proof size to be
discounted, or ignored entirely, if a proof-of-propagation scheme (e.g.
thinblocks) is used to ensure all miners have received the proof in advance.

6) How does this interact with fraud proofs? Obviously furthering dependency on
non-cryptographically-committed STXO/UTXO databases is incompatible with the
modularized validation approach to implementing fraud proofs.


# References

1) "Merkle Mountain Ranges",
Peter Todd, OpenTimestamps, Mar 18 2013,
https://github.com/opentimestamps/opentimestamps-serveblob/mastedoc/merkle-mountain-range.md

2) "Do we really need a mempool? (for relay nodes)",
Peter Todd, bitcoin-dev mailing list, Jul 18th 2015,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.html

3) "Segregated witnesses and validationless mining",
Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012103.html

--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160517/33f69665/attachment-0001.sig>
submitted by Godballz to CryptoTechnology [link] [comments]

Step by step in staking Redd with Raspberry Pi 3

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

Run a 0.14 Full-Node on RaspberryPi3 Pruned(less than 16GB SD needed)

Hi!
Happy if this guide helps you.
Tip if you want: 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
UPDATE 04/06/17
Add 'uacomment=UASF-SegWit-BIP148' into your bitcoin.conf if you want to signal UASF.
UPDATE 03/13/17
ADDED a tl;dr; Version at the end of this Post.
UPDATE 03/12/17:
Just to test it - I reinstalled all on 8GB SD and it works as well. But maybe you should use at least 16GB for the beginning.
Using a 128GB card for the first version was a little bit stupid - so I reinstalled everything on a 8GB SD card. Including Linux and a pruned blockchain - and it works.
I used prune=550 and Jessie Lite (headless / command line) - without wallet and gui.
The SD is almost full, but it works so far
I also updated the whole manual a bit to make things more clear. Thank you for all your feedback!
Just started my Bitcoin Node today and wanted to share the way I did it with people who are interested in running their own full node. It took some time to write everything down - hopefully correct so far.
I am sure, many people around bitcoin are way more informed and educated as I am - I am the noob. So I wrote this manual to help users like me - noobs, to get started with a cheap, simple bitcoin node on raspberry pi.
Have fun!
I wanted to get my Raspberry Pi 3 working as a node to support the network. Actually the process of installing and running the node was more or less easy - but for Noobs (like I am) it might be a bit tricky to start the whole thing, because there are different ways.
Did you - like me - think you would need +120GB on the raspi, external USB HDD to be a full node? You won't!
If you have a Raspberry and you know what Bitcoin is, I guess, you are a little bit aware of linux, networks and of course bitcoin - so I won't go into detail too much.
This guide is just a little helper to get a full node running on your raspberry pi. Thanks to the help of the nice people in this sub and of course the documentation by the developers, I got it working - and of course also special thanks to raspnode.com - as I followed their tutorial to start - I went some other ways here and there - so please read carefully.
For the Part 2 I would suggest to have http://raspnode.com/diyBitcoin.html open and read through my manual.
I split the tutorial in 2 Parts - PART ONE is about installing the client on your PC and downloading the Blockchain.
PART TWO is about the setup of the raspberryPi and transferring the pruned blockchain to the pi and run it as a full node!
The first thing to be aware of is: You actually need to download the whole blockchain to get this working - if you already have your bitcoin client synced on the PC / MAC great you can reuse it!
Now you might think "but you said less than 16GB in the title!"
Yes, but the good thing is you won't need to download it on your Raspberry, neither you need to sync it completely on your raspberry which took ages (weeks!) before. When you finished this Guide, you will just have a max. 4GB Blockchain on your Raspberry Pi - but it still is a full node! The magic word is Pruning.
Maybe even a 8GB SD Card works just fine including Linux (jessie lite)!
So, if you already have a full node on your PC - Great you can almost skip PART ONE - BUT have at how to Prune in PART ONE if you don't know about it.
For PART TWO you'll need a Raspberry Pi 2 or 3 (I used 3) min. 8GB (works also) or better 16GB SD Card. (I used a 128GB for the first version of this manual - which is way too big)

PART ONE

This is the manual how to get started on you PC / MAC / Linux (I did it on Win7)
Go to: https://bitcoin.org/en/download and download the core Client for your Machine (I used win64).
Install it and configure it to save the Blockchaindata to the directory of your choice - so instead getting 120GB on your C drive, I would suggest to download it to another place like a USB drive.
You can set this up during the install. Standard folder for the blockchain folder is "%APPDATA%\Bitcoin" on Windows.
or you can do it after the install by creating a bitcoin.conf file inside your installation folder / or %APPDATA%\Bitcoin and add
datadir=l:\yourfolder
to the file. Line by line.
By the way here you could also just add dbcache - to use more memory to speed up the process a bit:
dbcache=4096
if you don't want to use the settings inside the program. (you can also set this inside the program under settings! If you have this inside the bitcoin.conf you will see the amount you set there from inside the program - it overrides the values)
You can check inside the windows client under settings, if you can see a manual dbcache is set by having a look at the left footer area. When your dbcache value shows up, everything is fine.
So the Blockchain download process will take time - maybe a few days! Depending on your machine, internet connection and HDD.
The Blockchain is huge as it contains every single transaction of the past until today. You won't need to keep your PC running all the time, you can turn it off and on and it will resync automatically when you start bitcoin-qt.exe!
Make sure to close the client always via "quit" - ctrl+q.
After you have your bitcoin core installed, the blockchain downloaded and synced - you are ready to PRUNE!
First - close the Client and let it close smoothly. After it is really closed you can follow these steps:
By pruning, your blockchain will dramatically shrink. From 120GB to just a few GB.
Be aware, that you will lose your Downloaded Blockchain as pruning will erase a big chunk of it! If you have enough space, you could of course keep the full blockchain saved somewhere on another HDD.
You can prune by editing your bitcoin.conf file by adding:
prune=550
I used prune=1024 - not sure where the differences are right now (min. prune=550). (for my 8GB version I used 550! I suggest to use this.)
Save the bitcoind.conf file and restart your windows client.
It will now clean up the Blockchain. So just the latest blocks are saved. The client should start without any problems. Maybe it takes some time to prune the blockchain data.
Check if everything works normally (the client opens as usual, you can see an empty wallet) than close the client.
Inside the Bitcoin Folder, you'll find two folders called:
blocks chainstate
those are the interesting folders containing the important data (now pruned) - and we will transfer those two to the raspberry later!
Now you are good to start the raspi transfer explained in the next part.

PART 2

Here is what I did:
1) I installed Raspian Pixel (https://www.raspberrypi.org/downloads/raspbian/) using a 128 GB SD - which is not needed because of "Pruning" - I think a 16GB card might work, too! (You can also install Raspian Jessie Lite - which saves you even more space, as it runs headless - only command line) (Updated: It is better to use Jessie Lite to save a lot of space - when you are fine with only command line)
2) I followed partly this tutorial to get everything running and setup:
http://raspnode.com/diyBitcoin.html
Please have a look at it - I have copied the Headlines in capitals to let you know what I did, and what I skipped.
On Tutorial Page: Start with RASPBIAN (OPTIONAL) CONFIG OPTIONS.
Set You RasPi up including "EDITING FILES" to save your Layout at the tutorial page and come back here.
I skipped the CONFIGURE USB AND SET AUTOMOUNT process, as we are going to use PRUNING to reduce the 120GB to a tiny filesize - so USB Devices are not needed here!
It was necessary to ENLARGE SWAP FILE to install bitcoin core - otherwise it didn't went through which ended in a frozen raspi.
So have a close look by following the raspnode tutorial at: ENLARGE SWAP FILE.
I have my raspi running via cable to router - but you can also WiFi setup everything described under NETWORKING ON THE RASPBERRY PI.
Now comes the interesting part: Follow the steps at DOWNLOADING BITCOIN CORE DEPENDENCIES - they work fine for 0.14.0 too. Git should be on Board already when you installed Pixel - otherwise you would need to install it.
sudo apt-get install git -y (only jessy lite)
I skipped the next command lines - as I don't use bitcoin-qt wallet. If you want to use it as wallet - do the step.
mkdir ~/bin cd ~bin
Now you are in the folder you want your bitcoin core data be downloaded to via git. I didn't Downloaded the Berkeley Database source code - so I also skipped the whole next command lines
[email protected]~/bin$ wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz [email protected]~/bin$ tar -xzvf db-4.8.30.NC.tar.gz [email protected]~/bin$ cd db-4.8.30.NC/build_unix/ [email protected]~/bin/db-4.8.30.NC/build_unix$ ../dist/configure --enable-cxx [email protected]~/bin/db-4.8.30.NC/build_unix$ make -j4
and went on with "INSTALLING BITCOIN"!
I followed the first part but instead downloading 0.13 I took of course the latest version:0.14
git clone -b 0.14 https://github.com/bitcoin/bitcoin.git cd bitcoin ./autogen.sh
this might take some time to start.
If you have trouble with hanging RESOLVING DELTAS - just restart the Raspberry Pi and remove the bitcoin folder inside /~bin using
rm -rf bitcoin
this command will delete the folder and you can reuse
git clone -b 0.14 https://github.com/bitcoin/bitcoin.git

For some reason RESOLVING DELTAS is a common problem with different downloads - so just retry it and at least after 3 times it should work!

as I didn't use the GUI/ Wallet, I ran
./configure --enable-upnp-default --disable-wallet
as I don't need the wallet functionality.
I didn't need to use "MAKE" which saves you maybe up to 2.5 hours.
instead you can just go ahead with:
sudo make install
(If I am wrong in doing so - please let me know)
The install takes some time - and just a heads up: when it gets stuck somewhere - just redo the installation process - it took three times to went through - stuck at some processing.
After the installation took place you can finally get your Raspberry Pi Node running in no time!
To test if the the installation went through - you can just start bitcoind using:
bitcoind &
than check if everything is working so far:
bitcoin-cli getinfo
after a few seconds you should see version: etc...
if not, something went wrong. Try to redo the steps in the raspnode tutorial.
(don't give up if it failed - retry! Ask your questions here)
IMPORTANT: you need to stop bitcoin on your raspberry now!
bitcoin-cli stop
If you don't need an external USB Drive - what I hope - as we are going to use pruning just go ahead and skip the USB part and create a file inside (or follow the raspnode tutorial on how to setup the USB drive):
cd .bitcoin
sudo nano bitcoin.conf
and enter the exact same pruning size you have used on your Desktop Machine to prune. I used 1024 but the minimum is 550. (used 550 for the 8GB SD card on PC and Raspberry)
prune=550
That's it for the raspi.
update: To signal UASF enter in a new line:
uacomment=UASF-SegWit-BIP148

TRANSFER

Now you have to transfer the two folders CHAINSTATE and BLOCKS from your PC bitcoind directory to your raspberry.
I am using a program called "WINSCP" - it is free and easy to use: https://winscp.net/eng/download.php
We need this to transfer the files to the Raspberry pi. Pretty sure you can also do it via SSH - but I am the noob. So let's keep it simple.
Open Winscp and put in the IP Address of your Raspberry Pi, User and Password (same as in SSH)
You should now see the directories on your Raspberry Pi. There is a folder called
.bitcoin
enter it and you will see the two folders
blocks & chainstate
you can delete them on the raspberry as they have some data from your previous test inside.
Make sure you can also see the bitcoin.conf file in that directory, which needs to contain the exact same prune line, like the one on your desktop machine. If not, make sure to edit it via SSH. The line "datadir=l:\yourfolder" is obviously not needed in the Raspberry bitcoin.conf file.
Now grab the two folders CHAINSTATE and BLOCKS from your PC and copy them to your .bitcoind folder.
I also copied banlist.dat, fee_estimation.dat, mempool.dat and peers.dat to the folder - not really knowing if needed! Not needed.
The whole copy process might take some minutes (against some weeks in the old way).
After copying is finished, you can now start bitcoind on the Raspberry.
bitcoind &
the & symbol let you still use the command line while the process is running btw.
The process - if succesfull - will take some time to finish.
bitcoin-cli getinfo
Will give you some informations what is going on right now. When you can see, that it is checking the blocks, this is good!
If you get an error - double check - if you have the correct prune size (same as on desktop machine) - in bitcoin.conf and that this file is inside .bitcoin on RaspberryPi. It took me some time, to find my mistakes.
Congrats! You are almost a part of the network!
To make your node now a fullnode, you will need to go to your router (often 192.168.1.1) and enable portforwarding for your raspberry pi - and open ports 8333 - that's it!
You can now go to: https://bitnodes.21.co/nodes/
scroll down to "JOIN THE NETWORK" and check check if your node IP is connected!
It will show up as soon as the blocks are checked and the raspi is running.
Well done!
Now you are running a full node, with a small Blockchain and got it working in Minutes, not weeks!
I really hope, my little tutorial worked for you and your are part of the Node network now.
If you have problems or I made a mistake in this helper tut, just let me know and I will try to make it better.
Have fun and NODL!
the noob
tl;dr; (if you are a real noob start with the non-tl;dr version!)
tl;dr; PART ONE
1) Download & install / setup bitcoincore @ https://bitcoin.org/de/download
2) change dbcache to something smaller than your memory and download the whole Blockchain (120GB).
3) create a file called bitcoin.conf put the line prune=550 (or higher) in to activate pruning on win inside %appData%/bitcoin
4) Open ports 8333 on your Router to make this a full node with a smaller Blockchain.
You are running a full node on your PC.
tl;dr; PART TWO
1) Install jessie lite and the needed dependencies on your SDCard - Raspberry
( >git clone -b 0.14 https://github.com/bitcoin/bitcoin.git )
  • see tutorial for more info.
2) create a file called bitcoin.conf inside .bitcoin and add the same prune=Number you had on your PC.
3) transfer the pruned folders BLOCKS and CHAINSTATE to the Raspberry Folder .bitcoin
4)Start "bitcoind &"
5) let everything sync
6) Make sure you have port 8333 opened on your router.
You are running a full node on your Raspberry with a super small Blockchain (I put all on a 8GB SDcard)
Tip if you want : 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
updated 03/12 - will update more, soon.
updated 03/12.2 - I updated the whole process a bit and also added some improvements.
updated 03/14/ Added a tl;dr version at the end.
submitted by I-am-the-noob to Bitcoin [link] [comments]

The Nexus FAQ - part 1

Full formatted version: https://docs.google.com/document/d/16KKjVjQH0ypLe00aoTJ_hZyce7RAtjC5XHom104yn6M/
 

Nexus 101:

  1. What is Nexus?
  2. What benefits does Nexus bring to the blockchain space?
  3. How does Nexus secure the network and reach consensus?
  4. What is quantum resistance and how does Nexus implement this?
  5. What is Nexus’ Unified Time protocol?
  6. Why does Nexus need its own satellite network?
 

The Nexus Currency:

  1. How can I get Nexus?
  2. How much does a transaction cost?
  3. How fast does Nexus transfer?
  4. Did Nexus hold an ICO? How is Nexus funded?
  5. Is there a cap on the number of Nexus in existence?
  6. What is the difference between the Oracle wallet and the LLD wallet?
  7. How do I change from Oracle to the LLD wallet?
  8. How do I install the Nexus Wallet?
 

Types of Mining or Minting:

  1. Can I mine Nexus?
  2. How do I mine Nexus?
  3. How do I stake Nexus?
  4. I am staking with my Nexus balance. What are trust weight, block weight and stake weight?
 

Nexus 101:

1. What is Nexus (NXS)?
Nexus is a digital currency, distributed framework, and peer-to-peer network. Nexus further improves upon the blockchain protocol by focusing on the following core technological principles:
Nexus will combine our in-development quantum-resistant 3D blockchain software with cutting edge communication satellites to deliver a free, distributed, financial and data solution. Through our planned satellite and ground-based mesh networks, Nexus will provide uncensored internet access whilst bringing the benefits of distributed database systems to the world.
For a short video introduction to Nexus Earth, please visit this link
 
2. What benefits does Nexus bring to the blockchain space?
As Nexus has been developed, an incredible amount of time has been put into identifying and solving several key limitations:
Nexus is also developing a framework called the Lower Level Library. This LLL will incorporate the following improvements:
For information about more additions to the Lower Level Library, please visit here
 
3. How does Nexus secure the network and reach consensus?
Nexus is unique amongst blockchain technology in that Nexus uses 3 channels to secure the network against attack. Whereas Bitcoin uses only Proof-of-Work to secure the network, Nexus combines a prime number channel, a hashing channel and a Proof-of-Stake channel. Where Bitcoin has a difficulty adjustment interval measured in weeks, Nexus can respond to increased hashrate in the space of 1 block and each channel scales independently of the other two channels. This stabilizes the block times at ~50 seconds and ensures no single channel can monopolize block production. This means that a 51% attack is much more difficult to launch because an attacker would need to control all 3 channels.
Every 60 minutes, the Nexus protocol automatically creates a checkpoint. This prevents blocks from being created or modified dated prior to this checkpoint, thus protecting the chain from malicious attempts to introduce an alternate blockchain.
 
4. What is quantum resistance and how does Nexus implement it?
To understand what quantum resistance is and why it is important, you need to understand how quantum computing works and why it’s a threat to blockchain technology. Classical computing uses an array of transistors. These transistors form the heart of your computer (the CPU). Each transistor is capable of being either on or off, and these states are used to represent the numerical values 1 and 0.
Binary digits’ (bits) number of states depends on the number of transistors available, according to the formula 2n, where n is the number of transistors. Classical computers can only be in one of these states at any one time, so the speed of your computer is limited to how fast it can change states.
Quantum computers utilize quantum bits, “qubits,” which are represented by the quantum state of electrons or photons. These particles are placed into a state called superposition, which allows the qubit to assume a value of 1 or 0 simultaneously.
Superposition permits a quantum computer to process a higher number of data possibilities than a classical computer. Qubits can also become entangled. Entanglement makes a qubit dependant on the state of another, enabling quantum computing to calculate complex problems, extremely quickly.
One such problem is the Discrete Logarithm Problem which elliptic curve cryptography relies on for security. Quantum computers can use Shor’s algorithm to reverse a key in polynomial time (which is really really really fast). This means that public keys become vulnerable to quantum attack, since quantum computers are capable of being billions of times faster at certain calculations. One way to increase quantum resistance is to require more qubits (and more time) by using larger private keys:
Bitcoin Private Key (256 bit) 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
Nexus Private Key (571 bit) 6Wuiv513R18o5cRpwNSCfT7xs9tniHHN5Lb3AMs58vkVxsQdL4atHTF Vt5TNT9himnCMmnbjbCPxgxhSTDE5iAzCZ3LhJFm7L9rCFroYoqz
Bitcoin addresses are created by hashing the public key, so it is not possible to decrypt the public key from the address; however, once you send funds from that address, the public key is published on the blockchain rendering that address vulnerable to attack. This means that your money has higher chances of being stolen.
Nexus eliminates these vulnerabilities through an innovation called signature chains. Signature chains will enable access to an account using a username, password and PIN. When you create a transaction on the network, you claim ownership of your signature chain by revealing the public key of the NextHash (the hash of your public key) and producing a signature from the one time use private key. Your wallet then creates a new private/public keypair, generates a new NextHash, including the corresponding contract. This contract can be a receive address, a debit, a vote, or any other type of rule that is written in the contract code.
This keeps the public key obscured until the next transaction, and by divorcing the address from the public key, it is unnecessary to change addresses in order to change public keys. Changing your password or PIN code becomes a case of proving ownership of your signature chain and broadcasting a new transaction with a new NextHash for your new password and/or PIN. This provides the ability to login to your account via the signature chain, which becomes your personal chain within the 3D chain, enabling the network to prove and disprove trust, and improving ease of use without sacrificing security.
The next challenge with quantum computers is that Grover’s algorithm reduces the security of one-way hash function by a factor of two. Because of this, Nexus incorporates two new hash functions, Skein and Keccak, which were designed in 2008 as part of a contest to create a new SHA3 standard. Keccak narrowly defeated Skein to win the contest, so to maximize their potential Nexus combines these algorithms. Skein and Keccak utilize permutation to rotate and mix the information in the hash.
To maintain a respective 256/512 bit quantum resistance, Nexus uses up to 1024 bits in its proof-of-work, and 512 bits for transactions.
 
5. What is the Unified Time protocol?
All blockchains use time-stamping mechanisms, so it is important that all nodes operate using the same clock. Bitcoin allows for up to 2 hours’ discrepancy between nodes, which provides a window of opportunity for the blockchain to be manipulated by time-related attack vectors. Nexus eliminates this vulnerability by implementing a time synchronization protocol termed Unified Time. Unified Time also enhances transaction processing and will form an integral part of the 3D chain scaling solution.
The Unified Time protocol facilitates a peer-to-peer timing system that keeps all clocks on the network synchronized to within a second. This is seeded by selected nodes with timestamps derived from the UNIX standard; that is, the number of seconds since January 1st, 1970 00:00 UTC. Every minute, the seed nodes report their current time, and a moving average is used to calculate the base time. Any node which sends back a timestamp outside a given tolerance is rejected.
It is important to note that the Nexus network is fully synchronized even if an individual wallet displays something different from the local time.
 
6. Why does Nexus need its own satellite network?
One of the key limitations of a purely electronic monetary system is that it requires a connection to the rest of the network to verify transactions. Existing network infrastructure only services a fraction of the world’s population.
Nexus, in conjunction with Vector Space Systems, is designing communication satellites, or cubesats, to be launched into Low Earth Orbit in 2019. Primarily, the cubesat mesh network will exist to give Nexus worldwide coverage, but Nexus will also utilize its orbital and ground mesh networks to provide free and uncensored internet access to the world.
 

The Nexus Currency (NXS):

1. How can I get Nexus?
There are two ways you can obtain Nexus. You can either buy Nexus from an exchange, or you can run a miner and be rewarded for finding a block. If you wish to mine Nexus, please follow our guide found below.
Currently, Nexus is available on the following exchanges:
Nexus is actively reaching out to other exchanges to continue to be listed on cutting edge new financial technologies..
 
2. How much does a transaction cost?
Under Nexus, the fee structure for making a transaction depends on the size of your transaction. A default fee of 0.01 NXS will cover most transactions, and users have the option to pay higher fees to ensure their transactions are processed quickly.
When the 3D chain is complete and the initial 10-year distribution period finishes, Nexus will absorb these fees through inflation, enabling free transactions.
 
3. How fast does Nexus transfer?
Nexus reaches consensus approximately every ~ 50 seconds. This is an average time, and will in some circumstances be faster or slower. NXS currency which you receive is available for use after just 6 confirmations. A confirmation is proof from a node that the transaction has been included in a block. The number of confirmations in this transaction is the number that states how many blocks it has been since the transaction is included. The more confirmations a transaction has, the more secure its placement in the blockchain is.
 
4. Did Nexus hold an ICO? How is Nexus funded?
The Nexus Embassy, a 501(C)(3) not-for-profit corporation, develops and maintains the Nexus blockchain software. When Nexus began under the name Coinshield, the early blocks were mined using the Developer and Exchange (Ambassador) addresses, which provides funding for the Nexus Embassy.
The Developer Fund fuels ongoing development and is sourced by a 1.5% commission per block mined, which will slowly increase to 2.5% after 10 years. This brings all the benefits of development funding without the associated risks.
The Ambassador (renamed from Exchange) keys are funded by a 20% commission per block reward. These keys are mainly used to pay for marketing, and producing and launching the Nexus satellites.
When Nexus introduces developer and ambassador contracts, they will be approved, denied, or removed by six voting groups namely: currency, developer, ambassador, prime, hash, and trust.
Please Note: The Nexus Embassy reserves the sole right to trade, sell and or use these funds as required; however, Nexus will endeavor to minimize the impact that the use of these funds has upon the NXS market value.
 
5. Is there a cap on the number of NXS in existence?
After an initial 10-year distribution period ending on September 23rd, 2024, there will be a total of 78 million NXS. Over this period, the reward gradient for mining Nexus follows a decaying logarithmic curve instead of the reward halving inherent in Bitcoin. This avoids creating a situation where older mining equipment is suddenly unprofitable, encouraging miners to continue upgrading their equipment over time and at the same time reducing major market shocks on block halving events.
When the distribution period ends, the currency supply will inflate annually by a maximum of 3% via staking and by 1% via the prime and hashing channels. This inflation is completely unlike traditional inflation, which degrades the value of existing coins. Instead, the cost of providing security to the blockchain is paid by inflation, eliminating transaction fees.
Colin Cantrell - Nexus Inflation Explained
 
6. What is the difference between the LLD wallet and the Oracle wallet?
Due to the scales of efficiency needed by blockchain, Nexus has developed a custom-built database called the Lower Level Database. Since the development of the LLD wallet 0.2.3.1, which is a precursor to the Tritium updates, you should begin using the LLD wallet to take advantage of the faster load times and improved efficiency.
The Oracle wallet is a legacy wallet which is no longer maintained or updated. It utilized the Berkeley DB, which is not designed to meet the needs of a blockchain. Eventually, users will need to migrate to the LLD wallet. Fortunately, the wallet.dat is interchangeable between wallets, so there is no risk of losing access to your NXS.
 
7. How do I change from Oracle to the LLD wallet?
Step 1 - Backup your wallet.dat file. You can do this from within the Oracle wallet Menu, Backup Wallet.
Step 2 - Uninstall the Oracle wallet. Close the wallet and navigate to the wallet data directory. On Windows, this is the Nexus folder located at %APPDATA%\Nexus. On macOS, this is the Nexus folder located at ~/Library/Application Support/Nexus. Move all of the contents to a temporary folder as a backup.
Step 3 - Copy your backup of wallet.dat into the Nexus folder located as per Step 2.
Step 4 - Install the Nexus LLD wallet. Please follow the steps as outlined in the next section. Once your wallet is fully synced, your new wallet will have access to all your addresses.
 
8. How do I install the Nexus Wallet?
You can install your Nexus wallet by following these steps:
Step 1 - Download your wallet from www.nexusearth.com. Click the Downloads menu at the top and select the appropriate wallet for your operating system.
Step 2 - Unzip the wallet program to a folder. Before running the wallet program, please consider space limitations and load times. On the Windows OS, the wallet saves all data to the %APPDATA%\Nexus folder, including the blockchain, which is currently ~3GB.
On macOS, data is saved to the ~/Library/Application Support/Nexus folder. You can create a symbolic link, which will allow you to install this information in another location.
Using Windows, follow these steps:
On macOS, follow these steps:
Step 3 (optional) - Before running the wallet, we recommend downloading the blockchain database manually. Nexus Earth maintains a copy of the blockchain data which can save hours from the wallet synchronization process. Please go to www.nexusearth.com and click the Downloads menu.
Step 4 (optional) - Extract the database file. This is commonly found in the .zip or .rar format, so you may need a program like 7zip to extract the contents. Please extract it to the relevant directory, as outlined in step 2.
Step 5 - You can now start your wallet. After it loads, it should be able to complete synchronization in a short time. This may still take a couple of hours. Once it has completed synchronizing, a green check mark icon will appear in the lower right corner of the wallet.
Step 6 - Encrypt your wallet. This can be done within the wallet, under the Settings menu. Encrypting your wallet will lock it, requiring a password in order to send transactions.
Step 7 - Backup your wallet.dat file. This can be done from the File menu inside the wallet. This file contains the keys to the addresses in your wallet. You may wish to keep a secure copy of your password somewhere, too, in case you forget it or someone else (your spouse, for example) ever needs it.
You should back up your wallet.dat file again any time you create – or a Genesis transaction creates (see “staking” below) – a new address.
 

Types of Mining or Minting:

1.Can I mine Nexus?
Yes, there are 2 channels that you can use to mine Nexus, and 1 channel of minting:
Prime Mining Channel
This mining channel looks for a special prime cluster of a set length. This type of calculation is resistant to ASIC mining, allowing for greater decentralization. This is most often performed using the CPU.
Hashing Channel
This channel utilizes the more traditional method of hashing. This process adds a random nonce, hashes the data, and compares the resultant hash against a predetermined format set by the difficulty. This is most often performed using a GPU.
Proof of Stake (nPoS)
Staking is a form of mining NXS. With this process, you can receive NXS rewards from the network for continuously operating your node (wallet). It is recommended that you only stake with a minimum balance of 1000 NXS. It’s not impossible to stake with less, but it becomes harder to maintain trust. Losing trust resets the interest rate back to 0.5% per annum.
 
2. How do I mine Nexus?
As outlined above, there are two types of mining and 1 proof of stake. Each type of mining uses a different component of your computer to find blocks, the CPU or the GPU. Nexus supports CPU and GPU mining on Windows only. There are also third-party macOS builds available.
Please follow the instructions below for the relevant type of miner.
 
Prime Mining:
Almost every CPU is capable of mining blocks on this channel. The most effective method of mining is to join a mining pool and receive a share of the rewards based on the contribution you make. To create your own mining facility, you need the CPU mining software, and a NXS address. This address cannot be on an exchange. You create an address when you install your Nexus wallet. You can find the related steps under How Do I Install the Nexus Wallet?
Please download the relevant miner from http://nexusearth.com/mining.html. Please note that there are two different miner builds available: the prime solo miner and the prime pool miner. This guide will walk you through installing the pool miner only.
Step 1 - Extract the archive file to a folder.
Step 2 - Open the miner.conf file. You can use the default host and port, but these may be changed to a pool of your choice. You will need to change the value of nxs_address to the address found in your wallet. Sieve_threads is the number of CPU threads you want to use to find primes. Ptest_threads is the number of CPU threads you want to test the primes found by the sieve. As a general rule, the number of threads used for the sieve should be 75% of the threads used for testing.
It is also recommended to add the following line to the options found in the .conf file:
"experimental" : "true"
This option enables the miner to use an improved sieve algorithm which will enable your miner to find primes at a faster rate.
Step 3 - Run the nexus_cpuminer.exe file. For a description of the information shown in this application, please read this guide.
 
Hashing:
The GPU is a dedicated processing unit housed on-board your graphics card. The GPU is able to perform certain tasks extremely well, unlike your CPU, which is designed for parallel processing. Nexus supports both AMD and Nvidia GPU mining, and works best on the newer models. Officially, Nexus does not support GPU pool mining, but there are 3rd party miners with this capability.
The latest software for the Nvidia miner can be found here. The latest software for the AMD miner can be found here. The AMD miner is a third party miner. Information and advice about using the AMD miner can be found on our Slack channel. This guide will walk you through the Nvidia miner.
Step 1 - Close your wallet. Navigate to %appdata%\Nexus (~/Library/Application Support/Nexus on macOS) and open the nexus.conf file. Depending on your wallet, you may or may not have this file. If not, please create a new txt file and save it as nexus.conf
You will need to add the following lines before restarting your wallet:
Step 2 - Extract the files into a new folder.
Step 3 - Run the nexus.bat file. This will run the miner and deposit any rewards for mining a block into the account on your wallet.
For more information on either Prime Mining or Hashing, please join our Slack and visit the #mining channel. Additional information can be found here.
 
3. How do I stake Nexus?
Once you have your wallet installed, fully synchronized and encrypted, you can begin staking by:
After you begin staking, you will receive a Genesis transaction as your first staking reward. This establishes a Trust key in your wallet and stakes your wallet balance on that key. From that point, you will periodically receive additional Trust transactions as further staking rewards for as long as your Trust key remains active.
IMPORTANT - After you receive a Genesis transaction, backup your wallet.dat file immediately. You can select the Backup Wallet option from the File menu, or manually copy the file directly. If you do not do this, then your Nexus balance will be staked on the Trust key that you do not have backed up, and you risk loss if you were to suffer a hard drive failure or other similar problem. In the future, signature chains will make this precaution unnecessary.
 
4. I am staking with my Nexus balance. What are interest rate, trust weight, block weight, and stake weight?
These items affect the size and frequency of staking rewards after you receive your initial Genesis transaction. When staking is active, the wallet displays a clock icon in the bottom right corner. If you hover your mouse pointer over the icon, a tooltip-style display will open up, showing their current values.
Please remember to backup your wallet.dat file (see question 3 above) after you receive a Genesis transaction.
Interest Rate - The minting rate at which you will receive staking rewards, displayed as an annual percentage of your NXS balance. It starts at 0.5%, increasing to 3% after 12 months. The rate increase is not linear but slows over time. It takes several weeks to reach 1% and around 3 months to reach 2%.
With this rate, you can calculate the average amount of NXS you can expect to receive each day for staking.
Trust Weight - An indication of how much the network trusts your node. It starts at 5% and increases much more quickly than the minting (interest) rate, reaching 100% after one month. Your level of trust increases your stake weight (below), thus increasing your chances of receiving staking transactions. It becomes easier to maintain trust as this value increases.
Block Weight - Upon receipt of a Genesis transaction, this value will begin increasing slowly, reaching 100% after 24 hours. Every time you receive a staking transaction, the block weight resets. If your block weight reaches 100%, then your Trust key expires and everything resets (0.5% interest rate, 5% trust weight, waiting for a new Genesis transaction).
This 24-hour requirement will be replaced by a gradual decay in the Tritium release. As long as you receive a transaction before it decays completely, you will hold onto your key. This change addresses the potential of losing your trust key after months of staking simply because of one unlucky day receiving trust transactions.
Stake Weight - The higher your stake weight, the greater your chance of receiving a transaction. The exact value is a derived by a formula using your trust weight and block weight, which roughly equals the average of the two. Thus, each time you receive a transaction, your stake weight will reset to approximately half of your current level of trust.
submitted by scottsimon36 to nexusearth [link] [comments]

Qtum Co Founder Patrick Dai | "3 o'clock no sleep blockchain" depth of sharing

In the industry known as the "first block of the block community," the three o'clock sleepless block chain group, brought together the heavyweight figures in the domestic block chain industry. On the second day of the New Year, starting at 11 am, the group members with a total market capitalization of about 1 trillion yuan, as the traditional world still rejoice in the Great Reign, Technology, valuation, investment and future, the main questions raised in the group were carefully answered and shared. The full text is as follows:
 
Q1: Stellar recently fierce in Silicon Valley, do you think the threat to eth big?
Patrick Dai: ETH has become an ecosystem where the greatest risk comes from the risks inherent in one's own ecology but less from outside risks unless there is a tenfold increase in Ethereum's advanced ideas and technologies, giving it an opportunity to replace Ethereum , Otherwise it is a big threat to the nature, but not competing with the front of Ethereum, in other areas (outside the ICO) force, there are still a lot of business and investment opportunities.
 
Q2: What do you think about the millions of TPS that eos claims?
Patrick Dai: Blockchain is not born for the TPS, if we need faster TPS, the existing banking system and Paypal and WeChat payment, is a better choice. In addition to the degree of decentralization and TPS is basically an irreconcilable conflict, many of the replacement of TPS is to sacrifice network to the degree of centralization to obtain, I personally think, simply in pursuit of higher TPS, but it makes no sense , Especially if the network after only a few dozen large nodes (this is not the early stages of the bank?), Then the high TPS, very often not significant.
 
TPS makes sense for specific things, but requires a compromise with the philosophy behind cryptocurrencies. Because traditional IT technology has been studied for distributed systems for decades, all algorithms based on BFT and various variants can achieve very high TPS, but their degree of centralization is relatively high. The average person in the network is Can not get the right of reciprocity If you can not participate in the supervision and verification of the network, in fact, the use of existing financial services are more than enough.
 
Question 3: Qtum Chain initial design of the core of what is the point? Qtum how to build their own ecology? Qtum globalization is good, even South Koreans like Qtum,landing strategies and methods in different states around the world how to look?**
 
Patrick Dai:
The core of Qtum Blockchain design:
  1. Security, security is the number one priority for cryptocurrency systems, with no foundation for security and sophisticated software as a back-up.
  2. Qtum chain is basically compatible with bitcoin's UTXO and all BIPs, and is also compatible with EVM and EVM-based ecology.
  3. Flexible, the biggest innovation in Qtum is based on bitcoin transaction model, which supports the implementation of smart contract, so that Ethereum's virtual machine can run on the bitcoin network. In addition, the current Qtum network is already in the POS phase, and around 3000 A full node. POS is more friendly to business applications. Through technical support, development tools, Community Roadshow investment hatching in the constant construction of the ecology of the Qtum Blockchain. The more important thing is landing on the local community developers and local project developers to achieve localization, the international team will also be a lot of help.
 
Question 4: Decentralized trading system, the future direction of development is?
 
Patrick Dai: to the center of the trading system of my research is not much to talk about a few specific cases, the earliest to the center of the trading system is based on the colorcoin mastercoin and counterparty transactions colorcoin on the back appeared on NXT and the BTS Decentralized trading systems, followed by the emergence of etherdelta (based on the smart contract trading system), from the experience above, several decentralized trading system experience, similar to the centralized trading system of high-frequency mobile Sex, a great gap. About decentralized trading system in the order matching and order synchronization, this can find some developers in this area, consult.
 
Q5: ipfs really can really decentralized web and app? Not a simple one? What is the point of going to a centralized app?
Patrick Dai: IPFS specific technology to achieve no in-depth study, but read the design concept, the project itself also mentioned for several years, to the center of the web and app should be serverless service to developers, as long as the interface , Regardless of who behind the service to provide. Is not a simple token, depending on the ecology behind it, bitcoin is essentially just a piece of data in a bitcoin network, and decentralized apps make sense, but at the moment many of Dapp's really just an app + blockchain as a settlement layer .
However, the future of blockchain and Dapp's future will transcend the existence of cryptocurrency and will become a social infrastructure: trust. Dapp has a lot of good direction: the game (props channels), content (movie music text), Internet of things, ID and so on.
 
Q6: Everyone has been saying that it is necessary to decentralize and intensify the high level of Dapp's certain degree of contradictions. However, we can not just stay at the stage where btc is used as a currency and eth only serves as a currency to be raised. Developing Dapps to address user needs, that is, the need to strike a balance between a purely decentralized utopia and user application world, Dpos is a solution for now, what do you think? How to grasp the degree of the two?
Patrick Dai: Indeed, many Dapp is a pseudo-concept, but cryptocurrency itself has begun to penetrate into various places as the first successful application based on blockchain technology. My consideration for the future blockchain system is that there is enough decentralization at the bottom and the application layer can be neutralized. We need a trustless bottom plus an application layer that requires trust, on the one hand, a trustless premium (trust cost Lowest) + centralized premium (centralized), Dapp still has a lot to see in the future, such as gaming (virtual assets and channel changes) digital content (movie music) Internet of Things security and management of digital identities Areas of Pratt & Whitney Finance (Insurance-autonomous finance and micro-financial services, etc.).
At present, many Dapp just use the characteristics of a blockchain, that is, the issuance and clearing of tokens. The blockchain has many other features that need to be discovered and discovered.
 
Q7: How do you think about the feasibility and security of cross-link technology? At present, you are optimistic about this project. In addition, how to ensure the trust and reliability of the link in the chain?
Patrick Dai: I personally feel that the current cross-link area is still in its early stages, both in bitcoin and Ethereum network have limited processing power, and the process of continuous evolution, I personally feel that this one cross-chain is not yet mature enough, and from the solution Just need to point out whether cross-link at least at this stage is not just a need.
On the Oracle side, this is a need, especially in the popularization of smart contracts, we need the blockchain can access external systems, in a sense, the current blockchain is an algorithm-driven self-consistent Closed system, the logic is pre-set. Through Oracle we can introduce external data sources to trigger the execution of the contract. There are many directions on how to solve the problem of credible data sources.
One is a centralized approach, such as providing data sources by auditing companies and government departments. Another way to go to the center is to introduce games and mortgages. Punish fraud and reward honest data sources and establish a preferred positive feedback mechanism. Of course, there are many other solutions, there is a lot of community research, Microsoft also has a cryptolet project.
 
Q8: Ask a funny, 10 times eth, I have been curious about this issue, high-dimensional playing low-dimensional, non-dimensional entanglement. You must have thought about this 10 times the problem or possible direction method, want to hear you talk about the possibility of 10 times the direction of eth?
Patrick Dai: 10 times ETH advanced concepts and technology iteration, ETH basically invest this thing is done through the ICO done the ultimate, 15 seconds to complete the investment process (DD TS Token release). It takes a few months, compared to the traditional melting of an angel, which is a difference of 15 seconds vs 3 months. So somehow, ETH becomes the largest investment and financing platform in the world. This is also the largest application of Ethereum, but the application of other smart contracts but did not develop.
 
From the cash point of view there are several directions:
  1. distributed governance (refer to bitcoin 1M to 2M process and DAO processing);
  2. system of self-evolution and evolution;
  3. ease of use 10 times the increase;
 
From a technical point of view:
  1. scalability (full node size participation threshold TPS reciprocal rights);
  2. privacy and application independence and loose coupling (refer to Parity theft);
  3. Better flexibility (more types of virtual machines and a wider range of smart contract languages);
  4. network layering and partitioning and data compression;
  5. new consensus mechanisms (often requiring years of testing and practice) and more.
 
Q9: On the current blockchain + distributed computing issues, I think in the future if the dapp market can really make it indispensable based on the blockchain program to solve the calculation, storage, node acceleration and other issues. Currently I see several projects on distributed computing are based on the construction of Ethereum, are worrying about the performance, how do you think?
Patrick Dai: Distributed Computing I did not study much, but its initial project should come from MaidSafe (https://maidsafe.net/), a nearly 10-year project, essentially Proof of Resource, and many others. The type of computation is actually not very suitable for distributed processing, requiring serial processing of data that is essentially not accelerated through distributed computing, and distributed computing may be able to handle similar game rendering and image rendering needs, but I do not know How big is a market?
In addition, in distributed computing, it is also a problem how to use a common programming language to describe the computing task to be calculated and submit it accurately to the computing node. This one can consult the head of distributed computing projects.
 
Q10: Analysis of the following characteristics and advantages and disadvantages of the underlying chain: BTC / QTUM / ETH / EOS / NEO / ELASTOS?
 
Q11: At present more discussion is the public chain and the basic agreement, the application of technology in the future how to develop, what application scenarios faster landing?
Patrick Dai: The current blockchain technology is still in its early stages of evolution, standing in the Internet era 20 years ago, when we can hardly imagine today can be called a mobile phone uber, the development of technology to give everyone a more rich diversity The possibility is the future.
From an application perspective, the blockchain industry is indeed in the early stages of its application. Cryptocurrency is relative to the blockchain, similar to Email versus Internet, but the development behind the Internet goes far beyond emailing for information exchange, Then the future development of the blockchain will certainly not stop at cryptocurrencies born for value exchange.
Cryptocurrency is just the beginning. From a scenario perspective, the biggest feature of blockchain technology is that it guarantees a trustless platform through a variety of technologies, a trust-free platform that reduces the cost of all business transactions.
 
Q12: First ask yourself a few questions: blockchain where the biggest investment opportunities?
Patrick Dai: Based on the changes and disruptiveness brought by cryptocurrency, its wealth is created faster than the industrial revolution and the information revolution. From an investment point of view, I personally feel that there are several good directions:
  1. Encrypted currency (cryptocurrency and token) in the underlying publicchain, which basically became the industry's first token-based blockchain technology with a close combination of blockchain
  2. Technologies and specific application scenarios (the industry is in its infancy)
  3. Encryption Asset Services Portal (Wallet Exchange IM)
  4. Breaking Down Scenarios Across Industries (Games, Entertainment, IoT, ID, Healthcare, Supply Chain)
  5. Organizational Change Research, Economics, Think Tanks, Deep Media.
 
Q13: Is cryptocurrency popular at large scale?
Patrick Dai: the development of technology with jumping, but difficult to retract, with the car, the car will never disappear, although the carriage also continued to exist for hundreds of years. The advent of cryptocurrency is not a coincidence, but is accompanied by the maturity of various internet infrastructures and the enlightenment of Cyber ​​punk movement concept. It belongs to the fusion of technology and thought, not just to technological innovation.
Personally, I think the cryptocurrency is unlikely to disappear, the widespread adoption of cryptocurrency depends on the applicability of the cryptocurrency system, including what rigid demands are being addressed, and for the moment, the greatest use is to provide people around the world an option: a very fluid Transparent, credible, secure global assets.
 
Q14: How to build a valuation model of blockchain platform?
Patrick Dai: I have sent an article before. At present, this is a big problem in the industry. We do not have a set of valuation system to realize early warning and assessment of risks. What is the valuation of a project? Before writing something for your reference. http://www.gongxiangcj.com/posts/3895 "The number of nodes and cryptocurrency valuation model."
 
Q15: Who is Nakamoto?
Patrick Dai: From what I learned, Nakamoto was a hardworking man with idealistic feelings. It should be done independently by one person. There are many anonymous tech bucks in IRC channel in 2011 and 2012, on which you can see Nakamoto's figure. In addition to the birth of BTC, there is also some relationship with a Chinese Wei Dai.
Wei Dai, who wrote Bmoney's paper before, Zhong Zhongcong and Wei Dai also had some emails, and mentioned to Wei Dai that he has implemented Bmoney's part of cryptoCurrency, but in the second part of Bmoney there is actually a tentative idea about the contract. We can refer to Wei Dai's thesis at http://www.weidai.com/bmoney.txt and Qtum's idea Wei Dai has had some simple email exchanges, but Wei Dai's interest is no longer in the circle of cryptocurrencies.
 
Q16: In all the coins, which one will live the longest?
Patrick Dai: simply look at cryptocurrencies, BTC completed a historic jump, but also a breakthrough from 0 to 1, followed by many cryptocurrencies are 1 to 1.1 and 1.1 to 1.2 changes, more than one billion US dollars in the amount of encrypted currency thoroughly It is unlikely that it will disappear because of the drive and governance of the community that the community will uphold even if the developer does not maintain it. However, there are indeed many crypto-currencies that will be eliminated and 95% of the projects should be gone after three years.
 
Q17: 18 years blockchain private market analysis, what kind of industry is better?
Patrick Dai: Currently the industry needs to find other applications in addition to the cryptocurrency killer app, from the technical development point of view, I personally trust the concept of trustless Platform constantly landing and provide the underlying technology research and development and application scenarios.
 
Q18: Which industry has the largest total of all the industries in the blockchain?
Patrick Dai: Cryptocurrency itself seems to be the biggest at this moment, and others feel that there are many opportunities for the gaming industry and for digital content (video and audio) and for financial services and the Internet of Things.
 
Q19: Want to hear the competition between the public chain and the public relations and cooperation, how to comment on the big brother?
Patrick Dai: last year's growth in the industry, in essence, we are still eating BTC created by the combination of technology and ideas, creating a human species in the history of a new species premium, BTC has its historic significance. The groundbreaking idea it brought, gradually attracted the public's attention, but from a technical point of view, what BTC can do is limited, but it does solve its positioning.
Technology is not good or bad, mainly to meet the needs. BTC technology to meet its point-to-point electronic cash system positioning and needs. We do not expect to build infinite applications in the BTC above, this is impossible. The public chain is indeed an open experimental field and a community-driven evolutionary community of interests. Its vitality is also very strong. However, at present, the problem is that we really need technological progress to further promote the scene. If only from the perspective of cryptocurrency, BTC LTC DogeCoin for a user, in essence, is the same experience, and the experience of Ethereum is not much different. The difference is, BTC and the US dollar experience is very different.
I personally feel that the blockchain industry is an ecology. Whether it is serving one of the areas in the blockchain and ultimately building a blockchain together, it is essentially a collaborative evolution that builds a stronger consensus mechanism. Diversity provides the basis for the choice of consensus, and if there is only one technical direction, then the evolution of technology has become slow. In addition this is only a technical factor, but the blockchain system is not only as simple as technology, there is community community of interests behind.
 
Q20: What dimensions are the most important when evaluating the value of a blockchain project? What factors can be rejected one vote?
The Beginning: The Essential Elements of the Encrypted Currency Valuation Model (I send some thoughts that I wrote before) As the first truly successful decentralized e-cash system, bitcoin became the anchor of value in the industry and By far the most centralized network, Bitcoin is designed as an electronic currency that is secure, secure, and has a very low threshold of participation in the early stages.
It is early everyone can participate, and become a full node without any threshold, anyone can download bitcoin client, early mining in his computer, so in fact the realization of the low threshold of the financial services system, everyone With the freedom to join and exit, bitcoin clients have been rapidly evolving early, and if the client is a game, the Bitcoin client's distribution is a borderless game.
In P2P network, a very important core element is full node. In a P2P network, the total number of nodes basically determines the technical value of this network.
 
Why do you say that?
In the traditional database domain and distributed system, we study the consistency of the data, there are already many, all major companies have their own solutions, but few companies have tens of thousands of distributed system distributed nodes, So most of the research results are more suitable for some enterprises to solve the solution. For example, the Paxos algorithm proposed by Leslie Lamport in 1990 can achieve highly fault-tolerant requirements based on message passing. The latter algorithm is also widely used in google Chubby lock, and Chubby lock behind is widely used in Google's core design Bigtable, bigtable is to support a lot of Google's core business.
 
The realization of Bitcoin network is a fusion of technology and humanity.
In a traditional distributed network, in a large company's network, each node in many cases is due to network reasons, dropping or sending wrong messages, instead of deliberately forging information for the sake of profit.
 
The realization of bitcoin is facing a more complicated network environment, not only a more complex network environment, but also a more complicated game of humanity. In the traditional distributed network, no one will consider the introduction of incentives to allow nodes to maintain data consistency, Nakamoto was the first person to do so, and through a resource that can not be monopolized (hash function computing power ) To ensure the effective allocation of accounting rights to avoid single-point ddos ​​attacks on specific accounting nodes.
 
Bitcoin network to each distributed node in the network, the consistency of each time slice into a time interval consistency, if you look at the global currency bitcoin network, you will find each time slice and time, different The miners in calculating the different chains, in fact, is a bifurcated network, but in a 10-minute time interval, the probability that the data is modified is a Poisson distribution. The probability of the attacker's success is q, The growth of the block is exponentially declining. When the blockchain has six acknowledgments, the attacker's probability of success tends to be essentially zero.
 
If you are the full node in a Bitcoin network, then you have the largest and equal rights to the network, and you no longer have to trust third parties or give up your rights to others. At present, many other cryptocurrencies tend to be centralized. Many consensus mechanisms realize a fast transaction processing speed. In essence, they deprive participants of their equal rights and allow the network to return to a centralized network. But if we really need to hand over our rights in the blockchain network, banks may be a better choice than a lot of centralized blockchain systems.
 
At present there are about 13,000 full nodes in the bitcoin network. Due to the characteristics of the p2p network, it is very difficult to accurately count the total number of nodes in the network. These 13000 full nodes bear the accounting of the distribution and transaction of currency, and are also bits The foundation of the currency. Bitcoin is definitely a more distributed clearing network than Alipay, and unlike Alipay, Alipay is just a payment instrument that serves the renminbi system. Bitcoin's global clearing network also has its own currency system --- Bitcoin Compared to a bank, opening a bitcoin "dot" actually requires only one computer to run a full node. Therefore, the final service boundary of Bitcoin is borderless, and the service objects of banks and Alipay have boundaries.
 
Bitcoin achieved a breakthrough from 0 to 1 and completed the carriage-to-car transition (steam engine). In fact, crypto-currencies appeared behind us. In fact, we made some improvements on the basis of Nakamoto. Indeed, we have not Take the carriage again, essentially all the cryptocurrencies are in the car.
 
If we look at bitcoin from a software science perspective rather than a currency perspective, the various cryptocurrencies that appear later are essentially improvements and enhancements based on bitcoin's open-source software, which many teams make And upgrading, and not much difference, whether it is to change a mining algorithm, or add some total, a lot of bifurcation is done from 1 to 1.001 experiment, bitcoin from paper currency to electronic currency from 0 To 1 transition and fission.
 
Today, Bitcoin has the strongest network effect and the loudest brand effect. Although the technology iteration is very, very slow, some progress has been made one after another, but it can not be surpassed from the aspect of things development. , But no matter whether it will be surpassed, the emergence of bitcoin has its historical inevitability and it will certainly accomplish its historic mission. As the world's largest distributed clearing network and built-in monetary system in the future, as well as the anchor of the value in the parallel financial world in the blockchain and the boost of crazy humanity, we predict where its future highs will be Speaking of other factors aside, cryptocurrency has opened up a new era in which its market value should surpass that of the previous wave of the Internet.
 
Question 21: Blockchain whether the future is required to apply for a license to do?
Patrick Dai: From the future development of cryptocurrency, this is an inevitable.
 
Question 22: The future of blockchain in the IP field?
Patrick Dai: This still need to solve the chain and chain problems, as well as integration with the existing legal system. But purely virtual assets may not be needed, such as audio and video saved in the art and electronic formats of game props and electronic designs. But no matter what kind of industry, we have to think about, in addition to the token premium liquidity brought us by the blockchain, the blockchain really helped solve what problems?
 
Q23: Now the real consumption of blockchain project is not much, why do not wait for the project landing, re-vote? Tencent like buying now is not too late. Estimated seed round billion reasonable?
Patrick Dai: revolutionary ideas and new technology has brought endless imagination mixed with human speculation and greed.
 
Q24: Want to know how to treat EOS Q1 beta?
Patrick Dai: the specific progress did not pay attention to too many details, each project has its own position, as long as the solution to a certain area or the general needs, I personally feel that are very valuable. But we also look at the duration of the project is also to our own positioning, if the measurement of time is one day, it is trader, if it is a month, it is a short-term speculators, if it is one year, in the block chain industry is long-term investors If it is three to five years or ten years, it's the value discoverer and the leader in technological change.
 
Q25: What kind of impact can blockchain have on the economic vitality of the third and fourth tier cities today? When will have an impact?
Patrick Dai: I do not know this.
 
 
Credit.Wang Jiehui
submitted by thisthingismud to Qtum [link] [comments]

Lore v2 QT on Raspberry Pi

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