A Kademlia-inspired modification of
Dandelion for use in Grin.
What
On boot and restart, Grin nodes pick a random 256-bit node id which is broadcast to
their peers.
Upon receiving a block, a new epoch begins if block_height % 10 == 0.
The epoch id is the 256-bit blake2b hash of the block hash of the block that started
the epoch. (I.E. the double blake2b hash of the block header.)
At the start of each epoch, every node:
-
Calculates the relay weight of itself and all peers using the formula:
relay_weight = peer_id xor epoch_id. Relay weight is interpreted as a 256 bit
unsigned integer.
-
Selects the node among itself and all peers with the highest relay weight as the
relay target.
-
Determines that it is in stem mode if the relay target is a peer, and in
fluff mode if the relay target is itself.
Then, for every stem transaction received:
-
If it is in stem mode, it immediately relays it to its relay target.
-
If it is in fluff mode, it aggregates transactions until its next patience timer
expires, then broadcast them.
Why
"Heavy" peers will naturally be chosen for relay targets, creating agreed-upon stem paths
and fluff sinks, and leading to more opportunities for transaction aggregation.
Notes
-
In a well-connected network, one node may be the sink for all transactions during a
given epoch, and thus see all unaggregated transactions during the epoch. It may thus be
desirable to stick to random mode selection as in Dandelion++, so as to break up stem paths
with randomly selected fluff sinks.
-
If block hashes are used directly as the epoch ID, peers could select peer IDs with a
large number of leading 1s, thus biasing relay target selection towards themselves. Thus,
we take the double blake2b hash of the block header as the epoch ID.
-
Since the epoch ID is known by all, a node could pick node IDs that had high relay
weight during that epoch. To provent this, if a node connects to a new peer it should use a
randomly assigned peer ID for the current epoch.
-
Should this modification be called Kademlion, or
Objective-Dandelion?
-
Thanks to Antioch Peverell for the clear description of Dandelion++
whose language I shamelessly copied.
Lighting Network payment channels could be established between users and exchanges to
speed the transfer of funds.
This would be a huge boon, moving many on-chain deposit and withdrawal transactions
off-chain, but is possibly only the beginning.
Since Lightning Network payments can span different blockchains, an exchange could use a
cross-chain Lightning node to expose its internal order book to external entities.
As an example, imagine that an exchange has an LTC/BTC trading pair and wants to allow
non-exchange users to fill the orders in their order book.
The exchange runs a lightning node with a BTC channel and an LTC channel:
x: exchange node
a: third party node
b: third party node
<->: payment channel
BTC LTC
a <---> x <---> b
The exchange dynamically sets the exchange rates across the channels based on their
current best bid, best ask, and fee schedule.
With a best ask of 0.6 and a 1% fee, the exchange sets the BTC→LTC exchange rate like
so:
BTC LTC
a ----> x ----> b
0.606 1.000
When a payment is routed across the channels in this direction, LTC sell orders are
filled.
With a best bid of 0.4 and a 1% fee, the exchange sets the exchange rate on the channel in
the LTC→BTC direction like so:
BTC LTC
a <---- x <---- b
0.400 1.010
A payment routed in this direction fills LTC buy orders.
In this way, exchanges can expose their internal order book externally and trustlessly.
Anyone who wishes to make cross-chain Lightning Network payments will discover and travel
over these routes with no special effort required by the exchange, assuming that their rates
are competitive. Also, it’s likely that third parties will appear whose sole purpose is to
search the Lightning Network for arbitrage loops and travel them until they are exhausted,
thus bridging multiple exchanges when their order books cross.
IOTA is a cryptocurrency targeting the internet of things. It purports to be scalable,
decentralized, and feeless. Unfortunately it is none of those things.
In this article I attempt to summarize the numerous technical, social, and ethical
problems surrounding the IOTA project, The IOTA Foundation, and the IOTA developers.
Investing in cryptocurrencies is not the same as buying simple equity in a company.
Although each company has a different business model, they and the equity they issue are
largely structurally homogeneous. They hold their monies in banks, pay for their expenses with
wire transfers and cheques, follow prescribed rules of accounting, and issue stock that
operates according to well understood rules. This is not to say that said practices are good or
bad. They are simply a known factor.
Cryptocurrencies and tokens, however, are structurally heterogeneous. They have different
codebases, modes of operation, levels of complexity, and security models. Although broadly
lumped into the same category, they can, by the nature of these differences, have almost
nothing in common.
Investing in one is like buying stock in a company with novel business models, banking
practices, and accounting methods, and furthermore whose stock is issued under a bespoke scheme
and follows unique trading rules.
Accordingly, a much, much greater level of care is required when making such investments. If
any one of these novel mechanisms fail, your investment may go up in billowing smoke and flames
overnight.
This is not to say that you should completely avoid cryptocurrencies and tokens, just, you
know, do your homework.