Saturday, May 4, 2019

[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[uncensored-r/BitcoinMarkets] [Daily Discussion] Sunday, May 05, 2019

The following post by AutoModerator is being replicated because some comments within the post(but not the post itself) have been silently removed.

The original post can be found(in censored form) at this link:

np.reddit.com/r/ BitcoinMarkets/comments/bktmoi

The original post's content was as follows:


Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Altcoin Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • Discussion related to recent events
  • Technical analysis, trading ideas & strategies
  • General questions about altcoins

Thread guidelines:

  • Be excellent to each other.
  • All regular rules for this subreddit apply, except for number 2. This, and only this, thread is exempt from the requirement that all discussion must relate to bitcoin trading.
  • This is for high quality discussion of altcoins. All shilling or obvious pumping/dumping behavior will result in an immediate one day ban. This is your only warning.
  • No discussion about specific ICOs. Established coins only.

If you're not sure what kind of discussion belongs in this thread, here are some example posts. News, TA, and sentiment analysis are great, too.

Other ways to interact:


[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Sunday, May 05, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


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-server/blob/master/doc/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-December/012103.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>


[uncensored-r/BitcoinMarkets] [Altcoin Discussion] Saturday, May 04, 2019

The following post by AutoModerator is being replicated because some comments within the post(but not the post itself) have been silently removed.

The original post can be found(in censored form) at this link:

np.reddit.com/r/ BitcoinMarkets/comments/bkhbla

The original post's content was as follows:


Thread topics include, but are not limited to:

  • Discussion related to recent events
  • Technical analysis, trading ideas & strategies
  • General questions about altcoins

Thread guidelines:

  • Be excellent to each other.
  • All regular rules for this subreddit apply, except for number 2. This, and only this, thread is exempt from the requirement that all discussion must relate to bitcoin trading.
  • This is for high quality discussion of altcoins. All shilling or obvious pumping/dumping behavior will result in an immediate one day ban. This is your only warning.
  • No discussion about specific ICOs. Established coins only.

If you're not sure what kind of discussion belongs in this thread, here are some example posts. News, TA, and sentiment analysis are great, too.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


05-04 22:23 - 'Mindmap of some early events and future consequences in Bitcoin' (i.redd.it) by /u/bohuspollak removed from /r/Bitcoin within 3-13min


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[uncensored-r/Bitcoin] Mindmap of some early events and future consequences in Bitcoin

The following post by bohuspollak is being replicated because the post has been silently removed.

The original post can be found(in censored form) at this link:

np.reddit.com/r/ Bitcoin/comments/bkqgks

The original post's content was as follows:


https://i.redd.it/1idww5r4q9w21.png


MinedBlock Introduces Share-Backed Security Tokens to Everyone Interested in Crypto Mining Service

Cryptocurrency mining is a computational process that seeks to solve cryptographic problems. Mining is instrumental to the decentralized nature of non-premined tokenized assets and also ensures issuance of new coins into circulation. For blockchain built based on proof-of-work (PoW) consensus such as Bitcoin, Ethereum, Dash and others, mining is a must as it ensures validation of transactions and security of the network. For successfully mining a block, a miner is awarded a stipulated number of that crypto asset. The equipment required for crypto mining are often high-grade and specialized for the task due to the high amount of hash rate (computational power) required to decrypt block or mine. While in the very early times of cryptocurrency, classic CPUs (central processing units) could be used to profitably mine crypto, doing so today will amount to a total waste of time and resources because of the difficulty level of mining which has been raised and will still be raised on an ongoing basis.

Today, the mining industry is dominated by large mining firms with high-grade specialized mining rigs. The competition cannot be survived, in terms of economy of returns, by individual or small-scale miners because of the large capital intensive nature of the business. People are therefore turning to investing in these mining farms  with the promise of sharing in the mining rewards accrued to the operations of the miner.

These mining service companies mostly pass liabilities on to their investors by conducting ICOs with amplified risks of loss of capital to the retail investor. For example, the mining company could cancel mining contracts in the event of unprofitable mining service without considering the investors. MinedBlock presents a mining solution different from existing ones.

MinedBlock plans to build a dedicated mining facility that will enhance profitability through a multi-pronged business approach. Firstly, MinedBlock is a registered limited liability company with the intent to raise funds needed to establish and run the mining facility optimally through a security token offering (STO) based on Polymath ST20 standard. The security tokens, MBTX, represent one preference share in MinedBlock Holding Limited. This implies that investors are investing in a real company.

Secondly, token holders are entitled to 75% of the revenue generated from the mining service. This dividends will be issued monthly and initially in ethereum tokens, with the option of distribution in other tokens mined by the company. Additionally, MinedBlock plans to mine multiple cryptocurrencies and switch over to the more economically rewarding token depending on the difficulty level and mining success rate. Finally, there is also strategy to diversify investment by considering the options of: belonging to an existing mining pool to maximize profit and running master nodes to create additional stream of income. These exemplify the commitment and multiprong approach of MinedBlock to running the mining service profitably.

The opportunities in blockchain are diverse. Cryptocurrency mining represents one of the major markets that can be leveraged to generate revenue. MinedBlock is set to not only lower the entry barrier into crypto mining but also provide a secure and reduced risk share-backed access.

For more information on MinedBlock: Website: https://www.minedblock.io/

Whitepaper: https://www.minedblock.io/assets/MinedBlockWhitepaper.pdf

Bounty0x username: Mexite


Welcome to the Official Energi Cryptocurrency Reddit!

https://i.redd.it/wgriag3ha9w21.png

Hello and welcome to the Official Energi Cryptocurrency Reddit!

Below you will find a Table of Contents that will go over what Energi is and the fundamentals of the cryptocurrency.

Table of Contents

  1. What is Energi?
  2. What are the Fundamentals of Energi?
    1. Scalability
    2. Funding
    3. Governance
    4. Inflation
    5. Distribution
    6. Decentralization
    7. Long Term Vision
  3. Coin Specs
  4. How to Get Started
    1. Official Energi Website
    2. Energi Earndrop Campaign
    3. Social Media
    4. Exchanges
    5. Energi Block Explorers
    6. Wallet Downloads
    7. Proof-of-Stake Setup Guides
    8. Masternode Setup Guide
  5. FAQ

1. What is Energi

Energi is a self-funding (non-ICO and No Premine) cryptocurrency that has a purpose to become the world’s leading cryptocurrency with the unification of Smart Contracts, Governance & Self-funding Treasury to ensure longevity and enable rapid growth.

Energi provides a small allocation to Proof-of-Stake (PoS) rewards and takes a bulk of the coin issuance and give it to its treasury and active masternodes. Energi also allocates 10% on-going reward to the leadership of the Energi Backbone, which is significantly less compared to today’s ICOs’ rewarding their founders between 20–50% of the tokens distributed. Another trait that sets Energi apart from ICOs is they give an on-going 10% allocation through each block reward, rather than rewarding the founders up-front.

2. What are the Fundamentals of Energi?

  • Scalability

One minute block times and a 2 megabyte block size limit provide Energi with a vast transaction capacity for regular on-chain transactions. This allows for plenty of space on the blockchain for extremely fast transactions with very low fees.

Energi features a powerful on-chain scaling solution with a system of incentivized full nodes called Energi Masternodes. A masternode is a full node backed by 10,000 NRG collateral that provides level 2 scalability to the Energi Cryptocurrency. The Instant Send feature allows for instant transactions, even in times of network congestion. Transactions can be made securely and instantly ahead of the blockchain, as they are approved by a quorum of masternodes. Instant Send payments enjoy the same immutable transaction history as regular transactions, as they are later resolved on-chain as the network is able to.

40% of the inflation of Energi is allocated to masternodes, providing an extremely strong incentive to grow the number of full nodes and scalability of the network.

  • Funding

A key feature of Energi is its powerful treasury system. Energi makes up to 40% of the inflation available to the treasury, to be utilized in a manner that provides maximum benefit.

Treasury allocation is decentralized, allowing for submitted proposals from anyone, to be voted on by masternodes and paid out from the inflation.

Energi has a 14 day treasury cycle, allowing quick payments for proposal authors and contributors, as well as strategic responsiveness to effective proposals. Energi is guided by the principle that every dollar spent from its funding model, should yield more than dollar of value in return. Thanks to a 14 day treasury cycle, the Energi team is able to measure results and respond quickly to changes in strategy.

  • Governance

The Energi Treasury is a decentralized governance model designed with Masternodes as caretakers and stakeholders in Energi, with voting rights on how to best utilize treasury funding.

This governance model reduces risk in the form of allowing participation from everyone who holds 10,000 NRG. In this way, the Energi community can work together on how to best build the strategic direction of Energi.

  • Inflation

Energi Cryptocurrency has a simple rate of inflation at 1 million coins per month with no maximum cap. This ensures consistency in funding allocation, masternode rewards, and PoS rewards, making the economics of the cryptocurrency more understandable for everyone who chooses to participate in Energi.

No coin supply limit ensures that Energi is prepared for the long term, avoiding “bubble” economics caused by dramatic early inflation that in most coins only serves to benefit founders ahead of increased adoption.

  • Distribution

Energi conducted a fair launch on April 14, 2018 with NO ICO and NO PREMINE. Prior to launch, the Energi team gave a specific time and date for the launch of its main net, which its vibrant community eagerly awaited, so that mining could begin fairly, again avoiding centralization among the coin founders (It's important to note that Energi has transitioned to Proof-of-Work consensus to a Proof-of-Stake consensus).

Energi masternode payments were designed to begin at block 216000, which occurred on September 18, 2018, almost 160 days after launch. This ensured time to list Energi on exchanges, and to grow the community, encouraging fair and equitable distribution before the extremely powerful masternode rewards began. It is all too common for masternode coins to feature a premine, which has the effect of centralizing distribution among the founders and early adopters.

Energi has an ongoing Earndrop; a distribution of 4 million coins to users who contribute with social media activities about Energi, such as tweets, follows, and subscriptions on all major social media platforms. So far nearly 1 million coins have been distributed, helping to grow an enthusiastic community and serve to bring coins to the market in a way that is inspired by generosity.

  • Decentralization

Delayed masternode payments have allowed the market time to react to the future of Energi, helping to ensure a decentralized community of masternode holders.

Decentralized governance with masternodes help to ensure everyone is able to participate in Energi and help guide the project to achieve the best results.

  • Long Term Vision

All of the above features seamlessly work together in concert, to ensure that Energi is prepared for the long term. Rather than try to closely find a niche in the market, Energi is prepared to adapt and overcome all challenges for many years to come. Energi’s use case is that of a traditional cryptocurrency, such as Bitcoin. However, Energi’s strategy is to excel by avoiding the pitfalls of previous projects, while further utilizing and improving upon the most powerful ideas in the cryptocurrency space.

3. Coin Specs

Ticker: NRG

Block time: 1 minute.

Hashing Algorithm: Dagger-Hashimoto (similar to Ethereum).

Masternode requirements: 10,000 Energi.

Treasury cycle: Every 14 days.

Approximately 1 million Energi will be released per month. The allocations can be observed easily as “10/10/40/40.”

10% will go to the Energi Backbone.

10% to the PoS participants

40% to Masternodes.

40% to the Treasury.

Thus, for every block, allocations are: 2.28 Energi to the Backbone, 2.28 Energi to the PoS participants, 9.14 Energi to the Treasury, and 9.14 Energi to Masternodes.

Since Treasury allocations are paid in two-week cycles, they are made in lump sums of approximately 184,000 Energi every 14 days.

In order to allow for widespread distribution of Energi before Masternode payments begin, Masternode rewards will be delayed until day 150, this is to allow the airdrop campaign to be completed and ensure a large amount of Energi is spread out through the community. Until this point, Masternode rewards will be re-directed to the Treasury. Thus for the first 5 months, the Treasury will have approximately 368,000 Energi every two weeks (about 800k Energi per month). The airdrop campaign is designed to release ~4 million Energi to the community.

4. How to Get Started

  • Energi Official Website

https://www.energi.world/

  • Energi Earndrop Campaign

Energi chose not to premine and not to do an ICO. Instead, we will conduct multiple rounds of Earndrops to disperse rewards for people who engage with our community. In order for us to process your Earndrop info for you in a fast and efficient manner, we ask that you upload quality information. This includes clear non-mirrored pictures, readable text in images, and non-offensive usernames. Failure to upload quality information may lead to you not receiving any Earndrop rewards.

https://earndrop.energi.world/homepage

  • Social Media

Twitter: https://twitter.com/Energicrypto

Discord: https://discordapp.com/invite/sCtgNC3

Telegram: https://t.me/energicrypto

Reddit: https://www.reddit.com/r/energicryptocurrency/

Facebook: https://www.facebook.com/Energi-Cryptocurrency-195355164580336/

Medium: https://medium.com/energi

Steemit: https://steemit.com/@energi

  • Exchanges

KuCoin: https://www.kucoin.com/trade/NRG-BTC

DigiFinex: https://www.digifinex.com/en-ww/trade/BTC/NRG

Cryptopia: https://www.cryptopia.co.nz/Exchange/?market=NRG_BTC

CryptoBridge: https://wallet.crypto-bridge.org/market/BRIDGE.NRG_BRIDGE.BTC

Coin.Exchange: https://www.coinexchange.io/market/NRG/BTC

  • Energi Block Explorers

https://explore.energi.network/

https://explorer2.energi.network/#/

  • Wallet Downloads

https://www.energi.world/downloads

  • Proof-of-Stake Setup Guides

Local Staking: https://www.energi.world/staking/

Staking on VPS: https://www.energi.world/staking-on-vps/

  • Masternode Setup Guide

https://www.energi.world/masternode-setup/

5. FAQ

https://www.energi.world/faq/



[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


FindBitcoin.Cash to bring the best solution to find and rate merchants

Ladies and gentlemen and friends of Bitcoin Cash,

I am thrilled to announce that we have cleaned up a lot of the issues we had; login page is now fixed, spam has been cleaned up too. Now to really explain the vision and what we hope to achieve with this site.

FindBitcoinCash: the treasure hunt:

This is basically the geocaching part of the site. Members can load and hide paper wallets around the world, log it on the map, and showcase where they are. Be creative and have fun with this. We do hope, however that random people might stumble upon these wallets and use them as a stepping stone to learn about Bitcoin Cash through FindBitcoin.cash. The wallet will guide them to the site where they will learn to sweep it, and we will direct them towards community resources to learn more information about BCH.

Please feel free to comment if there is a resource you think I should post on to the site.

FindBitcoinCash: merchants:

We all know the importance of merchant integration in to our ecosystem. As a result, we strive to not only allow users to play with the FindBitcoinCash Treasure Hunt, but they can also find local merchants near them to #spendBCH. in the bottom right hand corner of the map there is a toggle to search merchants. in the future, I will be adding the ability for merchants to claim their listings and edit them as they see fit.

For your convenience, here is the link to add merchants

https://i.redd.it/vs2z8jjxo8w21.png

In addition, members of the site will have the ability to rate merchants, sort of like yelp does, and we look forward to expanding this section of the site as we go along.

Find Bitcoincash resources:

This is the final part of the site where we will share posts from our community, and resources for anyone who may have stumbled upon a wallet learn more about Bitcoin Cash.

I welcome all comments, suggestions and feedback from this awesome community!!

Huge thank you to everyone who has donated to the cause and to help us cover some expenses. If you'd like to donate, we thank you in advance:

Badgerwallet via Findbitcoin.cash, set at 100k sats because every satoshi helps :)

Address: bitcoincash:qznqfwlrfv2s6y5agmwf0zm8lmcqcf946gput954mm

QR Code:

https://i.redd.it/748ibfu8r8w21.png



[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


/r/Monero Weekly Discussion – May 04, 2019 - Use this thread for general chatter, basic questions, and if you're new to Monero

Index

  1. General questions
  2. Wallet: CLI & GUI
  3. Wallet: Ledger
  4. Nodes

1. General questions

Where can I download the Monero wallet?

There are multiple Monero wallets for a wide range of devices at your disposal. Check the table below for details and download links. Attention: for extra security make sure to calculate and compare the checksum of your downloaded files when possible.

Please note the following usage of the labels:

⚠️ - Relatively new and/or beta. Use wallet with caution.

☢️ - Closed source.


Desktop wallets

Wallet Device Description Download link
"Official" GUI / CLI Windows, macOS, Linux Default implementation maintained by the core team. Use this wallet to run a full node and obtain maximum privacy. Integrates with hardware wallets. Current version: 0.14.0.0 / 0.14.0.2. GetMonero.org
MyMonero Windows, macOS, Linux Lightweight wallet -- you don't need to download the blockchain and run a node. MyMonero was developed with the assistance of the core team. It also has web-based and iOS versions. MyMonero.com
Exodus Eden (Beta) Windows, macOS, Linux ⚠️ / Multi-asset wallet. Exodus.io
ZelCore Windows, macOS, Linux ⚠️ / Multi-asset wallet. It also has Android and iOS versions. Zeltrez.io
Guarda Windows, macOS, Linux ⚠️ ☢️ / Multi-asset wallet. Guarda.co

Mobile wallets

Wallet Device Description Download link
Monerujo Android Integrates with Ledger (hardware wallet). Website: https://www.monerujo.io/. Google Play / F-Droid / GitHub
MyMonero iOS Website: https://mymonero.com/ App Store
Cake Wallet iOS Website: https://cakewallet.io/ App Store
X Wallet iOS Website: https://xwallet.tech/ App Store
Edge Wallet Android / iOS Multi-asset wallet. Website: https://edge.app/ Google Play / App Store
ZelCore Android / iOS ⚠️ / Multi-asset wallet. Website: https://zelcore.io/ Google Play / App Store
Coinomi Android / iOS ⚠️ ☢️ / Multi-asset wallet. Website: https://www.coinomi.com/ Google Play / App Store
Moxi / Guarda Android / iOS ⚠️ ☢️ / Multi-asset wallet. Website: https://guarda.co/ Google Play / App Store

Web-based wallets

Wallet Description Link
MyMonero Web version of the MyMonero wallet. Web
XMRWallet Web wallet with TOR support. Web / Onion URL
Guarda Multi-asset wallet. Web

How long does it take for my balance to unlock?

Your balance is unlocked after 10 confirmations (which means 10 mined blocks). A block is mined approximately every two minutes on the Monero network, so that would be around 20 minutes.

How can I prove that I sent a payment?

The fastest and most direct way is by using the ExploreMonero blockchain explorer. You will need to recover the transaction key from your wallet (complete guide for GUI / CLI).

How do I buy Monero (XMR) with Bitcoin (BTC)?

There are dozens of exchanges that trade Monero against Bitcoin and other cryptocurrencies. Check out the list on CoinMarketCap and choose the option that suits you best.

How do I buy Monero (XMR) with fiat?

  • Kraken (USD and EUR): old-school, decent exchange. They might require your documents for verification and approval of your account.
  • LocalMonero: peer-to-peer exchange. They have pretty much everything as a payment method and they support hundreds of fiat options.

How can I quickly exchange my Monero (XMR) for Bitcoin (BTC)?

There are multiple ways to exchange your Monero for Bitcoin, but first of all, I'd like to remind you that if you really want to do your part for Monero, one of the simplest ways is to get in touch with your merchant/service provider and request for it to accept Monero directly as payment. Ask the service provider to visit the official website and our communication channels if he or she needs help with system integration.

That being said, the community has been recommending two services in particular, XMR.TO and MorphToken. These services are only recommendations and are operated by entities outside the control of the Monero Project. Be diligent.

How do I mine Monero? And other mining questions.

The correct place to ask questions and discuss the Monero mining scene is in the dedicated subreddit r/MoneroMining. That being said, you can find a list of pools and available mining software in the GetMonero.org website.


2. Wallet: CLI & GUI

Why I can't see my balance? Where is my XMR?

Before any action there are two things to check:

  1. Are you using the latest available version of the wallet? A new version is released roughly every 6 months, so make sure you're using the current release (compare the release on GetMonero.org with your wallet's version on Settings, under Debug info).
  2. Is your wallet fully synchronized? If it isn't, wait the sync to complete.

Because Monero is different from Bitcoin, wallet synchronization is not instant. The software needs to synchronize the blockchain and use your private keys to identify your transactions. Check in the lower left corner (GUI) if the wallet is synchronized.

You can't send transactions and your balance might be wrong or unavailable if the wallet is not synced with the network. So please wait.

If this is not a sufficient answer for your case and you're looking for more information, please see this answer on StackExchange.

How do I upgrade my wallet to the newest version?

This question is beautifully answered on StackExchange.

Why does it take so long to sync the wallet [for the first time]?

You have decided to use Monero's wallet and run a local node. Congratulations! You have chosen the safest and most secure option for your privacy, but unfortunately this has an initial cost. The first reason for the slowness is that you will need to download the entire blockchain, which is considerably heavy (+70 GB) and constantly growing. There are technologies being implemented in Monero to slow this growth, however it is inevitable to make this initial download to run a full node. Consider syncing to a device that has an SSD instead of an HDD, as this greatly impacts the speed of synchronization.

Now that the blockchain is on your computer, the next time you run the wallet you only need to download new blocks, which should take seconds or minutes (depending on how often you use the wallet).

I don't want to download the blockchain, how can I skip that?

The way to skip downloading the blockchain is connecting your wallet to a public remote node. You can follow this guide on how to set it up. You can find a list of public remote nodes on MoneroWorld.

Be advised that when using a public remote node you lose some of your privacy. A public remote node is able to identify your IP and opens up a range for certain attacks that further diminish your privacy. A remote node can't see your balance and it can't spend your XMR.

How do I restore my wallet from the mnemonic seed or from the keys?

To restore your wallet with the 25 word mnemonic seed, please see this guide.

To restore your wallet with your keys, please see this guide.


3. Wallet: Ledger

How do I generate a Ledger Monero Wallet with the GUI or CLI?

This question is beautifully answered on StackExchange. Check this page for the GUI instructions, and this page for the CLI instructions.


4. Nodes

How can my local node become a public remote node?

If you want to support other Monero users by making your node public, you can follow the instructions on MoneroWorld, under the section "How To Include Your Node On Moneroworld".

How can I connect my node via Tor?

This question is beautifully answered on StackExchange.



[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact:


[Help] Clearing out staking transactions Ledger Nano S

I'm trying to clear out my node rewards with Ledger Bitcoin Wallet and my Ledger Nano, I've got all the 42 ZEN from my secure nodes into one Ledger Account, but it's a mess. I do not understand how to clear the rewards of all my nodes and put them into one single address, I always ruin my last secure node ZEN address when I do the transactions trying to clear out.

I was checking the following guide to do so: Zen-Solutions - Sending Rewards

Could anyone give me a hand on this, it's getting really frustrating.

Edit: staking -> rewards



[Daily Discussion] Saturday, May 04, 2019

Thread topics include, but are not limited to:

  • General discussion related to the day's events
  • Technical analysis, trading ideas & strategies
  • Quick questions that do not warrant a separate post

Thread guidelines:

  • Be excellent to each other.
  • Do not make posts outside of the daily thread for the topics mentioned above.

Other ways to interact: