A Kademlia-inspired modification of Dandelion for use in Grin.
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.
"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.
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
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:
a ----> x ----> b
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:
a <---- x <---- b
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.