Cost of a 51% Attack for Different Cryptocurrencies Crypto51

Dutch authorities have seized Bestmixer.io, a bitcoin mixing service.

Dutch authorities have seized Bestmixer.io, a bitcoin mixing service. submitted by mmeijeri to Bitcoin [link] [comments]

Bitcoin is the fake Skycoin

Satoshi Nakamoto said that biggest flaw in Bitcoin network are miners. That's because consensus algorithm, TX hash rate is dependent on miners calculation. Basically, we are consuming a lot of electricity to gather multiple tx in a block, in order to 3 Chinese mining pools can smash that block and take the Bitcoin reward. And if is not enough, the mining pools can inject fake tx in the network to clog it, so TX fees for us (peasants) will go higher.
  1. Why we are using hardware and electricity to create one block?
  2. Why Consensus algorithm is dependent on a new block creation?
  3. Where is the new Internet we all wanted back in 2009-2010 where millions of computer would be the network ?
https://medium.com/@Skycoinproject/cyberbalkanization-and-the-future-of-the-internets-f03f2b590c39
A) Skycoin is the bigger brother of Bitcoin. Early developers of Bitcoin knew that Miners will control the Bitcoin network in the future, so a part of them started to research a new Consensus Algorithm called Obeliskhttps://www.skycoin.net/blog/posts/obelisk-the-skycoin-consensus-algorithm/
B) Skycoin resolved 51% attack, sybil attack, has 0 TX fee, 1-2 sec for a tx , and is private. But the most important thing.
Skycoin is the only crypto out there who fixed the problem of volatility of a cryptocurrency. What's that ? Imagine if price of Skycoin goes higher and higher, peasants will ''HoDL'' it, so the term ''currency '' is lost. Why someone would spend an asset that goes higher and higher?
B1) One Skycoin kept in the wallet is creating non-stop a second currency called CoinHour. 1SKY is creating 24 CoinHours per day and so on. Coinhour is backed by bandwidth => Skywire(Software Defined Network) is the New Internet that gives Skycoin a real value, a commodity level value. https://www.youtube.com/watch?v=-CbSdVIwr8E
B2) In this ecosystem Skycoin behaves like an equity and CoinHour is the real currency. For example Skycoin Price can reach 1 million and the price of Coinhour is independent, its equilibrium is reached by supply and demand of the market https://explorer.skycoin.net/app/blocks/1
C) Ethereum has a buggy prog language and all shitcoins are on Ethereum Blockchain (Database) with only 30 tx/s. Why would someone would gather all the data on ONE Database?!
C1) Skycoin created CX ( first deterministic cryptographic prog language) https://www.skycoin.net/blog/posts/cx-overview/
C2) Skycoin created Fiber https://www.skycoin.net/fibe ( basically you can create your own blockchain with 300-3000 tx/s, private or public , with hardware customization ( law firms, government entities and so on as early adopters)
D) Skywire is the New Internet built at the Hardware and Software level
-Skywire is hardware agnostic
-Skywire has its DYI Antennas
- Skywire has FPGA boards
-Skyiwire has 10k nodes online ( more than TOR)
Bibliography:
  1. https://www.youtube.com/channel/UCMAS-n0SGseIZPxWuaQVFkg
  2. https://www.skycoin.net/downloads/
  3. https://www.skycoin.net/blog/

TLDR: one neighbor is rendering a movie. He wants 1 TB/ s. He will pay CoinHour to his neighbors to borrow bandwidth capacity of their sky clusters and antennas.
Skycoin Address : 25139AGYjwGwgKMZEA268GbJyXrZGWF533i
submitted by CaptainCuc to CryptoCurrency [link] [comments]

I think I just figured out how to beat the 51% attack, with no drawbacks

So the 51% attack has been a hot topic lately for obvious reasons. Not only that, I think it's THE topic on everyone's mind even if nobody is officially saying it. There is evidence here, here, here and I think even here...
The elephant nobody is acknowledging remains in the room. Accordingly I've been thinking of good defensive strategies a lot over these last days. The day before the fork I submitted an article outlining a new defense model:
https://www.reddit.com/btc/comments/9x5gmn/bitcoins_model_is_antiquated_moving_beyond/
For some reason it got zero upvotes (actually a downvote to zero) and no worthwhile discussion. Hopefully this submission fares better. I do think the defense I outlined is quite viable, but I acknowledge the costly move toward centralization. So I continued thinking of ways to further improve defense and I think I've got something that works without any added centralization pressure. It's surprisingly simple, with only two general changes being made.
First, there is a consensus rule change saying no node accepts a re-organization over 5 blocks long, at least, not without explicit manual override (useful in cases of unintentional chain splits). There shouldn't ever be a case where nodes suddenly learn of 6 or more blocks having valid rules and proper difficulty they were previously unaware of. The only situations where that would be expected is a bug creating a chain split, or an intentional hashpower attack to create disruption. As stated, an override can handle bugs, so the remaining issue should be edited out completely. This gives the ecosystem assurance that as often stated 6 confirmations means settlement certainty.
Astute observers will recognize an obvious problem: nodes attempting to sync won't ever be aware of rejected re-organizations since they would satisfy all chain requirements otherwise. This is easily resolved by having all nodes sync backwards. A node synchronizing from the highest block perceived from the network's perspective will include all rules of that network, including one rejecting lengthy real-time re-organizations.
So those are the only two changes to the way we currently do things, but 51% attacks are rendered impotent! As for where nodes get the highest block that's easy to accommodate. Nodes compatible with BIP 0064 (authored by Mike Hearn) already have access to 'chain height' and 'chain tip hash' when querying for UTXO lookups. Those return values coincide with the moment the result was calculated, though, so a better, explicitly most recent height and hash service might be preferable. Nodes then use the broadest consensus.
This does open the door slightly to Sybil attacks. However, an attacker would need to be working alongside the entity performing the broader re-org attack, and any harmful effects are limited to the effectively isolated and Sybil'd node(s). Since synchronization events are rare there might be a bootstrap 'sanity' list similar to the current DNS seed which is used to compare the information the node receives with IPs developers deem trustworthy (e.g. Bitcoin.com, BitPay etc), which would also defeat a Sybil attack.
The DoS portion of a 51% attack is also solvable with simple changes such as adding tx prority weighting (mentioned in my article) to determine the best chain.
submitted by cryptos4pz to btc [link] [comments]

FruitChains: A Fair Blockchain

Cryptology ePrint Archive: Report 2016/916
Date: 2017-05-05
Author(s): Rafael Pass, Elaine Shi

Link to Paper


Abstract
Nakamoto's famous blockchain protocol enables achieving consensus in a so-called permissionless setting---anyone can join (or leave) the protocol execution, and the protocol instructions do not depend on the identities of the players. His ingenious protocol prevents ``sybil attacks'' (where an adversary spawns any number of new players) by relying on computational puzzles (a.k.a. ``moderately hard functions') introduced by Dwork and Naor (Crypto'92). Recent work by Garay et al (EuroCrypt'15) and Pass et al (manuscript, 2016) demonstrate that this protocol provably achieves consistency and liveness assuming a) honest players control a majority of the computational power in the network, b) the puzzle-hardness is appropriately set as a function of the maximum network delay and the total computational power of the network, and c) the computational puzzle is modeled as a random oracle.
Assuming honest participation, however, is a strong assumption, especially in a setting where honest players are expected to perform a lot of work (to solve the computational puzzles). In Nakamoto's Bitcoin application of the blockchain protocol, players are incentivized to solve these puzzles by receiving rewards for every ``blocks'' (of transactions) they contribute to the blockchain. An elegant work by Eyal and Sirer (FinancialCrypt'14), strengthening and formalizing an earlier attack discussed on the Bitcoin forum, demonstrates that a coalition controlling even a minority fraction of the computational power in the network can gain (close to) 2 times its ``fair share'' of the rewards (and transation fees) by deviating from the protocol instructions. In contrast, in a fair protocol, one would expect that players controlling a ϕϕ fraction of the computational resources to reap a ϕϕ fraction of the rewards.
In this work, we present a new blockchain protocol---the FruitChain protocol---which satisfies the same consistency and liveness properties as Nakamoto's protocol (assuming an honest majority of the computing power), and additionally is δδ-approximately fair: with overwhelming probability, any honest set of players controlling a ϕϕ fraction of computational power is guaranteed to get at least a fraction (1−δ)ϕ(1−δ)ϕ of the blocks (and thus rewards) in any Omega(κ/δ)Omega(κ/δ) length segment of the chain (where κκ is the security parameter).
As a consequence, if this blockchain protocol is used as the ledger underlying a cryptocurrency system, where rewards and transaction fees are evenly distributed among the miners of blocks in a length kappa segment of the chain, no coalition controlling less than a majority of the computing power can gain more than a factor (1+3δ)(1+3δ) by deviating from the protocol (i.e., honest participation is an n/2n/2-coalition-safe 3δ3δ-Nash equilibrium).
Finally, the fruit chain protocol enables decreasing the variance of mining rewards and as such significantly lessens (or even obliterates) the need for mining pools.

References
[sol] http://www.coinwarz.com/calculators/bitcoin-mining-calculator.
[BCL+05] Boaz Barak, Ran Canetti, Yehuda Lindell, Rafael Pass, and Tal Rabin. Secure computation without authentication. In CRYPTO’05, 2005.
[BHP+] Iddo Bentov, Yuncong Hu, Rafael Pass, Elaine Shi, and Siqiu Yao. Decentralized pooled mining: An implementation of fruitchain. Manuscript.
[BPS16] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. Cryptology ePrint Archive, Report 2016/919, 2016. http://eprint.iacr.org/2016/919.
[CKWN16] Miles Carlsten, Harry A. Kalodner, S. Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016, pages 154–167, 2016.
[DN92] Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In CRYPTO’92, pages 139–147, 1992.
[ES14] Ittay Eyal and Emin G¨un Sirer. Majority is not enough: Bitcoin mining is vulnerable. In Financial Cryptography and Data Security, pages 436–454. Springer, 2014.
[GKL15] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In Advances in Cryptology-EUROCRYPT 2015, pages 281–310. Springer, 2015. 25
[HP15] Joseph Y. Halpern and Rafael Pass. Algorithmic rationality: Game theory with costly computation. J. Economic Theory, 156:246–268, 2015.
[KKKT16] Aggelos Kiayias, Elias Koutsoupias, Maria Kyropoulou, and Yiannis Tselekounis. Blockchain mining games. In Proceedings of the 2016 ACM Conference on Economics and Computation, EC ’16, pages 365–382, 2016.
[KP15] Aggelos Kiayias and Giorgos Panagiotakos. Speed-security tradeoffs in blockchain protocols, 2015.
[KP16] Aggelos Kiayias and Giorgos Panagiotakos. On trees, chains and fast transactions in the blockchain. IACR Cryptology ePrint Archive, 2016:545, 2016.
[KRDO16] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. Cryptology ePrint Archive, Report 2016/889, 2016. http://eprint.iacr.org/2016/889.
[LSZ15] Yoad Lewenberg, Yonatan Sompolinsky, and Aviv Zohar. Inclusive block chain protocols. In Financial Crypto’15, 2015.
[mtg10] mtgox. https://bitcointalk.org/index.php?topic=2227.msg29606#msg29606, 2010.
[Nak08] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
[NKMS16] Kartik Nayak, Srijan Kumar, Andrew Miller, and Elaine Shi. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack. In IEEE European Symposium on Security and Privacy, EuroS&P 2016, Saarbr¨ucken, Germany, March 21-24, 2016, pages 305–320, 2016.
[PSS17] Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in asynchronous networks. In Eurocrypt, 2017.
[PS16] Rafael Pass and Elaine Shi. Hybrid consensus. http://eprint.iacr.org/2016/917, 2016.
[SSZ16] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal selfish mining strategies in bitcoin. In Financial Crypto’16, 2016.
[SZ15] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In Financial Cryptography and Data Security - 19th International Conference, FC 2015, San Juan, Puerto Rico, January 26-30, 2015, Revised Selected Papers, pages 507–527, 2015.
submitted by dj-gutz to myrXiv [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]

ebakus: focusing on mass adoption

ebakus: focusing on mass adoption
It has been two years since we started working on ebakus and it’s time to start sharing more about it and why we came to build it. Ebakus is a smart contract enabled blockchain solution engineered for performance and accessibility

https://preview.redd.it/ugxpafxmjh331.png?width=1000&format=png&auto=webp&s=a2d005b59265edb22f8f15d7465571811718857f
So why do we need another blockchain?
It wasn’t a long ago since we decided to work on our own dApp, “a booking platform running on the blockchain”. As with any other project, we started by researching the available solutions to define our development stack. We were quite excited as the promise of decentralized unstoppable programs is a strong one!
Unfortunately, we quickly came to the conclusion that developing a truly decentralized application would not be easy because of the underlying limitations of solutions available at the time :
  • were inaccessible to uninitiated users and this would cause massive drop-offs with user acquisition, thus hurting our ROI. In order to interface with the blockchain, they required users to own a token balance to pay for fees or staking towards resources (CPU, Network, Power). Additionally, to store these tokens and use the special staking functionality they also required special wallets either in the form of browser plugins or third party software.
  • Developing decentalized Applications is quite hard. An economic model must be designed, data are always public and immutable and in most solutions, there is no Database available to handle and make operations with large datasets. Additionally, there are a lot of competing technologies all using their proprietary solutions. Different APIs, scripting languages, each with its own peculiarities and subpar support when compared to mature centralized solutions.
  • Low throughput and high latency will have a negative impact to the user experience and drastically impact the viability of any product that could surpass the previous hurdles and become popular.
As we were brainstorming on how to make it happen and as we researched how other teams do it, we thought of several solutions but all of them involved hybrid stacks that were sacrificing decentralization at best. For us, the whole point of getting into the trouble of building a decentralized application was for it to be unstoppable and decentralized, if we were to sacrifice that why not use traditional alternatives in the first place. It made no sense and that sent us to the drawing board with a different question: “There is an opportunity here, how can we make complex and decentralized Applications that remain accessible and unstoppable happen?”
“There should be no need for initial token balance or additional software in order to use a decentralized App.”
Enter ebakus
After a lot of funding and hype, the blockchain industry has yet to see a popular smart contract based decentralized application. Ebakus was designed to bring us a step closer to overcoming the hurdles and making this a reality.
For us, the biggest problem is making dApps accessible as it creates a chicken and egg problem for developers trying to make a return on their investment by targeting mass audiences. Since market penetration of the most popular tokens is less than 2% of the population we had to find a solution for the initial need for a token balance problem.
There should be no need for initial token balance or additional software to use a dApp.As mentioned before, blockchains are low throughput networks, which creates the need to have spam countermeasures. Essentially, they need a way to make it uneconomical for malicious users to spam the networks, to avoid these type of attacks (called Sybil attacks), they use fees adding a cost to each transaction. Alternatively, there is the model of staking, where tokens represent network resources and allow token holders upon locking them for a minimum period of time to utilize network resources in a pro-rata basis. Both of these solutions require a wallet and tokens which as we mentioned earlier is the root of the accessibility problem, that leads on bad user experience in decentralized applications (dApps).
Fees in ebakus — HINT: There aren’t any…
To solve this with ebakus, we had to reimagine fees. There should be a resource used to pay for fees that can be spent while remaining transparent to the end user. This resource in ebakus, is CPU. For a transaction to be accepted in the ebakus network, it requires a low difficulty proof of work to be performed. This proof of work only exists to make it uneconomical for attackers to spam the network and should be clear that doesn’t take part in the consensus in the way regular PoW does in bitcoin. It is important to take into account that the proof of work required for a transaction to be accepted is of low difficulty and doesn’t take more than 200ms in a modern mobile phone to be calculated. As the network gets congested, the target difficulty required for a transaction to be included into a block adjusts dynamically to higher targets, requiring more work to be done by clients. To allow accounts with less powerful CPUs interact with the blockchain and accounts that need to interact with transaction-intensive applications to still be usable under periods of congestion, the native token (EBK) can be optionally utilized through staking for a minimum period of 3 days and significantly less proof of work will be required for that account.
“By removing the needs for fees, in order to interact with the blockchain, we open up the remaining 98% of the market who don’t own any token balance or have no prior knowledge of blockchain technology.”
Removing the friction: no need for 3rd party software
Making users to download and install third-party software in order to be able to interact with the application logic is something that’s counterintuitive for users. It steepens the learning curve of the application and has them perform additional steps which often translates to further drop-offs during onboarding. Getting users’ attention is hard enough, having them jump through hoops before getting them hooked through providing them with value is problematic.
The wallet, if needed at all in the form we see it today, should be part of the dApp.
A lot of the more successful dApps nowadays have their own wallet implementations integrated into their dApps to remove this friction. For ebakus we have created a turnkey solution that allows devs to achieve just that and even better. Ebakus’ web wallet can also be shared between dApps resulting in users effectively using the same identity and credentials for all the ebakus based dApps they interact with. Moreover ebakus’ wallet solution is much better at removing the friction as it leverages the ebakus fee-less protocol to allow developers onboard users to their dApps in a highly efficient manner that is comparable or even better than their traditional counterparts.
By removing the need for plugins we remove the friction between the any dApp and its target audience. The user is not limited by device and/or platform.
Catering to developers
Being developers ourselves we strongly regard developers the primary persona to optimize ebakus for, as they are the primary value creators of this ecosystem in its early stages and their experience in building and monetising applications directly affects progress and mass adoption. We knew from the start, how important it would be for ebakus to be compatible and allow developers to build on their hard-earned skills so we kept it backwards compatible to Ethereum, the most popular smart contract platform at the time. Ethereum, while popular, is far from perfect though, lacking in performance and without a proper database to handle large datasets efficiently, deeply concerned us while making the initial architectural decisions. We built ebakus to use Delegated Proof of Stake (DPOS), that enables it to reach high throughput (23,000+ tps) with 1sec latency. Moreover, it leverages our proprietary transactional ebakusDB in its core, but also available inside the smart contracts to enable developers to have proper schema defined tables with indexes.
“Ebakus, by removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.”
If you are a developer working on a dApp and like us find these limitations are holding you back, stop reading and go check out Ebakus. On our website you will find our boilerplate and relevant documentation to get you started and you are always within reach on our discord and telegram channels.
Reach us at discord, telegram and twitter.
Ebakus is a blockchain solution designed for improved UX. By removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.
Originally published at https://medium.com/ebakus/ on May 08, 2019.
submitted by Kalima_Hils to cryptobots [link] [comments]

ebakus: focusing on mass adoption

ebakus: focusing on mass adoption
It has been two years since we started working on ebakus and it’s time to start sharing more about it and why we came to build it. Ebakus is a smart contract enabled blockchain solution engineered for performance and accessibility

https://preview.redd.it/7al7eqmrwh331.png?width=1000&format=png&auto=webp&s=0e1c29b7b3d942618ee8c2be499f93d1e822140b
So why do we need another blockchain?
It wasn’t a long ago since we decided to work on our own dApp, “a booking platform running on the blockchain”. As with any other project, we started by researching the available solutions to define our development stack. We were quite excited as the promise of decentralized unstoppable programs is a strong one!
Unfortunately, we quickly came to the conclusion that developing a truly decentralized application would not be easy because of the underlying limitations of solutions available at the time :
  • were inaccessible to uninitiated users and this would cause massive drop-offs with user acquisition, thus hurting our ROI. In order to interface with the blockchain, they required users to own a token balance to pay for fees or staking towards resources (CPU, Network, Power). Additionally, to store these tokens and use the special staking functionality they also required special wallets either in the form of browser plugins or third party software.
  • Developing decentalized Applications is quite hard. An economic model must be designed, data are always public and immutable and in most solutions, there is no Database available to handle and make operations with large datasets. Additionally, there are a lot of competing technologies all using their proprietary solutions. Different APIs, scripting languages, each with its own peculiarities and subpar support when compared to mature centralized solutions.
  • Low throughput and high latency will have a negative impact to the user experience and drastically impact the viability of any product that could surpass the previous hurdles and become popular.
As we were brainstorming on how to make it happen and as we researched how other teams do it, we thought of several solutions but all of them involved hybrid stacks that were sacrificing decentralization at best. For us, the whole point of getting into the trouble of building a decentralized application was for it to be unstoppable and decentralized, if we were to sacrifice that why not use traditional alternatives in the first place. It made no sense and that sent us to the drawing board with a different question: “There is an opportunity here, how can we make complex and decentralized Applications that remain accessible and unstoppable happen?”
“There should be no need for initial token balance or additional software in order to use a decentralized App.”
Enter ebakus
After a lot of funding and hype, the blockchain industry has yet to see a popular smart contract based decentralized application. Ebakus was designed to bring us a step closer to overcoming the hurdles and making this a reality.
For us, the biggest problem is making dApps accessible as it creates a chicken and egg problem for developers trying to make a return on their investment by targeting mass audiences. Since market penetration of the most popular tokens is less than 2% of the population we had to find a solution for the initial need for a token balance problem.
There should be no need for initial token balance or additional software to use a dApp.As mentioned before, blockchains are low throughput networks, which creates the need to have spam countermeasures. Essentially, they need a way to make it uneconomical for malicious users to spam the networks, to avoid these type of attacks (called Sybil attacks), they use fees adding a cost to each transaction. Alternatively, there is the model of staking, where tokens represent network resources and allow token holders upon locking them for a minimum period of time to utilize network resources in a pro-rata basis. Both of these solutions require a wallet and tokens which as we mentioned earlier is the root of the accessibility problem, that leads on bad user experience in decentralized applications (dApps).
Fees in ebakus — HINT: There aren’t any…
To solve this with ebakus, we had to reimagine fees. There should be a resource used to pay for fees that can be spent while remaining transparent to the end user. This resource in ebakus, is CPU. For a transaction to be accepted in the ebakus network, it requires a low difficulty proof of work to be performed. This proof of work only exists to make it uneconomical for attackers to spam the network and should be clear that doesn’t take part in the consensus in the way regular PoW does in bitcoin. It is important to take into account that the proof of work required for a transaction to be accepted is of low difficulty and doesn’t take more than 200ms in a modern mobile phone to be calculated. As the network gets congested, the target difficulty required for a transaction to be included into a block adjusts dynamically to higher targets, requiring more work to be done by clients. To allow accounts with less powerful CPUs interact with the blockchain and accounts that need to interact with transaction-intensive applications to still be usable under periods of congestion, the native token (EBK) can be optionally utilized through staking for a minimum period of 3 days and significantly less proof of work will be required for that account.
“By removing the needs for fees, in order to interact with the blockchain, we open up the remaining 98% of the market who don’t own any token balance or have no prior knowledge of blockchain technology.”
Removing the friction: no need for 3rd party software
Making users to download and install third-party software in order to be able to interact with the application logic is something that’s counterintuitive for users. It steepens the learning curve of the application and has them perform additional steps which often translates to further drop-offs during onboarding. Getting users’ attention is hard enough, having them jump through hoops before getting them hooked through providing them with value is problematic.
The wallet, if needed at all in the form we see it today, should be part of the dApp.
A lot of the more successful dApps nowadays have their own wallet implementations integrated into their dApps to remove this friction. For ebakus we have created a turnkey solution that allows devs to achieve just that and even better. Ebakus’ web wallet can also be shared between dApps resulting in users effectively using the same identity and credentials for all the ebakus based dApps they interact with. Moreover ebakus’ wallet solution is much better at removing the friction as it leverages the ebakus fee-less protocol to allow developers onboard users to their dApps in a highly efficient manner that is comparable or even better than their traditional counterparts.
By removing the need for plugins we remove the friction between the any dApp and its target audience. The user is not limited by device and/or platform.
Catering to developers
Being developers ourselves we strongly regard developers the primary persona to optimize ebakus for, as they are the primary value creators of this ecosystem in its early stages and their experience in building and monetising applications directly affects progress and mass adoption. We knew from the start, how important it would be for ebakus to be compatible and allow developers to build on their hard-earned skills so we kept it backwards compatible to Ethereum, the most popular smart contract platform at the time. Ethereum, while popular, is far from perfect though, lacking in performance and without a proper database to handle large datasets efficiently, deeply concerned us while making the initial architectural decisions. We built ebakus to use Delegated Proof of Stake (DPOS), that enables it to reach high throughput (23,000+ tps) with 1sec latency. Moreover, it leverages our proprietary transactional ebakusDB in its core, but also available inside the smart contracts to enable developers to have proper schema defined tables with indexes.
“Ebakus, by removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.”
If you are a developer working on a dApp and like us find these limitations are holding you back, stop reading and go check out Ebakus. On our website you will find our boilerplate and relevant documentation to get you started and you are always within reach on our discord and telegram channels.
Reach us at discord, telegram and twitter.
Ebakus is a blockchain solution designed for improved UX. By removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.
Originally published at https://medium.com/ebakus/ on May 08, 2019.
submitted by Kalima_Hils to ICOAnalysis [link] [comments]

ebakus: focusing on mass adoption

ebakus: focusing on mass adoption
It has been two years since we started working on ebakus and it’s time to start sharing more about it and why we came to build it. Ebakus is a smart contract enabled blockchain solution engineered for performance and accessibility

https://preview.redd.it/6kpw8mgpsh331.png?width=1000&format=png&auto=webp&s=d5203b9b714ce374b33aeff79cb3fdc4b9447da9
So why do we need another blockchain?
It wasn’t a long ago since we decided to work on our own dApp, “a booking platform running on the blockchain”. As with any other project, we started by researching the available solutions to define our development stack. We were quite excited as the promise of decentralized unstoppable programs is a strong one!
Unfortunately, we quickly came to the conclusion that developing a truly decentralized application would not be easy because of the underlying limitations of solutions available at the time :
  • were inaccessible to uninitiated users and this would cause massive drop-offs with user acquisition, thus hurting our ROI. In order to interface with the blockchain, they required users to own a token balance to pay for fees or staking towards resources (CPU, Network, Power). Additionally, to store these tokens and use the special staking functionality they also required special wallets either in the form of browser plugins or third party software.
  • Developing decentalized Applications is quite hard. An economic model must be designed, data are always public and immutable and in most solutions, there is no Database available to handle and make operations with large datasets. Additionally, there are a lot of competing technologies all using their proprietary solutions. Different APIs, scripting languages, each with its own peculiarities and subpar support when compared to mature centralized solutions.
  • Low throughput and high latency will have a negative impact to the user experience and drastically impact the viability of any product that could surpass the previous hurdles and become popular.
As we were brainstorming on how to make it happen and as we researched how other teams do it, we thought of several solutions but all of them involved hybrid stacks that were sacrificing decentralization at best. For us, the whole point of getting into the trouble of building a decentralized application was for it to be unstoppable and decentralized, if we were to sacrifice that why not use traditional alternatives in the first place. It made no sense and that sent us to the drawing board with a different question: “There is an opportunity here, how can we make complex and decentralized Applications that remain accessible and unstoppable happen?”
“There should be no need for initial token balance or additional software in order to use a decentralized App.”
Enter ebakus
After a lot of funding and hype, the blockchain industry has yet to see a popular smart contract based decentralized application. Ebakus was designed to bring us a step closer to overcoming the hurdles and making this a reality.
For us, the biggest problem is making dApps accessible as it creates a chicken and egg problem for developers trying to make a return on their investment by targeting mass audiences. Since market penetration of the most popular tokens is less than 2% of the population we had to find a solution for the initial need for a token balance problem.
There should be no need for initial token balance or additional software to use a dApp.As mentioned before, blockchains are low throughput networks, which creates the need to have spam countermeasures. Essentially, they need a way to make it uneconomical for malicious users to spam the networks, to avoid these type of attacks (called Sybil attacks), they use fees adding a cost to each transaction. Alternatively, there is the model of staking, where tokens represent network resources and allow token holders upon locking them for a minimum period of time to utilize network resources in a pro-rata basis. Both of these solutions require a wallet and tokens which as we mentioned earlier is the root of the accessibility problem, that leads on bad user experience in decentralized applications (dApps).
Fees in ebakus — HINT: There aren’t any…
To solve this with ebakus, we had to reimagine fees. There should be a resource used to pay for fees that can be spent while remaining transparent to the end user. This resource in ebakus, is CPU. For a transaction to be accepted in the ebakus network, it requires a low difficulty proof of work to be performed. This proof of work only exists to make it uneconomical for attackers to spam the network and should be clear that doesn’t take part in the consensus in the way regular PoW does in bitcoin. It is important to take into account that the proof of work required for a transaction to be accepted is of low difficulty and doesn’t take more than 200ms in a modern mobile phone to be calculated. As the network gets congested, the target difficulty required for a transaction to be included into a block adjusts dynamically to higher targets, requiring more work to be done by clients. To allow accounts with less powerful CPUs interact with the blockchain and accounts that need to interact with transaction-intensive applications to still be usable under periods of congestion, the native token (EBK) can be optionally utilized through staking for a minimum period of 3 days and significantly less proof of work will be required for that account.
“By removing the needs for fees, in order to interact with the blockchain, we open up the remaining 98% of the market who don’t own any token balance or have no prior knowledge of blockchain technology.”
Removing the friction: no need for 3rd party software
Making users to download and install third-party software in order to be able to interact with the application logic is something that’s counterintuitive for users. It steepens the learning curve of the application and has them perform additional steps which often translates to further drop-offs during onboarding. Getting users’ attention is hard enough, having them jump through hoops before getting them hooked through providing them with value is problematic.
The wallet, if needed at all in the form we see it today, should be part of the dApp.
A lot of the more successful dApps nowadays have their own wallet implementations integrated into their dApps to remove this friction. For ebakus we have created a turnkey solution that allows devs to achieve just that and even better. Ebakus’ web wallet can also be shared between dApps resulting in users effectively using the same identity and credentials for all the ebakus based dApps they interact with. Moreover ebakus’ wallet solution is much better at removing the friction as it leverages the ebakus fee-less protocol to allow developers onboard users to their dApps in a highly efficient manner that is comparable or even better than their traditional counterparts.
By removing the need for plugins we remove the friction between the any dApp and its target audience. The user is not limited by device and/or platform.
Catering to developers
Being developers ourselves we strongly regard developers the primary persona to optimize ebakus for, as they are the primary value creators of this ecosystem in its early stages and their experience in building and monetising applications directly affects progress and mass adoption. We knew from the start, how important it would be for ebakus to be compatible and allow developers to build on their hard-earned skills so we kept it backwards compatible to Ethereum, the most popular smart contract platform at the time. Ethereum, while popular, is far from perfect though, lacking in performance and without a proper database to handle large datasets efficiently, deeply concerned us while making the initial architectural decisions. We built ebakus to use Delegated Proof of Stake (DPOS), that enables it to reach high throughput (23,000+ tps) with 1sec latency. Moreover, it leverages our proprietary transactional ebakusDB in its core, but also available inside the smart contracts to enable developers to have proper schema defined tables with indexes.
“Ebakus, by removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.”
If you are a developer working on a dApp and like us find these limitations are holding you back, stop reading and go check out Ebakus. On our website you will find our boilerplate and relevant documentation to get you started and you are always within reach on our discord and telegram channels.
Reach us at discord, telegram and twitter.
Ebakus is a blockchain solution designed for improved UX. By removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.
Originally published at https://medium.com/ebakus/ on May 08, 2019.
submitted by Kalima_Hils to airdrops [link] [comments]

ebakus: focusing on mass adoption

ebakus: focusing on mass adoption
It has been two years since we started working on ebakus and it’s time to start sharing more about it and why we came to build it. Ebakus is a smart contract enabled blockchain solution engineered for performance and accessibility

https://preview.redd.it/ek0hzjt16v331.png?width=1000&format=png&auto=webp&s=82d11d2d29cba3867019e71ed24bfcadb7c7e2f5
So why do we need another blockchain?
It wasn’t a long ago since we decided to work on our own dApp, “a booking platform running on the blockchain”. As with any other project, we started by researching the available solutions to define our development stack. We were quite excited as the promise of decentralized unstoppable programs is a strong one!
Unfortunately, we quickly came to the conclusion that developing a truly decentralized application would not be easy because of the underlying limitations of solutions available at the time :
  • were inaccessible to uninitiated users and this would cause massive drop-offs with user acquisition, thus hurting our ROI. In order to interface with the blockchain, they required users to own a token balance to pay for fees or staking towards resources (CPU, Network, Power). Additionally, to store these tokens and use the special staking functionality they also required special wallets either in the form of browser plugins or third party software.
  • Developing decentalized Applications is quite hard. An economic model must be designed, data are always public and immutable and in most solutions, there is no Database available to handle and make operations with large datasets. Additionally, there are a lot of competing technologies all using their proprietary solutions. Different APIs, scripting languages, each with its own peculiarities and subpar support when compared to mature centralized solutions.
  • Low throughput and high latency will have a negative impact to the user experience and drastically impact the viability of any product that could surpass the previous hurdles and become popular.
As we were brainstorming on how to make it happen and as we researched how other teams do it, we thought of several solutions but all of them involved hybrid stacks that were sacrificing decentralization at best. For us, the whole point of getting into the trouble of building a decentralized application was for it to be unstoppable and decentralized, if we were to sacrifice that why not use traditional alternatives in the first place. It made no sense and that sent us to the drawing board with a different question: “There is an opportunity here, how can we make complex and decentralized Applications that remain accessible and unstoppable happen?”
“There should be no need for initial token balance or additional software in order to use a decentralized App.”
Enter ebakus
After a lot of funding and hype, the blockchain industry has yet to see a popular smart contract based decentralized application. Ebakus was designed to bring us a step closer to overcoming the hurdles and making this a reality.
For us, the biggest problem is making dApps accessible as it creates a chicken and egg problem for developers trying to make a return on their investment by targeting mass audiences. Since market penetration of the most popular tokens is less than 2% of the population we had to find a solution for the initial need for a token balance problem.
There should be no need for initial token balance or additional software to use a dApp.As mentioned before, blockchains are low throughput networks, which creates the need to have spam countermeasures. Essentially, they need a way to make it uneconomical for malicious users to spam the networks, to avoid these type of attacks (called Sybil attacks), they use fees adding a cost to each transaction. Alternatively, there is the model of staking, where tokens represent network resources and allow token holders upon locking them for a minimum period of time to utilize network resources in a pro-rata basis. Both of these solutions require a wallet and tokens which as we mentioned earlier is the root of the accessibility problem, that leads on bad user experience in decentralized applications (dApps).
Fees in ebakus — HINT: There aren’t any…
To solve this with ebakus, we had to reimagine fees. There should be a resource used to pay for fees that can be spent while remaining transparent to the end user. This resource in ebakus, is CPU. For a transaction to be accepted in the ebakus network, it requires a low difficulty proof of work to be performed. This proof of work only exists to make it uneconomical for attackers to spam the network and should be clear that doesn’t take part in the consensus in the way regular PoW does in bitcoin. It is important to take into account that the proof of work required for a transaction to be accepted is of low difficulty and doesn’t take more than 200ms in a modern mobile phone to be calculated. As the network gets congested, the target difficulty required for a transaction to be included into a block adjusts dynamically to higher targets, requiring more work to be done by clients. To allow accounts with less powerful CPUs interact with the blockchain and accounts that need to interact with transaction-intensive applications to still be usable under periods of congestion, the native token (EBK) can be optionally utilized through staking for a minimum period of 3 days and significantly less proof of work will be required for that account.
“By removing the needs for fees, in order to interact with the blockchain, we open up the remaining 98% of the market who don’t own any token balance or have no prior knowledge of blockchain technology.”
Removing the friction: no need for 3rd party software
Making users to download and install third-party software in order to be able to interact with the application logic is something that’s counterintuitive for users. It steepens the learning curve of the application and has them perform additional steps which often translates to further drop-offs during onboarding. Getting users’ attention is hard enough, having them jump through hoops before getting them hooked through providing them with value is problematic.
The wallet, if needed at all in the form we see it today, should be part of the dApp.
A lot of the more successful dApps nowadays have their own wallet implementations integrated into their dApps to remove this friction. For ebakus we have created a turnkey solution that allows devs to achieve just that and even better. Ebakus’ web wallet can also be shared between dApps resulting in users effectively using the same identity and credentials for all the ebakus based dApps they interact with. Moreover ebakus’ wallet solution is much better at removing the friction as it leverages the ebakus fee-less protocol to allow developers onboard users to their dApps in a highly efficient manner that is comparable or even better than their traditional counterparts.
By removing the need for plugins we remove the friction between the any dApp and its target audience. The user is not limited by device and/or platform.
Catering to developers
Being developers ourselves we strongly regard developers the primary persona to optimize ebakus for, as they are the primary value creators of this ecosystem in its early stages and their experience in building and monetising applications directly affects progress and mass adoption. We knew from the start, how important it would be for ebakus to be compatible and allow developers to build on their hard-earned skills so we kept it backwards compatible to Ethereum, the most popular smart contract platform at the time. Ethereum, while popular, is far from perfect though, lacking in performance and without a proper database to handle large datasets efficiently, deeply concerned us while making the initial architectural decisions. We built ebakus to use Delegated Proof of Stake (DPOS), that enables it to reach high throughput (23,000+ tps) with 1sec latency. Moreover, it leverages our proprietary transactional ebakusDB in its core, but also available inside the smart contracts to enable developers to have proper schema defined tables with indexes.
“Ebakus, by removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.”
If you are a developer working on a dApp and like us find these limitations are holding you back, stop reading and go check out Ebakus. On our website you will find our boilerplate and relevant documentation to get you started and you are always within reach on our discord and telegram channels.
Reach us at discord, telegram and twitter.
Ebakus is a blockchain solution designed for improved UX. By removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.
Originally published at https://medium.com/ebakus/ on May 08, 2019.
submitted by Kalima_Hils to cryptoall [link] [comments]

ebakus: focusing on mass adoption

ebakus: focusing on mass adoption
It has been two years since we started working on ebakus and it’s time to start sharing more about it and why we came to build it. Ebakus is a smart contract enabled blockchain solution engineered for performance and accessibility

https://preview.redd.it/bip9213v5v331.png?width=1000&format=png&auto=webp&s=d4e63c84e896c5e818555f5adb08bdde9f16b57d
So why do we need another blockchain?
It wasn’t a long ago since we decided to work on our own dApp, “a booking platform running on the blockchain”. As with any other project, we started by researching the available solutions to define our development stack. We were quite excited as the promise of decentralized unstoppable programs is a strong one!
Unfortunately, we quickly came to the conclusion that developing a truly decentralized application would not be easy because of the underlying limitations of solutions available at the time :
  • were inaccessible to uninitiated users and this would cause massive drop-offs with user acquisition, thus hurting our ROI. In order to interface with the blockchain, they required users to own a token balance to pay for fees or staking towards resources (CPU, Network, Power). Additionally, to store these tokens and use the special staking functionality they also required special wallets either in the form of browser plugins or third party software.
  • Developing decentalized Applications is quite hard. An economic model must be designed, data are always public and immutable and in most solutions, there is no Database available to handle and make operations with large datasets. Additionally, there are a lot of competing technologies all using their proprietary solutions. Different APIs, scripting languages, each with its own peculiarities and subpar support when compared to mature centralized solutions.
  • Low throughput and high latency will have a negative impact to the user experience and drastically impact the viability of any product that could surpass the previous hurdles and become popular.
As we were brainstorming on how to make it happen and as we researched how other teams do it, we thought of several solutions but all of them involved hybrid stacks that were sacrificing decentralization at best. For us, the whole point of getting into the trouble of building a decentralized application was for it to be unstoppable and decentralized, if we were to sacrifice that why not use traditional alternatives in the first place. It made no sense and that sent us to the drawing board with a different question: “There is an opportunity here, how can we make complex and decentralized Applications that remain accessible and unstoppable happen?”
“There should be no need for initial token balance or additional software in order to use a decentralized App.”
Enter ebakus
After a lot of funding and hype, the blockchain industry has yet to see a popular smart contract based decentralized application. Ebakus was designed to bring us a step closer to overcoming the hurdles and making this a reality.
For us, the biggest problem is making dApps accessible as it creates a chicken and egg problem for developers trying to make a return on their investment by targeting mass audiences. Since market penetration of the most popular tokens is less than 2% of the population we had to find a solution for the initial need for a token balance problem.
There should be no need for initial token balance or additional software to use a dApp.As mentioned before, blockchains are low throughput networks, which creates the need to have spam countermeasures. Essentially, they need a way to make it uneconomical for malicious users to spam the networks, to avoid these type of attacks (called Sybil attacks), they use fees adding a cost to each transaction. Alternatively, there is the model of staking, where tokens represent network resources and allow token holders upon locking them for a minimum period of time to utilize network resources in a pro-rata basis. Both of these solutions require a wallet and tokens which as we mentioned earlier is the root of the accessibility problem, that leads on bad user experience in decentralized applications (dApps).
Fees in ebakus — HINT: There aren’t any…
To solve this with ebakus, we had to reimagine fees. There should be a resource used to pay for fees that can be spent while remaining transparent to the end user. This resource in ebakus, is CPU. For a transaction to be accepted in the ebakus network, it requires a low difficulty proof of work to be performed. This proof of work only exists to make it uneconomical for attackers to spam the network and should be clear that doesn’t take part in the consensus in the way regular PoW does in bitcoin. It is important to take into account that the proof of work required for a transaction to be accepted is of low difficulty and doesn’t take more than 200ms in a modern mobile phone to be calculated. As the network gets congested, the target difficulty required for a transaction to be included into a block adjusts dynamically to higher targets, requiring more work to be done by clients. To allow accounts with less powerful CPUs interact with the blockchain and accounts that need to interact with transaction-intensive applications to still be usable under periods of congestion, the native token (EBK) can be optionally utilized through staking for a minimum period of 3 days and significantly less proof of work will be required for that account.
“By removing the needs for fees, in order to interact with the blockchain, we open up the remaining 98% of the market who don’t own any token balance or have no prior knowledge of blockchain technology.”
Removing the friction: no need for 3rd party software
Making users to download and install third-party software in order to be able to interact with the application logic is something that’s counterintuitive for users. It steepens the learning curve of the application and has them perform additional steps which often translates to further drop-offs during onboarding. Getting users’ attention is hard enough, having them jump through hoops before getting them hooked through providing them with value is problematic.
The wallet, if needed at all in the form we see it today, should be part of the dApp.
A lot of the more successful dApps nowadays have their own wallet implementations integrated into their dApps to remove this friction. For ebakus we have created a turnkey solution that allows devs to achieve just that and even better. Ebakus’ web wallet can also be shared between dApps resulting in users effectively using the same identity and credentials for all the ebakus based dApps they interact with. Moreover ebakus’ wallet solution is much better at removing the friction as it leverages the ebakus fee-less protocol to allow developers onboard users to their dApps in a highly efficient manner that is comparable or even better than their traditional counterparts.
By removing the need for plugins we remove the friction between the any dApp and its target audience. The user is not limited by device and/or platform.
Catering to developers
Being developers ourselves we strongly regard developers the primary persona to optimize ebakus for, as they are the primary value creators of this ecosystem in its early stages and their experience in building and monetising applications directly affects progress and mass adoption. We knew from the start, how important it would be for ebakus to be compatible and allow developers to build on their hard-earned skills so we kept it backwards compatible to Ethereum, the most popular smart contract platform at the time. Ethereum, while popular, is far from perfect though, lacking in performance and without a proper database to handle large datasets efficiently, deeply concerned us while making the initial architectural decisions. We built ebakus to use Delegated Proof of Stake (DPOS), that enables it to reach high throughput (23,000+ tps) with 1sec latency. Moreover, it leverages our proprietary transactional ebakusDB in its core, but also available inside the smart contracts to enable developers to have proper schema defined tables with indexes.
“Ebakus, by removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.”
If you are a developer working on a dApp and like us find these limitations are holding you back, stop reading and go check out Ebakus. On our website you will find our boilerplate and relevant documentation to get you started and you are always within reach on our discord and telegram channels.
Reach us at discord, telegram and twitter.
Ebakus is a blockchain solution designed for improved UX. By removing the initial friction, increasing performance, being backwards compatible and powered by ebakusDB, enables developers to create dApps more powerful than ever before that can reach mass adoption.
Originally published at https://medium.com/ebakus/ on May 08, 2019.
submitted by Kalima_Hils to ico [link] [comments]

Great interview questions for bitcoin engineers

From here...
https://bitcointalk.org/index.php?topic=5006583.0
Questions. Chapter 1: Introduction 1. What are the main Bitcoin terms? 2. What is a Bitcoin address? 3. What is a Bitcoin transaction? 4. What is a Bitcoin block? 5. What is a Bitcoin blockchain? 6. What is a Bitcoin transaction ledger? 7. What is a Bitcoin system? What is a bitcoin (cryptocurrency)? How are they different? 8. What is a full Bitcoin stack? 9. What are two types of issues that digital money have to address? 10. What is a “double-spend” problem? 11. What is a distributed computing problem? What is the other name of this problem? 12. What is an election? 13. What is a consensus? 14. What is the name of the main algorithm that brings the bitcoin network to the consensus? 15. What are the different types of bitcoin clients? What is the difference between these clients? Which client offers the most flexibility? Which client offers the least flexibility? Which client is the most and least secure? 16. What is a bitcoin wallet? 17. What is a confirmed transaction and what is an unconfirmed transaction? Chapter 2: How Bitcoin works. 1. What is the best way to understand transactions in the Bitcoin network? 2. What is a transaction? What does it contain? What is the similarity of a transaction to a double entry ledger? What does input correspond to? What does output correspond to? 3. What are the typical transactions in the bitcoin network? Could you please name three of such transactions and give examples of each type of the transaction? 4. What is a QR and how it is used in the Bitcoin network? Are there different types of QRs? If so, what are the different types? Which type is more informational? What kind of information does it provide? 5. What is SPV? What does this procedure check and what type of clients of the Bitcoin network usually use this procedure? Chapter 3: The Bitcoin client. 1. How to download and install the Core Bitcoin client? 2. What is the best way to test the API available for the Core Bitcoin client without actually programming? What is the interface called? 3. What are the major areas of operations in the Bitcoin client? What can we do with the client? 4. What are the available operations for the Bitcoin addresses? 5. What are the available read operations for the Bitcoin transactions? How is a transaction encoded in the Bitcoin network? What is a raw transaction and what is a decoded transaction? 6. If I want to get information about a transaction that is not related to any address in my own wallet, do I need to change anything in the Bitcoin client configuration? If yes, which option do I need to modify? 7. What are the available read operation for the Bitcoin blocks? 8. What are the available operations for the creation of the transactions in the Bitcoin network? 9. How do you normally need to address the unspent output from the previous transaction in order to use it as an input for a new transaction? 10. What is the mandatory operation after creating a new transaction and before sending this new transaction to the network? What state does the wallet have to be in order to perform this operation? 11. Is the transaction ID immutable (TXID)? If not why, if yes, why and when? 12. What does signing a transaction mean? 13. What are the other options for Bitcoin clients? Are there any libraries that are written for some specific languages? What types of clients do these libraries implement? Chapter 4: Keys, Addresses and Wallets. 1. What is a PKC? When it was developed? What are the main mathematical foundations or functions that PKC is using? 2. What is ECC? Could you please provide the formula of the EC? What is the p and what is the Fp? What are the defined operations in ECC? What is a “point to infinity”? 3. What is a Bitcoin wallet? Does this wallet contain coins? If not, what does it contain then? 4. What is a BIP? What it is used for? 5. What is an encrypted private key? Why would we want to encrypt private keys? 6. What is a paper wallet? What kind of storage it is an example of? 7. What is a nondeterministic wallet? Is it a good wallet or a bad wallet? Could you justify? 8. What is a deterministic wallet? 9. What is an HD wallet? 10. How many keys are needed for one in and out transaction? What is a key pair? Which keys are in the key pair? 11. How many keys are stored in a wallet? 12. How does a public key gets created in Bitcoin? What is a “generator point”? 13. Could you please show on a picture how ECC multiplication is done? 14. How does a private key gets created in Bitcoin? What we should be aware of when creating a new private key? What is CSPRNG? What kind of input should this function be getting? 15. What is a WIF? What is WIF-Compressed? 16. What is Base58 encoding and what is Base58Check encoding? How it is different from Base64 encoding? Which characters are used in Base58? Why Base58Check was invented? What kind of problems does it solve? How is Base58Check encoding is created from Base58 encoding? 17. How can Bitcoin addresses be encoded? Which different encodings are used? Which key is used for the address creation? How is the address created? How this key is used and what is the used formula? 18. Can we visually distinguish between different keys in Base58Check format? If yes, how are they different from each other? What kind of prefixes are used? Could you please provide information about used prefixes for each type of the key? 19. What is an index in HD wallets? How many siblings can exist for a parent in an HD wallet? 20. What is the depth limitation for an HD wallet key hierarchy? 21. What are the main two advantages of an HD wallet comparing to the nondeterministic wallets? 22. What are the risks of non-hardened keys creation in an HD wallet? Could you please describe each of them? 23. What is a chain code in HD wallets? How many different chain code types there are? 24. What is the mnemonic code words? What are they used for? 25. What is a seed in an HD wallet? Is there any other name for it? 26. What is an extended key? How long is it and which parts does it consist of? 27. What is P2SH address? What function are P2SH addresses normally used for? Is that correct to call P2SH address a multi-sig address? Which BIP suggested using P2SH addresses? 28. What is a WIF-compressed private key? Is there such a thing as a compressed private key? Is there such a thing as a compressed public key? 29. What is a vanity address? 30. What is a vanity pool? 31. What is a P2PKH address? What is the prefix for the P2PKH address? 32. How does the owner prove that he is the real owner of some address? What does he have to represent to the network to prove the ownership? Why a perpetrator cannot copy this information and reuse it in the next transactions? 33. What is the rule for using funds that are secured by a cold storage wallet? How many times you can send to the address that is protected by the private key stored in a cold storage? How many times can you send funds from the address that is protected by the private key stored in a cold storage? Chapter 5: Transactions. 1. What is a transaction in Bitcoin? Why is it the most important operation in the Bitcoin ecosystem? 2. What is UTXO? What is one of the important rules of the UTXO? 3. Which language is used to write scripts in Bitcoin ecosystem? What are the features of this language? Which language does it look like? What are the limitations of this language? 4. What is the structure of a transaction? What does transaction consists of? 5. What are the standard transactions in Bitcoin? How many standard transactions there are (as of 2014)? 6. What is a “locking script” and what is an “unlocking script”? What is inside these scripts for a usual operation of P2PKH? What is a signature? Could you please describe in details how locking and unlocking scripts work and draw the necessary diagrams? 7. What is a transaction fee? What does the transaction fee depend on? 8. If you are manually creating transactions, what should you be very careful about? 9. Could you please provide a real life scenario when you might need a P2SH payment and operation? 10. What is the Script operation that is used to store in the blockchain some important data? Is it a good practice? Explain your answer. Chapter 6: The Bitcoin Network. 1. What is the network used in Bitcoin? What is it called? What is the abbreviation? What is the difference between this network architecture and the other network architectures? Could you please describe another network architecture and compare the Bitcoin network and the other network architectures? 2. What is a Bitcoin network? What is an extended Bitcoin network? What is the difference between those two networks? What are the other protocols used in the extended Bitcoin network? Why are these new protocols used? Can you give an example of one such protocol? What is it called? 3. What are the main functions of a bitcoin node? How many of them there are? Could you please name and describe each of them? Which functions are mandatory? 4. What is a full node in the Bitcoin network? What does it do and how does it differ from the other nodes? 5. What is a lightweight node in the Bitcoin network? What is another name of the lightweight node? How lightweight node checks transactions? 6. What are the main problems in the SPV process? What does SPV stand for? How does SPV work and what does it rely on? 7. What is a Sybil attack? 8. What is a transaction pool? Where are transaction pools stored in a Bitcoin network client? What are the two different transaction pools usually available in implementations? 9. What is the main Bitcoin client used in the network? What is the official name of the client and what is an unofficial name of this client? 10. What is UTXO pool? Do all clients keep this pool? Where is it stored? How does it differ from the transaction pools? 11. What is a Bloom filter? Why are Bloom filters used in the Bitcoin network? Were they originally used in the initial SW or were they introduced with a specific BIP? Chapter 7: The Blockchain. 1. What is a blockchain? 2. What is a block hash? Is it really a block hash or is it a hash of something else? 3. What is included in the block? What kind of information? 4. How many parents can one block have? 5. How many children can one block have? Is it a temporary or permanent state of the blockchain? What is the name of this state of the blockchain? 6. What is a Merkle tree? Why does Bitcoin network use Merkle trees? What is the advantage of using Merkle trees? What is the other name of the Merkle tree? What kind of form must this tree have? 7. How are blocks identified in the blockchain? What are the two commonly used identities? Are these identities stored in the blockchain? 8. What is the average size of one transaction? How many transactions are normally in one block? What is the size of a block header? 9. What kind of information do SPV nodes download? How much space do they save by that comparing to what they would need if they had to download the whole blockchain? 10. What is a usual representation of a blockchain? 11. What is a genesis block? Do clients download this block and if yes – where from? What is the number of the genesis block? 12. What is a Merkle root? What is a Merkle path? Chapter 8: Mining and Consensus. 1. What is the main purpose of mining? Is it to get the new coins for the miners? Alternatively, it is something else? Is mining the right or good term to describe the process? 2. What is PoW algorithm? 3. What are the two main incentives for miners to participate in the Bitcoin network? What is the current main incentive and will it be changed in the future? 4. Is the money supply in the Bitcoin network diminishing? If so, what is the diminishing rate? What was the original Bitcoin supply rate and how is it changed over time? Is the diminishing rate time related or rather block related? 5. What is the maximum number of Bitcoins available in the network after all the Bitcoins have been mined? When will all the Bitcoins be mined? 6. What is a decentralized consensus? What is a usual setup to clear transactions? What does a clearinghouse do? 7. What is deflationary money? Are they good or bad usually? What is the bad example of deflationary spiral? 8. What is an emergent consensus? What is the feature of emergent consensus? How does it differ from a usual consensus? What are the main processes out of which this emergent decentralized consensus becomes true? 9. Could you please describe the process of Independent Transaction Verification? What is the list of criteria that are checked against a newly received transaction? Where can these rules be checked? Can they be changed over time? If yes, why would they be changed? 10. Does mining node have to be a full node? If not, what are the other options for a node that is not full to be a mining node? 11. What is a candidate block? What types of nodes in the Bitcoin network create candidate blocks? What is a memory pool? Is there any other name of the memory pool? What are the transactions kept in this memory pool? 12. How are transactions added to the candidate block? How does a candidate block become a valid block? 13. What is the minimum value in the Bitcoin network? What is it called and what is the value? Are there any alternative names? 14. What is the age of the UTXO? 15. How is the priority of a transaction is calculated? What is the exact formula? What are the units of each contributing member? When is a transaction considered to be old? Can low priority transactions carry a zero fee? Will they be processed in this case? 16. How much size in each block is reserved for high priority transactions? How are transactions prioritized for the remaining space? 17. Do transactions expire in Bitcoin? Can transactions disappear in the Bitcoin network? If yes, could you please describe such scenario? 18. What is a generation transaction? Does it have another name? If it does, what is the other name of the transaction? What is the position of the generation transaction in the block? Does it have an input? Is the input usual UTXO? If not – what is the input called? How many outputs there are for the generation transaction? 19. What is the Coinbase data? What is it currently used for? 20. What is little-endian and big-endian formats? Could you please give an example of both? 21. How is the block header constructed? Which fields are calculated and added to the block header? Could you please describe the steps for calculation of the block header fields? 22. What is a mantissa-exponent encoding? How is this encoding used in the Bitcoin network? What is the difficulty target? What is the actual process of mining? What kind of mathematical calculation is executed to conduct mining? 23. Which hash function is used in the Bitcoin mining process? 24. Could you describe the PoW algorithm? What features of the hash function does it depend on? What is the other name of the hash function? What is a nonce? How can we increase the difficulty of the PoW calculation? What do we need to change and how do we need to change this parameter? 25. What is difficulty bits notation? Could you please describe in details how it works? What is the formula for the difficulty notation? 26. Why is difficulty adjustable? Who adjusts it and how exactly? Where is the adjustment made? On which node? How many blocks are taken into consideration to predict the next block issuance rate? What is the change limitation? Does the target difficulty depend on the number of transactions? 27. How is a new block propagated in the network? What kind of verification does each node do? What is the list of criteria for the new block? What kind of process ensures that the miners do not cheat? 28. How does a process of block assembly work? What are the sets of blocks each full node have? Could you please describe these sets of blocks? 29. What is a secondary chain? What does each node do to check this chain and perhaps to promote it to the primary chain? Could you please describe an example when a fork occurs and what happens? 30. How quickly forks are resolved most of the time? Within how many new block periods? 31. Why the next block is generated within 10 minutes from the previous? What is this compromise about? What do designers of the Bitcoin network thought about when implementing this rule? 32. What is a hashing race? How did Bitcoin hashing capacity has changed within years from inception? What kind of hardware devices were initially used and how did the HW utilization evolved? What kind of hardware is used now to do mining? How has the network difficulty improved? 33. What is the size of the field that stores nonce in the block header? What is the limitation and problem of the nonce? Why was an extra nonce created? Was there any intermediate solution? If yes, what was the solution? What are the limitations of the solution? 34. What is the exact solution for the extra nonce? Where does the new space come from? How much space is currently used and what is the range of the extra nonce now? 35. What is a mining pool? Why was it created? How are normally such pools operated? Do they pay regularly to the pool participants? Where are newly created Bitcoins distributed? To which address? How do mining pools make money? How do the mining pools calculate the participation? How are shares earned calculated? 36. What is a managed pool? How is the owner of the pool called? Do pool members need to run full nodes? Explain why or why not? 37. What are the most famous protocols used to coordinate pool activities? What is a block template? How is it used? 38. What is the limitation of a centralized pool? Is there any alternative? If yes, what is it? How is it called? How does it work? 39. What is a consensus attack? What is the main assumption of the Bitcoin network? What can be the targets of the consensus attacks? What can these attacks do and what they cannot do? How much overall capacity of the network do you have to control to exercise a consensus attack? Chapter 9: Alternative Chains, Currencies and Applications. 1. What is the name of alternative coins? Are they built on top of the Bitcoin network? What are examples of them? Is there any alternative approach? Could you please describe some alternatives? 2. Are there any alternatives to the PoW algorithm? If yes – what are the alternatives? Could you please name two or three? 3. What is the operation of the Script language that is used to store a metadata in Bitcoin blockchain? 4. What is a coloured coin? Could you please explain how it is created and how it works? Do you need any special SW to manage coloured coins? 5. What is the difference between alt coins and alt chains? What is a Litecoin? What are the major differences between the Bitcoin and Litecoin? Why so many alt coins have been created? What are they usually based on? 6. What is Scrypt? Where is it used and how is it different from the original algorithm from which it has been created? 7. What is a demurrage currency? Could you please give an example of one blockchain and crypto currency that is demurrage? 8. What is a good example of an alternative algorithm to PoW? What is it called and how is it different from the PoW? Why the alternatives to Bitcoin PoW have been created? What is the main reason for this? What is dual-purpose PoW algorithms? Why have they been created? 9. Is Bitcoin “anonymous” currency? Is it difficult to trace transactions and understand someone’s spending habits? 10. What is Ethereum? What kind of currency does it use? What is the difference from Bitcoin? Chapter 10: Bitcoin security. 1. What is the main approach of Bitcoin security? 2. What are two common mistakes made by newcomers to the world of Bitcoin? 3. What is a root of trust in traditional security settings? What is a root of trust in Bitcoin network? How should you assess security of your system? 4. What is a cold storage and paper wallet? 5. What is a hardware wallet? How is it better than storing private keys on your computer or your smart phone?
submitted by 5tu to BitcoinTechnology [link] [comments]

BTC vs BCH: What is Consensus

BTC vs. BCH is a series of posts that will first steelman (opposite of strawman) the arguments of each side. Hopefully, this will foster discussion in the comments about the merits of each position.

BTC Position

In the minds of Bitcoin supporters, consensus can be split into two separate domains: Chainstate Consensus, and Validation Consensus (I made up these terms, but feel they describe the position pretty well). Chainstate consensus is the domain of miners. It is concerned with things like the order of blocks and transactions, what the minimum fee to send a transaction is, which chain is the longest, and other similar concerns. Validation Consensus concerns things like whether a transaction or block is valid, if proper proof of work has been calculated, if the coinbase reward is less than or equal to the current limit, and other similar concerns. Validation consensus is the domain of fully validating nodes (which miners also run). The enforcement mechanism for the two types of consensus are also different. In Chainstate Consensus, the parties with the most computing power control the consensus. This is acceptable because what the Chainstate Consensus is does not matter as long as there is consensus. For example, it does not matter if transaction x or y appears first. It only matters that the entire network agree on which came first, at the time the transactions are confirmed. Validation Consensus is much more interesting. Validation Consensus has no enforcement mechanism, and is entirely opt-in and ad-hoc. For instance, the maximum block size is part of Validation Consensus. When Bitcoin Cash changed the MAX_BLOCK_SIZE to 8 MB, and then to 32 MB, there was no way to enforce these changes. So, unlike in Chainstate Consensus, there is no "voting" on Validation Consensus (because Validation Consensus does not use proof-of-work as an enforcement mechanism, "voting" based on node count could easily be Sybil attacked). Each node sets their own rules, and compatible nodes connect to each other on the network. Although this is a complicated system that relies on every user to verify each transaction, this system ensures that a powerful entity - say, one that feels comfortable running a 20 trillion dollar deficit - cannot change the definition of valid blocks and transaction by overpowering the network. This also prevents a tragedy of the commons, because even if a majority of users decide that they don't mind centralizing changes to the Bitcoin Protocol, users who do not agree are unaffected.

BCH Position

In BCH, miners hold all the power over consensus. The chain with the most proof-of-work is the valid chain, full stop. This is a much simpler approach than the BTC approach, as users only need to verify the proof-of-work (SPV Mode), if the longest chain is presumed valid. Miners are assumed to act in rational self-interest, as is is presumed that Bitcoin Cash will be most valuable if miners cater to the wishes of the user. This approach to consensus allows Bitcoin Cash to scale mush more efficiently on-chain, as not every user has to verify each transaction (SPV Mode). This system also allows easier upgradeability, as miners can vote with their proof-of-work on behalf of users, rather than require each individual user to upgrade on their own.
EDIT: Added more details about upgrades to the BCH Position. EDIT 2: Clarify I am speaking about SPV in BCH position.
submitted by ReilySiegel to btc [link] [comments]

Blockchain and Sustainability

In terms of blockchain algorithms and platforms, sustainability can be interpreted in many ways. On the one hand, anyone who has ever heard about the energy demand of the Bitcoin network can rightly think that the system is pretty far from being considered as sustainable or environmentally friendly. This extreme energy requirement is not necessarily similar however with other blockchain platforms. On the other hand, a number of initiatives have been taken over the past few years to address sustainability or environmental issues with decentralized applications. In this article, we analyze the topic of blockchain and sustainability from these two relatively different point of views.

Consensus and energy consumption

One of the most important components of decentralized platforms is the consensus mechanism. The consensus mechanism is responsible for ensuring that the system is always in a consistent state, meaning that all nodes contain the same information. With other words when someone creates a new transaction, the consensus mechanism ensures that the entire system reaches a single state: either each node finds the transaction valid, or each node finds it invalid.
In public blockchain algorithms, the implementation of the consensus algorithm may be particularly difficult. With such systems, there is always the possibility of a so-called sybil attack, where an external attacker creates a large number of hacked nodes and tries to influence the consensus of the system. Therefore, in such systems, the consensus algorithm is not based on the number of nodes, instead on some other economically scarce or expensive resource. Early day consensus algorithms implemented this resource with computational power (Proof of Work). As a participant in such a consensus compete with each other on a market basis, the total computing power can grow to an extremely large extent to maintain the system and the consensus.
📷
Figure 1, the computational capacity needed to maintain the Bitcoin consensus
(source: https://www.blockchain.com/de/charts/hash-rate?timespan=all)
Of course, the computational capacity that might be extremely high in some places has significant energy consumption, which does not affect the sustainability or the environment positively. It is difficult to explicitly measure this energy consumption, but it can be estimated in two ways. The so-called bottom-up estimation calculates the energy consumption, cooling, and production energy requirements of computing hardware in detail. The other, so called top down approach, takes into account that the participants in the consensus receive profit or reward for their activity. Given that there are many players on the market and that market is pretty competitive, participants can only realize an estimated normal profit and the rest of the revenue can be considered as direct or indirect energy cost. In both cases however, the total amount of estimated energy is significant.
📷
Figure 2. Energy consumption of the Bitcoin network compared to countries.(source: https://bitcoinist.com/huge-wind-farm-to-power-bitcoin-mining-will-be-built-in-north-africa/)
Fortunately, the Bitcoin consensus mechanism was merely the first working mechanism and it is almost certainly not the last. Many research and development focuses on developing faster and more efficient consensus mechanisms that require less energy. In one solution, the critical resource involved in the consensus is not the computational capacity but directly the cryptographic currency. In such so-called proof of stake systems, nodes intercept a certain amount of cryptocurrencies, which is lost if it turns out that they tried to hack the system. Other approaches, called layer 2 scaling solutions, execute most of the transactions not directly on the blockchain but on a separate off-chain transaction channel. Considering that usually every hundreds transaction is executed or synchronized with a blockchain, the overall efficiency is enormously increased.
The area of ​​consensus mechanisms is very actively researched area. Even if the currently most widespread solution are energy demanding, this will most likely not a problem for future blockchain platforms and consensus mechanisms.

Sustainability applications on the blockchain

There are on the other hand a lot of applications and initiatives that try to support or solve sustainability and environmental issues with the help of a blockchain. Of course, many of these initiatives are still in the early stage, so it is too early to evaluate which of them will be real killer sustainability application. Most of these initiatives can be summarized by the following categories:
“Green” energy distribution: One of the applications sustainability and blockchain focuses on the efficient distribution of locally produced “green” energy. Suppose that some residents in a local community install solar cells, and in the case of overproduction of energy they share the extra energy with their neighbors. The blockchain can be used here to accurately and automatically accounting the distributed energy. From a technical point of view, early implementations use Ethereum integrated with local energy IoT devices, creating a so-called smart meter [1].
📷
Figure 3, “green” energy distribution in a local market
(source: https://microgridknowledge.com/blockchain-siemens-lo3-energy/)
Supply chain transparency: The next major area of ​​sustainability applications is to improve the transparency of supply chains and value chains. The first applications come from the area of ​​food production and food distribution, where it is particularly important to keep track of the exact lifespan and raw materials of a food product [2]. For example, if it is found that an agricultural area has been sprayed with harmful substances, all the products directly or indirectly affected should be withdrawn. The technology also provides the opportunity to aggregate certain properties in the supply chain and display them on end products. For example, it is possible to say about a food product that it is made from vegetable ingredients or does not contain gluten, considering the entire production chain. In addition to properties directly related to food, other sustainability parameters can be also measured and aggregated along the supply chain, such as greenhouse gas emission or the proportion of recycled materials used.
Incentives: Blockchain-based incentive systems generally reward some kind of environmentally conscious activity. A classic example is getting a token reward for collecting and recovering recyclable materials [3]. The environmentally conscious activity can be glass recycling, plastic garbage collection or the purchasing services that have a positive overall environmental impact. The motivational token can also be implemented in different ways. It can function as a collectible token, it can work as a local currency to buy different special products, or it can also be a full scale cryptocurrency.
There are a number of other examples and initiatives how blockchain can be used in sustainability or environment protection. Examples include a transparent "green" point system for companies, or a transparent block chain accounting system that tracks charity cash flows. Of course, it is not yet possible to see which application will be a real “killer app” in the area. However, there is a strong chance that many sustainability issues will be better solved with transparent global blockchain systems and decentralized automated organizations than in the current system, which is usually dominated by short-term financial decisions and other local political interests.

Reference

[1] SolarCoin, https://solarcoin.org/
[2] FoodTrax, https://www.bcdc.online/foodtrax
[3] Recycle2Coin, https://www.recycletocoin.com/
submitted by CryptoEasy to u/CryptoEasy [link] [comments]

Information and FAQ

Hi, for everyone looking for help and support for IOTA you have come to the right place. Please read this information, the FAQ and the side bar before asking for help.

Information

IOTA

IOTA is an open-source distributed ledger protocol launched in 2015 that goes 'beyond blockchain' through its core invention of the blockless ‘Tangle’. The IOTA Tangle is a quantum-resistant Directed Acyclic Graph (DAG), whose digital currency 'iota' has a fixed money supply with zero inflationary cost.
IOTA uniquely offers zero-fee transactions & no fixed limit on how many transactions can be confirmed per second. Scaling limitations have been removed, since throughput grows in conjunction with activity; the more activity, the more transactions can be processed & the faster the network. Further, unlike blockchain architecture, IOTA has no separation between users and validators (miners / stakers); rather, validation is an intrinsic property of using the ledger, thus avoiding centralization.
IOTA is focused on being useful for the emerging machine-to-machine (m2m) economy of the Internet-of-Things (IoT), data integrity, micro-/nano- payments, and other applications where a scalable decentralized system is warranted.
More information can be found here.

Non reusable addresses

Contrary to traditional blockchain based systems such as Bitcoin, where your wallet addresses can be reused, IOTA's addresses should only be used once (for outgoing transfers). That means there is no limit to the number of transactions an address can receive, but as soon as you've used funds from that address to make a transaction, this address should not be used anymore.
The reason for this is, by making an outgoing transaction a part of the private key of that specific address is revealed, and it opens the possibility that someone may brute force the full private key to gain access to all funds on that address. The more outgoing transactions you make from the same address, the easier it will be to brute force the private key.
It should be noted that having access to the private key of an address will not reveal your seed or the private key of the other addresses within your seed / "account".
This piggy bank diagram can help visualize non reusable addresses. imgur link

Address Index

When a new address is generated it is calculated from the combination of a seed + Address Index, where the Address Index can be any positive Integer (including "0"). The wallet usually starts from Address Index 0, but it will skip any Address Index where it sees that the corresponding address has already been attached to the tangle.

Private Keys

Private keys are derived from a seeds key index. From that private key you then generate an address. The key index starting at 0, can be incremented to get a new private key, and thus address.
It is important to keep in mind that all security-sensitive functions are implemented client side. What this means is that you can generate private keys and addresses securely in the browser, or on an offline computer. All libraries provide this functionality.
IOTA uses winternitz one-time signatures, as such you should ensure that you know which private key (and which address) has already been used in order to not reuse it. Subsequently reusing private keys can lead to the loss of funds (an attacker is able to forge the signature after continuous reuse).
Exchanges are advised to store seeds, not private keys.

Double spending

Sending a transaction will move your entire balance to a completely new address, if you have more than one pending transaction only one can eventually be confirmed and the resulting balance is sent to your next wallet address. This means that the other pending transactions are now sent from an address that has a balance of 0 IOTA, and thus none of these pending transactions can ever be confirmed.

Transaction Process

As previously mentioned, in IOTA there are no miners. As such the process of making a transaction is different from any Blockchain out there today. The process in IOTA looks as follows:
  • Signing: You sign the transaction inputs with your private keys. This can be done offline.
  • Tip Selection: MCMC is used to randomly select two tips, which will be referenced by your transaction (branchTransaction and trunkTransaction)
  • Proof of Work: In order to have your transaction accepted by the network, you need to do some Proof of Work - similar to Hashcash, not Bitcoin (spam and sybil-resistance). This usually takes a few minutes on a modern pc.
After this is completed, the trunkTransaction, branchTransaction and nonce of the transaction object should be updated. This means that you can broadcast the transaction to the network now and wait for it to be approved by someone else.

FAQ

How do I to buy IOTA?

Currently not all exchanges support IOTA and those that do may not support the option to buy with fiat currencies.
One way to buy IOTA is to buy with bitcoin (BTC) or Ether (ETH), first you will need to deposit BTC/ETH onto an exchange wallet and you can the exchange them for IOTA.
You can buy BTC or ETH through coinbase. And exchange those for IOTA on Binance or Bitfinex (other exchanges do exist, some linked in the side bar).
A detailed guide to buying can be found here.

What is MIOTA?

MIOTA is a unit of IOTA, 1 Mega IOTA or 1 Mi. It is equivalent to 1,000,000 IOTA and is the unit which is currently exchanged.
We can use the metric prefixes when describing IOTA e.g 2,500,000,000 i is equivalent to 2.5 Gi.
Note: some exchanges will display IOTA when they mean MIOTA.

Can I mine IOTA?

No you can not mine IOTA, all the supply of IOTA exist now and no more can be made.
If you want to send IOTA, your 'fee' is you have to verify 2 other transactions, thereby acting like a minenode.

Where should I store IOTA?

It is not recommended to store large amounts of IOTA on the exchange as you will not have access to the private keys of the addresses generated.
However many people have faced problems with the current GUI Wallet and therefore group consensus at the moment is to store your IOTA on the exchange, until the release of the UCL Wallet, or the Paper Wallet.

What is the GUI wallet?

What is the UCL Wallet?

What is a seed?

A seed is a unique identifier that can be described as a combined username and password that grants you access to your wallet.
Your seed is used to generate the addresses linked to your account and so this should be kept private and not shared with anyone. If anyone obtains your seed, they can login and access your IOTA.

How do I generate a seed?

You must generate a random 81 character seed using only A-Z and the number 9.
It is recommended to use offline methods to generate a seed, and not recommended to use any non community verified techniques. To generate a seed you could:

On a Linux Terminal use the following command:

 cat /dev/urandom |tr -dc A-Z9|head -c${1:-81} 

On a Mac Terminal use the following command:

 cat /dev/urandom |LC_ALL=C tr -dc 'A-Z9' | fold -w 81 | head -n 1 

With KeePass on PC

A helpful guide for generating a secure seed on KeePass can be found here.

With a dice

Dice roll template

Is my seed secure?

  1. All seeds should be 81 characters in random order composed of A-Z and 9.
  2. Do not give your seed to anyone, and don’t keep it saved in a plain text document.
  3. Don’t input your seed into any websites that you don’t trust.
Is this safe? Can’t anyone guess my seed?
What are the odds of someone guessing your seed?
  • IOTA seed = 81 characters long, and you can use A-Z, 9
  • Giving 2781 = 8.7x10115 possible combinations for IOTA seeds
  • Now let's say you have a "super computer" letting you generate and read every address associated with 1 trillion different seeds per second.
  • 8.7x10115 seeds / 1x1012 generated per second = 8.7x10103 seconds = 2.8x1096 years to process all IOTA seeds.

Why does balance appear to be 0 after a snapshot?

When a snapshot happens, all transactions are being deleted from the Tangle, leaving only the record of how many IOTA are owned by each address. However, the next time the wallet scans the Tangle to look for used addresses, the transactions will be gone because of the snapshot and the wallet will not know anymore that an address belongs to it. This is the reason for the need to regenerate addresses, so that the wallet can check the balance of each address. The more transactions were made before a snapshot, the further away the balance moves from address index 0 and the more addresses have to be (re-) generated after the snapshot.

Why is my transaction pending?

IOTA's current Tangle implementation (IOTA is in constant development, so this may change in the future) has a confirmation rate that is ~66% at first attempt.
So, if a transaction does not confirm within 1 hour, it is necessary to "reattach" (also known as "replay") the transaction one time. Doing so one time increases probability of confirmation from ~66% to ~89%.
Repeating the process a second time increases the probability from ~89% to ~99.9%.

What does attach to the tangle mean?

The process of making an transaction can be divided into two main steps:
  1. The local signing of a transaction, for which your seed is required.
  2. Taking the prepared transaction data, choosing two transactions from the tangle and doing the POW. This step is also called “attaching”.
The following analogy makes it easier to understand:
Step one is like writing a letter. You take a piece of paper, write some information on it, sign it at the bottom with your signature to authenticate that it was indeed you who wrote it, put it in an envelope and then write the recipient's address on it.
Step two: In order to attach our “letter” (transaction), we go to the tangle, pick randomly two of the newest “letters” and tie a connection between our “letter” and each of the “letters” we choose to reference.
The “Attach address” function in the wallet is actually doing nothing else than making an 0 value transaction to the address that is being attached.

How do I reattach a transaction.

Reattaching a transaction is different depending on where you send your transaction from. To reattach using the GUI Desktop wallet follow these steps:
  1. Click 'History'.
  2. Click 'Show Bundle' on the 'pending' transaction.
  3. Click 'Reattach'.
  4. Click 'Rebroadcast'. (optional, usually not required)
  5. Wait 1 Hour.
  6. If still 'pending', repeat steps 1-5 once more.

What happens to pending transactions after a snapshot?

How do I recover from a long term pending transaction?

How can I support IOTA?

You can support the IOTA network by setting up a Full Node, this will help secure the network by validating transactions broadcast by other nodes.
Running a full node also means you don't have to trust a 3rd party in showing you the correct balance and transaction history of your wallet.
By running a full node you get to take advantage of new features that might not be installed on 3rd party nodes.

How to set up a full node?

To set up a full node you will need to follow these steps:
  1. Download the full node software: either GUI, or headless CLI for lower system requirements and better performance.
  2. Get a static IP for your node.
  3. Join the network by adding 7-9 neighbours.
  4. Keep your full node up and running as much as possible.
A detailed user guide on how to set up a VTS IOTA Full Node from scratch can be found here.

How do I get a static IP?

To learn how to setup a hostname (~static IP) so you can use the newest IOTA versions that have no automated peer discovery please follow this guide.

How do I find a neighbour?

Are you a single IOTA full node looking for a partner? You can look for partners in these place:

Extras

Transaction Example:

Multiple Address in 1 Wallet Explained:

submitted by Boltzmanns_Constant to IOTASupport [link] [comments]

New to r/Tokenmining? click here for more in-depth info!

What is EIP:918?

EIP:918 is an Ethereum Improvement Proposal for standardizing mineable token distribution using Proof of Work.
The primary driver behind the standard is to address the very broken ICO model that currently plagues the Ethereum network. Token distribution via the ICO model and it’s derivatives has always been susceptible to illicit behavior by bad actors. New token projects are centralized by nature because a single entity must handle and control all of the initial coins and all of the the raised ICO money. By distributing tokens via an alternative ‘Initial Mining Offering’ (or IMO), the ownership of the token contract no longer belongs with the deployer at all and the deployer is ‘just another user.’ As a result, investor risk exposure utilizing a mined token distribution model is significantly diminished. This standard is intended to be standalone, allowing maximum interoperability with ERC20, ERC721, and future token standards.
The most effective economic side effect of Satoshi Nakamoto’s desire to secure the original Bitcoin network with Proof of Work hash mining was tethering the coin to real computing power, thereby removing centralized actors. Transitioning the responsibility of work back onto individual miners, government organizations have no jurisdiction over the operation of a pure mined token economy. Oversight is removed from an equation whereby miners are providing economic effort in direct exchange of a cryptographic commodity. This facilitates decentralized distribution and establishes all involved parties as stakeholders. The ERC918 standard allows projects to be funded through decentralized computing power instead of centralized, direct-fiat conversion.
The Ethereum blockchain in its current state exists as a thriving ecosystem which allows any individual to store immutable records in a permission-less, invulnerable and transparent manner. Recently, there have been proposals to mitigate some initial ICO investment risks through the introduction of the DAICO model that relies on timed and automated value transfers via the smart contract tapping mechanism. However, this does not align a token smart contract as a non-security and still has the potential to put investors at risk if not implemented carefully, relying on centralized actors to be fair and community intended. Allowing users of the network direct access to tokens by performing computations as a proof of work supplies allows any smart contract to distribute a token in a safe and controlled manner similar to the release of a commodity.
As of 2017, all Ethereum token distribution methods were flawed and susceptible to Sybil attacks. A Sybil attack is a form of computer security attack where one person pretends to be many people with multiple computer accounts in order to manipulate a system in a malicious way. ICOs and airdrops are highly susceptible to these type of attacks so there is no way to verify that all ERC20 tokens distributed by the deployer were doled out fairly or unfairly. Proof of Work distribution is resistant to Sybil attacks. This means that ERC918 tokens are among the first trustless Ethereum tokens in the world. The distribution of ERC918 tokens is fair because they are allotted via an open, decentralized mathematical algorithm (that anyone can view on the mainnet blockchain) and not a centralized human monarchy.
ERC918’s first incarnation (and inspiration) was the 0xBitcoin project that launched in early 2018. Since then, several projects have realized the standard in innovative and creative ways. Catether (0xCATE) erupted early and additionally mints payback tokens during transfer operations to offset gas costs. 0xGold and 0xLitecoin each implement the first on-chain merge-mining with 0xBitcoin and the Mineable Gem project extends the standard onto a non-fungible collectible artifacts, whereby each gem has a unique mining difficulty. The Mineable project is a newer initiative that provides users with the ability to create mineable ERC20 tokens on-chain without writing a line of code and includes a virtualized hashing artifact market that allows miners to purchase on-chain vGPUs to improve mining difficulty and rewards. (written by jlogelin) ​

MINING IN A NUTSHELL

0xBitcoin is a Smart Contract on the Ethereum network, and the concept of Token Mining is patterned after Bitcoin's distribution. Rather than solving 'blocks', work is issued by the contract, which also maintains a Difficulty which goes up or down depending on how often a Reward is issued. Miners can put their hardware to work to claim these rewards, in concert with specialized software, working either by themselves or together as a Pool. The total lifetime supply of 0xBitcoin is 21,000,000 tokens and rewards will repeatedly halve over time.
The 0xBitcoin contract was deployed by Infernal_Toast at Ethereum address: 0xb6ed7644c69416d67b522e20bc294a9a9b405b31
0xBitcoin's smart contract, running on the Ethereum network, maintains a changing "Challenge" (that is generated from the previous Ethereum block hash) and an adjusting Difficulty Target. Like traditional mining, the miners use the SoliditySHA3 algorithm to solve for a Nonce value that, when hashed alongside the current Challenge and their Minting Ethereum Address, is less-than-or-equal-to the current Difficulty Target. Once a miner finds a solution that satisfies the requirements, they can submit it into the contract (calling the Mint() function). This is most often done through a mining pool. The Ethereum address that submits a valid solution first is sent the 50 0xBTC Reward.
(In the case of Pools, valid solutions that do not satisfy the full difficulty specified by the 0xBitcoin contract, but that DO satisfy the Pool's specified Minimum Share Difficulty, get a 'share'. When one of the Miners on that Pool finds a "Full" solution, the number of shares each miner's address has submitted is used to calculate how much of the 50 0xBTC reward they will get. After a Reward is issued, the Challenge changes.
A Retarget happens every 1024 rewards. In short, the Contract tries to target an Average Reward Time of about 60 times the Ethereum block time. So (at the time of this writing):
~13.9 seconds \* 60 = 13.9 minutes
If the average Reward Time is longer than that, the difficulty will decrease. If it's shorter, it will increase. How much longer or shorter it was affects the magnitude with which the difficulty will rise/drop, to a maximum of 50%. * Click Here to visit the stats page~ (https://0x1d00ffff.github.io/0xBTC-Stats) to see recent stats and block times, feel free to ask questions about it if you need help understanding it.

MINING HARDWARE

Presently, 0xBitcoin and "Alt Tokens" can be mined on GPUs, CPUs, IGPs (on-CPU graphics) and certain FPGAs. The most recommended hardware is nVidia graphics cards for their efficiency, ubiquity and relatively low cost. As general rules, the more cores and the higher core frequency (clock) you can get, the more Tokens you will earn!
Mining on nVidia cards:
Mining on AMD cards:
Mining on IGPs (e.g. AMD Radeon and Intel HD Graphics):
Clocks and Power Levels:

MINING SOFTWARE AND DESCRIPTIONS

For the most up-to-date version info, download links, thread links and author contact information, please see this thread: https://www.reddit.com/0xbitcoin/comments/8o06dk/links_to_the_newestbest_miners_for_nvidia_amd/ Keep up to date for the latest speed, stability and feature enhancements!
COSMiC Miner by LtTofu:
SoliditySha3Miner by Amano7:
AIOMiner All-In-One GPU Miner:
TokenMiner by MVis (Mining-Visualizer):
"Nabiki"/2.10.4 by Azlehria:
~Older Miners: Older and possibly-unsupported miner versions can be found at the above link for historical purposes and specific applications- including the original NodeJS CPU miner by Infernal Toast/Zegordo, the '1000x' NodeJS/C++ hybrid version of 0xBitcoin-Miner and Mikers' enhanced CUDA builds.

FOR MORE INFORMATION...

If you have any trouble, the friendly and helpful 0xBitcoin community will be happy to help you out. Discord has kind of become 0xBTC's community hub, you can get answers the fastest from devs and helpful community members. Or message one of the community members on reddit listed below.
Links
submitted by GeoffedUP to Tokenmining [link] [comments]

Why Dash is the Most Sybil Attack-Resistant Cryptocurrency -- By Far Dusting Attacks Explained Sybil Attack - My Presentation Cryptoeconomics - 3.4 - Bitcoin: Game Theory BITCOIN $20K IMMINENT?! Fastest Bull Market in History... $LINK Coinbase, Sybil vs Eclipse Attack

Blockchain Technology For Government - Mitre.org Public vs. Permissioned Blockchain. .. 9 Table 3. Guardtime Pros and Cons.. 16 . 1 Background In 2009, a developer (or developers) by the name of Satoshi Nakamoto created an electronic Bitcoin and the emergence of new platforms such as Ethereum that offer programmable smart ... From Bitcoin Wiki. Jump to: navigation, search. A majority attack (usually labeled 51% attack or >50% attack) is an attack on the network. This attack has a chance to work even if the merchant waits for some confirmations, but requires extremely high relative hashrate. The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork ... Name Symbol Market Cap Algorithm Hash Rate 1h Attack Cost NiceHash-able; Bitcoin: BTC: $242.13 B: SHA-256: 123,758 PH/s: $483,191: 0%: Ethereum: ETH: $46.16 B: Ethash ... Q&A for Bitcoin crypto-currency enthusiasts. Stack Exchange network consists of 176 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.. Visit Stack Exchange Bitcoin Calculator; Bitcoin Analytics; Chainalysis CEO Denies ‘Sybil Attack’ on Bitcoin’s Network. February 28, 2017 February 28, 2017 by Bits n Coins. UPDATE (14th March 16:18 GMT): Additional remark added from Chainalysis CEO Michael Grønager. Compliance startup Chainalysis was pressured to defend itself as we speak after allegations its surveillance ways had disrupted providers and ...

[index] [32754] [4108] [20259] [37788] [44472] [11519] [22240] [8245] [15898] [40300]

Why Dash is the Most Sybil Attack-Resistant Cryptocurrency -- By Far

In this video I make some calculations about the costs of making a sybil attack on the Bitcoin network. If this video helped you and you'd like to give back ... Sybil Attack in Online Social Networks. Robert Kiyosaki 2019 - The Speech That Broke The Internet!!! KEEP THEM POOR! Decoding The Elite Plan For The World Economy - Mike Maloney On Federal Reserve Strategy - Duration: 56:48. GoldSilver (w/ Mike Maloney) 1,025,836 views Sybil Attacks are extremely common in the day-to-day world. They are happening all around and yet you may not even notice. How do blockchains prevent sybil a... A Sybil Attack in a peer-to-peer network happens when one person uses many, many nodes for a malicious end. How is this achieved, and what does it cost? Amanda B. Johnson explains why Dash in ...

#