Dandelion transaction relay (BIP 156) #13947

MarcoFalke · Aug 12, 2018

The implementation of BIP 156 (Dandelion transaction relay) is done in three steps:

Add the protocol messages

dandeliontx, which contains a transaction serialized with all witness data
dandelionacc, which is always empty and only used to signal dandelion support to other peers

Shuffle dandelion stems

We shuffle a list of all peers that sent us the message that they accept dandelion txs (dandelionacc). This list can be used on demand by nodes that want to forward a dandelion transaction. (Actual receiving of dandelion txs is done in the next step).

Also, we add a command line option -dandelion, which can be used to opt out of all dandelion features.

Keep a cache of recent dandelion transactions

Dandelion transactions are never added to the global tx pool and only forwarded to one peer (the next hop in the stem). To guard against the next peer going offline, we keep a cache of recent dandelion transactions that are not yet fluffed (added to the mempool) or mined. Entries in this cache expire after some random timeout and transition to fluff phase.

MarcoFalke · Aug 12, 2018

This is completely untested, so TODO:

add tests
use dandelion relay for our wallet txs

practicalswift · Aug 12, 2018

practicalswift reviewed Aug 12, 2018

View changes

practicalswift · Aug 12, 2018

src/net.h

@@ -755,6 +778,10 @@ class CNode
    // Our address, as reported by the peer
    CService addrLocal;
    mutable CCriticalSection cs_addrLocal;
+
+    /** Our current dandelion destination */
+    CConnman::DandelionPeer* m_dandelion_destination /* GUARDED_BY(CConnman::cs_dandelion_peers) */ {nullptr};


Any drawbacks from uncommenting the GUARDED_BY(…) annotation?

The drawback was that it didn't compile for me

practicalswift · Aug 12, 2018

practicalswift reviewed Aug 12, 2018

View changes

practicalswift · Aug 12, 2018

Sign in to view

@@ -1027,6 +1031,12 @@ bool AppInitParameterInteraction()
        LogPrintf("Warning: nMinimumChainWork set below default value of %s\n", chainparams.GetConsensus().nMinimumChainWork.GetHex());
    }

+    {
+        const int64_t pct = gArgs.GetArg("-dandelion", DEFAULT_DANDELION_STEM_PERCENTAGE);
+        if (pct < 0 || 100 < pct) return InitError(_("-dandelion must be 0 or a percentage less than 100"));


Should -dandelion=100 generate an error message? From the error message it looks like it should, but not from the logic :-)

100% is allowed to always extend the stem by one hop. So the interval is [0, 100].

Then the error message should be -dandelion must be 0 or a percentage up to 100 or something equivalent?

DrahtBot · Aug 12, 2018

Note to reviewers: This pull request conflicts with the following ones:

#14032 (Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli)
#13946 (p2p: Clarify control flow in ProcessMessage by MarcoFalke)
#13743 (refactor: Replace std/boost::bind with lambda by ken2812221)
#13123 (net: Add Clang thread safety annotations for guarded variables in the networking code by practicalswift)
#10102 ([experimental] Multiprocess bitcoin by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

clodhopp · Aug 12, 2018

clodhopp reviewed Aug 12, 2018

View changes

clodhopp · Aug 12, 2018

doc/bips.md

@@ -33,6 +33,7 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.17.0**):
 * [`BIP 145`](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki): getblocktemplate updates for Segregated Witness as of **v0.13.0** ([PR 8149](https://github.com/bitcoin/bitcoin/pull/8149)).
 * [`BIP 147`](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki): NULLDUMMY softfork as of **v0.13.1** ([PR 8636](https://github.com/bitcoin/bitcoin/pull/8636) and [PR 8937](https://github.com/bitcoin/bitcoin/pull/8937)).
 * [`BIP 152`](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki): Compact block transfer and related optimizations are used as of **v0.13.0** ([PR 8068](https://github.com/bitcoin/bitcoin/pull/8068)).
+* [`BIP 156`](https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki): Dandelion transaction relay is supported as of **v0.18.0** ([PR 13947](https://github.com/bitcoin/bitcoin/pull/13947)).


Link https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki gives error 404 page not found.

@clodhopp that's because the BIP PR hasn't been merged, you can see it here: bitcoin/bips#703
Once merged, the link should work

sipa · Aug 12, 2018

This code doesn't seem to include a "stempool"; how does it deal with dandelion transactions that depend on other dandelion transactions? ATMP will fail for those.

MarcoFalke · Aug 12, 2018

This code doesn't seem to include a "stempool"; how does it deal with dandelion transactions that depend on other dandelion transactions? ATMP will fail for those.

Continued here https://botbot.me/freenode/bitcoin-core-dev/2018-08-12/?msg=103212266&page=2

sdaftuar · Aug 13, 2018

sdaftuar reviewed Aug 13, 2018

View changes

I just left some initial comments from a quick-read of the code. As discussed on IRC we still need to figure out what the right behavior is for transaction chains and replacement transactions (and combinations of the two), and generally how to prevent DoS attacks during stem routing.

If we use a stempool to address those issues, then I'm not sure I understand how we could share a stempool across multiple inbound peers without leaking dandelion routing information to an adversary (and if we have separate stempools for each inbound peer, then that sounds like a lot of overhead).

sdaftuar · Aug 13, 2018

src/init.cpp

        if (gArgs.SoftSetBoolArg("-whitelistrelay", false))
            LogPrintf("%s: parameter interaction: -blocksonly=1 -> setting -whitelistrelay=0\n", __func__);
+        if (gArgs.SoftSetBoolArg("-dandelion", false)) {


Do we use SoftSetBoolArg() like this elsewhere, on arguments that take numeric values? It was not clear to me that this worked until I saw that SoftSetBoolArg converts the false to std::string("0"). (Neat, though.)

Just to not mix up values, this should set 0 instead of false, even if false would be converted automatically to 0.

sdaftuar · Aug 13, 2018

Sign in to view

@@ -803,7 +847,19 @@ class CNode
        nRefCount--;
    }

+    /** If this peer is not yet connected or soon to be disconnected */
+    bool IsEphermal() const


nit: IsEphemeral

sdaftuar · Aug 13, 2018

Sign in to view

+    else if (strCommand == NetMsgType::TX_DANDELION) {
+        // Stop processing the transaction early if
+        // dandelion is disabled and peer is either not whitelisted or whitelistrelay is off
+        if (!CNode::IsDandelionEnabled()&& (!pfrom->fWhitelisted || !gArgs.GetBoolArg("-whitelistrelay", DEFAULT_WHITELISTRELAY))) {


Some IRC discussion around not extending whitelist-relay behavior further with dandelion processing:
https://botbot.me/freenode/bitcoin-core-dev/2018-08-13/?msg=103271568&page=3

sdaftuar · Aug 13, 2018

Sign in to view

+            return true;
+        }
+
+        if (pfrom->fWhitelisted && gArgs.GetBoolArg("-whitelistforcerelay", DEFAULT_WHITELISTFORCERELAY)) {


See above comment about dropping this behavior for whitelisted peers.

sdaftuar · Aug 13, 2018

src/protocol.h

+ * The dandelion tx message transmits a single transaction.
+ * @see https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki
+ */
+extern const char* TX_DANDELION;


I think in the past, we've usually bumped the protocol version when introducing new p2p messages so that we only send the new messages (like ACCEPT_DANDELION) to peers that are signaling that they've upgraded. Not sure how important that is...

Note that we'd never send a TX_DANDELION to a peer that never sent us ACCEPT_DANDELION in the first place. So I don't think this is an issue at all.

Perhaps my comment was not placed on the right line of this file; I was thinking of the dandelionacc message. With sendheaders and I think compact blocks, I believe we bumped the protocol version and only tried to send the new p2p messages (even for handshaking/negotiating the protocol to use) to peers with that higher version?

Good point. I think it is a lot easier to do this without enforcing a global network version bump.

Note that the dandelionacc message is properly read by all nodes that implement dandelion (regardless of their network protocol version) or choose to ignore that message. And for all other nodes (that are completely unaware of dandelion) they simply treat this as unknown message (once per connection) in their logs. I think this one debug log is not enough reason to go through the hassle of bumping the protocol version.

bitcoin/src/net_processing.cpp

Line 2942 in 63f8b01

LogPrint(BCLog::NET, "Unknown command \"%s\" from peer=%d\n", SanitizeString(strCommand), pfrom->GetId());

Why not a service bit?

sdaftuar · Aug 14, 2018

sdaftuar reviewed Aug 14, 2018

View changes

sdaftuar · Aug 14, 2018

src/net_processing.cpp

+        CValidationState state;
+        bool missing_inputs;
+        if (AcceptToMemoryPool(mempool, state, tx, &missing_inputs, nullptr /* lRemovedTxn */, false /* bypass_limits */, 0 /* nAbsurdFee */, true /* test_accept */)) {
+            RelayDandelionTransaction(mempool, pfrom, tx, msgMaker, connman);


I think we should queue transactions for relay to a peer, rather than doing a direct send as is done here. Otherwise transaction relay can fill up our send buffers and delay block relay.

Further our current transaction relay system batches transactions for relay and, at each broadcast time, we sort the to-be-relayed transactions for the purposes of prioritising transactions that have fewer ancestors and higher feerate. I think being able to prioritise transactions with higher feerate for relay is probably useful (to prevent low-feerate transactions from harming propagation times of higher feerate transactions).

it's also better for privacy against traffic analysis to batch things.

MarcoFalke · Aug 14, 2018

MarcoFalke reviewed Aug 14, 2018

View changes

MarcoFalke · Aug 14, 2018

Sign in to view

@@ -1908,6 +1967,11 @@ bool static ProcessMessage(CNode* pfrom, const std::string& strCommand, CDataStr
        State(pfrom->GetId())->fPreferHeaders = true;
    }

+    else if (strCommand == NetMsgType::ACCEPT_DANDELION) {
+        pfrom->m_accept_dandelion = true;
+        return true;


Should write something to debug log here.

stevenroose · Aug 20, 2018

stevenroose suggested changes Aug 20, 2018

View changes

stevenroose · Aug 20, 2018

Sign in to view

@@ -399,6 +399,7 @@ void SetupServerArgs()
    gArgs.AddArg("-bantime=<n>", strprintf("Number of seconds to keep misbehaving peers from reconnecting (default: %u)", DEFAULT_MISBEHAVING_BANTIME), false, OptionsCategory::CONNECTION);
    gArgs.AddArg("-bind=<addr>", "Bind to given address and always listen on it. Use [host]:port notation for IPv6", false, OptionsCategory::CONNECTION);
    gArgs.AddArg("-connect=<ip>", "Connect only to the specified node; -connect=0 disables automatic connections (the rules for this peer are the same as for -addnode). This option can be specified multiple times to connect to multiple nodes.", false, OptionsCategory::CONNECTION);
+    gArgs.AddArg("-dandelion", strprintf("Probability to extend the stem in Dandelion transaction relay by one hop (default: %d, 0 to disable dandelion)", DEFAULT_DANDELION_STEM_PERCENTAGE), false, OptionsCategory::CONNECTION);


A simple "probability" should a number between 0 and 1. The variable used as default and the code below suggest a percentage is used instead. I think it would make sense to document it as such as well.

I was thinking about this as well: normally I’d expect a probability parameter to be in the interval [0.0, 1.0]. Are we trying to be consistent with other parameters taking probabilities as [0, 100] here, or what is the rationale? :-)

If that is the case, it should at least be mentioned in the help line.

Probability in % to extend ..

stevenroose · Aug 20, 2018

src/init.cpp

        if (gArgs.SoftSetBoolArg("-whitelistrelay", false))
            LogPrintf("%s: parameter interaction: -blocksonly=1 -> setting -whitelistrelay=0\n", __func__);
+        if (gArgs.SoftSetBoolArg("-dandelion", false)) {


Just to not mix up values, this should set 0 instead of false, even if false would be converted automatically to 0.

stevenroose · Aug 20, 2018

Sign in to view

+{
+    from->m_dandelion_destination = nullptr;
+
+    if (!CNode::IsDandelionEnabled()) return;


This check should not be necessary, failing it means there's a bug. I'd suggest either using an assertion or something more severe than this or just removing the check.

stevenroose · Aug 20, 2018

src/net.h

@@ -317,6 +327,16 @@ class CConnman
    */
    int64_t PoissonNextSendInbound(int64_t now, int average_interval_seconds);

+    using DandelionPeer = std::pair<CNode*, /* use count */ unsigned>;


Please elaborate a bit more on the documentation of the integer.

Maybe it is better to create a struct? This integer will look much better with a name. It is very hard to read all those peer.first and peer.second

stevenroose · Aug 20, 2018

src/net.h

 /** Time between pings automatically sent out for latency probing and keepalive (in seconds). */
 static const int PING_INTERVAL = 2 * 60;
 /** Time after which to disconnect, after waiting for a ping response (or inactivity). */
 static const int TIMEOUT_INTERVAL = 20 * 60;
 /** Run the feeler connection loop once every 2 minutes or 120 seconds. **/
 static const int FEELER_INTERVAL = 120;
+/** Pick new dandelion peers once every 10 minutes or 600 seconds. */
+static constexpr int INTERVAL_DANDELION = 600;


The convention seems to be XXX_INTERVAL instead of INTERVAL_XXX.

Also, why 10 minutes?

@stevenroose as per the BIP: https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki#periodic-dandelion-route-shuffling (the value suggested in the BIP is best discussed on the bitcoin-dev mailinglist)

@Sjors this would do:
/** As per BIP156, pick new dandelion peers once every 10 minutes or 600 seconds. */

stevenroose · Aug 20, 2018

src/net.h


+/** Default for -dandelion stem percentage */
+static constexpr int64_t DEFAULT_DANDELION_STEM_PERCENTAGE = 90;


Why 90? This is like the most important parameter of the dandelion algorithm, I think it deserves some motivation..

@stevenroose the BIP specifies that:

When relaying a Dandelion transaction along a Dandelion route, there is a 10% chance that the Dandelion transaction becomes a typical Bitcoin transaction and is therefore relayed via diffusion.

@Sjors So I'd suggest referring to the BIP in the comment of that variable.

What I'm trying to say with this comments is that this is supposed to be an implementation of the BIP, so it should refer to the BIP for logic/params etc. It has happened too often that a BIP is just a description of the implementation.

stevenroose · Aug 20, 2018

src/net_processing.cpp

    });
 }

+static void FluffTransaction(CTxMemPool& tx_pool, const CNode* from, const CTransactionRef& ptx, CConnman* connman)
+{
+    LogPrint(BCLog::DANDELION, "fluff\n");


Perhaps mention txid?

stevenroose · Aug 20, 2018

src/net_processing.cpp

+static void RelayDandelionTransaction(CTxMemPool& tx_pool, CNode* node_from, const CTransactionRef& ptx, const CNetMsgMaker& msg_maker, CConnman* connman)
+{
+    bool fluff = GetRand(100 * 100) / 100. >= CNode::m_dandelion_stem_pct_threshold;
+    if (fluff) return FluffTransaction(tx_pool, node_from, ptx, connman);


Should this check also be made for the wallet's own transactions? Or should a forced non-fluff be done in that case?

stevenroose · Aug 20, 2018

Sign in to view

+        }
+
+        LogPrint(BCLog::DANDELION, "dandelion relay to peer=%d\n", dest->GetId());
+        connman->PushMessage(dest, msg_maker.Make(DANDELION_SEND_FLAGS, NetMsgType::TX_DANDELION, *ptx));


Wrong indentation since after return.

stevenroose · Aug 20, 2018

src/protocol.h

+ * The dandelion tx message transmits a single transaction.
+ * @see https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki
+ */
+extern const char* TX_DANDELION;


Why not a service bit?

DrahtBot · Aug 25, 2018

Needs rebase

Sjors · Sep 2, 2018

Sjors reviewed Sep 2, 2018

View changes

I don't know how to test this without an (experimental) RPC method to broadcast a Dandelion transaction. It does compile on macOS, seems to recognize other peers with this feature and occasionally logs "Dandelion: Shuffle Dandelion Destinations".

Same question as @stevenroose: why a dandelionacc message rather than a service bit? If we use a service bit, then it would be nice to have an updated version of the DNS Seeder, so it's easier test this in the wild. I'd be happy to update my testnet seed for that.

Neither dandeliontx or dandelionacc are mentioned and/or specified in the BIP. Is that because the BIP is still work in progress?

Needs functional tests.

Maybe add a dandelion bool field to getpeerinfo?

Sjors · Sep 2, 2018

src/net.h


+/** Default for -dandelion stem percentage */
+static constexpr int64_t DEFAULT_DANDELION_STEM_PERCENTAGE = 90;


@stevenroose the BIP specifies that:

When relaying a Dandelion transaction along a Dandelion route, there is a 10% chance that the Dandelion transaction becomes a typical Bitcoin transaction and is therefore relayed via diffusion.

Sjors · Sep 2, 2018

src/net.h

 /** Time between pings automatically sent out for latency probing and keepalive (in seconds). */
 static const int PING_INTERVAL = 2 * 60;
 /** Time after which to disconnect, after waiting for a ping response (or inactivity). */
 static const int TIMEOUT_INTERVAL = 20 * 60;
 /** Run the feeler connection loop once every 2 minutes or 120 seconds. **/
 static const int FEELER_INTERVAL = 120;
+/** Pick new dandelion peers once every 10 minutes or 600 seconds. */
+static constexpr int INTERVAL_DANDELION = 600;


@stevenroose as per the BIP: https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki#periodic-dandelion-route-shuffling (the value suggested in the BIP is best discussed on the bitcoin-dev mailinglist)

scravy · Sep 19, 2018

Shouldn't the functional test from the reference implementation (dandelion-org@d043e36#diff-21ab9447686d819eeeb7668ce8011e0d) run more-or-less unchanged on top of this branch?

rodasmith · Sep 30, 2018

rodasmith reviewed Sep 30, 2018

View changes

rodasmith · Sep 30, 2018

src/net.cpp

+            m_nodes_dandelion.clear();
+            for (CNode* node : all_nodes) {
+                // Ignore inbound nodes
+                if (node->fInbound) continue;


Why ignore inbound nodes? Does this mean non-listening dandelion nodes send only their own transactions and that the peer who receives such will know with undeniable certainty that the non-listening node initiated the transaction?

Inbound nodes are much more likely to be snooping peers.

While that is true, aren't there solutions that do not make dandelion break firewalled nodes' privacy? For example, send only to outgoing peers if you originated the transaction, but send to incoming as well for forwarded txes? Perhaps weigh the outgoing peers more heavily than incoming peers when selecting a random peer to forward to (either by assigning a weight to individual peers based on incoming/outgoing status, or by first randomly selecting the outgoing or incoming pool with a fixed weighting before selecting a peer from whichever pool).

jb55 · Oct 3, 2018

These commits could be documented more in general, I'm finding it hard to review when there are no descriptions about what is being implemented.

AM5800 · Oct 9, 2018

It has been mentioned several times that common stempool might leak dandelion routing information to an adversary. Can someone help me understand how exactly?

Also, what is the current status of this issue? I would like to offer some help. For example with tests

scravy · Oct 9, 2018

@jb55 BIP156 should explain a lot of things.

jb55 · Oct 9, 2018

@scravy I'm more interested in documentation of the implementation itself, how each commit relates to a part of the bip, etc. It's much harder to verify an implementation without that, especially with important privacy/security features. I don't think we should be making it harder on reviewers than it needs to be.

stevenroose · Oct 9, 2018

@jb55 Totally agree. All the non-trivial pieces of code should explain themselves, refer to the BIP when relevant, etc..

AM5800 · Oct 25, 2018

AM5800 reviewed Oct 25, 2018

View changes

AM5800 · Oct 25, 2018

src/net_processing.cpp

    });
 }

+static void FluffTransaction(CTxMemPool& tx_pool, const CNode* from, const CTransactionRef& ptx, CConnman* connman)


I was wandering... FluffTransaction is logically equivalent to receiving a transaction, right?
Then shouldn't we also execute all this code on fluff?

AM5800 · Oct 25, 2018

AM5800 reviewed Oct 25, 2018

View changes

AM5800 · Oct 25, 2018

src/net.cpp

+
+    if (CNode::IsDandelionEnabled()) {
+        // Shuffle dandelion destinations
+        m_thread_shuffle_dandelion = std::thread(&TraceThread<std::function<void()>>, "dandelionshuff", [&] { ThreadShuffleDandelionDestinations(); });


When I tried this PR in action - dandelion was turned off for the first epoch. I believe this happens because we do the very first shuffle when there are no connections. Maybe the first shuffle should be delayed until someone connects?

AM5800 · Oct 25, 2018

AM5800 reviewed Oct 25, 2018

View changes

AM5800 · Oct 25, 2018

src/net_processing.cpp

+        from->m_cache_expiry.pop();
+    } while (from->m_cache_expiry.top() < now_millis);
+
+    for (auto it = from->m_cache_dandelion.cbegin(); it != from->m_cache_dandelion.cend(); ++it) {


An idea: if you define m_cache_expiry as std::map<int64_t, CTransactionRef> - you will get the same 'Constant time lookup' but you won't need to walk the whole cache - expired transactions are already available

AM5800 · Oct 25, 2018

AM5800 reviewed Oct 25, 2018

View changes

AM5800 · Oct 25, 2018

src/net_processing.cpp

+    // Dandelion relay (at least one hop)
+    const int64_t now_micros = GetTimeMicros();
+    const int64_t expiry = now_micros + EXPIRE_DANDELION_CACHE * 1000 * 1000 + PoissonNextSend(now_micros, EXPIRE_DANDELION_CACHE_AVG_ADD);
+    node_from->m_cache_dandelion.emplace(std::make_pair(ptx->GetWitnessHash(), std::make_pair(ptx, expiry)));


Nit:
node_from->m_cache_dandelion.emplace(ptx->GetWitnessHash(), std::make_pair(ptx, expiry))
does absolutely the same, but shorter.

riclas · Feb 4, 2019

I believe this explanation of the DDoS possibilities on Dandelion by @sdaftuar belongs here:
https://bitcoin.stackexchange.com/questions/81503/what-is-the-tradeoff-between-privacy-and-implementation-complexity-of-dandelion

regarding option b), maybe dynamically adjusting stem % according to fullness of the stempool/cache could be a solution? at worst, we would fluff all the time just like a regular tx spam attack.

protocol: Add BIP 156 message types

8c27c3b

MarcoFalke added the P2P label Aug 12, 2018

MarcoFalke added this to the 0.18.0 milestone Aug 12, 2018

MarcoFalke added the Feature label Aug 12, 2018

This was referenced Aug 12, 2018

Merged

p2p: Clarify control flow in ProcessMessage #13946

Merged

refactor: Replace boost::bind with std::bind #13743

logging: Add BCLog::DANDELION

3c29217

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch 3 times, most recently Aug 14, 2018

doc: Dandelion transaction relay (BIP 156)

c5aba5c

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch 4 times, most recently Aug 15, 2018

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch 3 times, most recently Aug 21, 2018

p2p: Keep cache of recent Dandelion transactions for stem expiry

Loading status checks…

8b533b2

net: Add thread to shuffle potential dandelion stems

bbe290e

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch to 8b533b2 Aug 21, 2018

DrahtBot referenced this pull request Aug 23, 2018
Open
Add p2p layer encryption with ECDH/ChaCha20Poly1305 #14032
0 of 1 task complete

DrahtBot added the Needs rebase label Aug 25, 2018

thothd referenced this pull request Sep 14, 2018
Closed
Dandelion (BIP 156) #100

MarcoFalke removed this from the 0.18.0 milestone Dec 3, 2018

bitcoin/bitcoin

Join GitHub today

Dandelion transaction relay (BIP 156) #13947

Conversation

MarcoFalke commented Aug 12, 2018 • edited

Add the protocol messages

Shuffle dandelion stems

Keep a cache of recent dandelion transactions

This comment has been minimized.

MarcoFalke commented Aug 12, 2018

practicalswift reviewed Aug 12, 2018 View changes

This comment has been minimized.

This comment has been minimized.

MarcoFalke added the P2P label Aug 12, 2018

MarcoFalke added this to the 0.18.0 milestone Aug 12, 2018

MarcoFalke added the Feature label Aug 12, 2018

practicalswift reviewed Aug 12, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

DrahtBot commented Aug 12, 2018 • edited

This was referenced Aug 12, 2018

clodhopp reviewed Aug 12, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sipa commented Aug 12, 2018

This comment has been minimized.

MarcoFalke commented Aug 12, 2018

sdaftuar reviewed Aug 13, 2018 View changes

sdaftuar left a comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sdaftuar reviewed Aug 14, 2018 View changes

This comment has been minimized.

This comment has been minimized.

MarcoFalke reviewed Aug 14, 2018 View changes

This comment has been minimized.

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch 3 times, most recently Aug 14, 2018

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch 4 times, most recently Aug 15, 2018

stevenroose suggested changes Aug 20, 2018 View changes

This comment has been minimized.

This comment has been minimized.

practicalswift Aug 20, 2018 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch 3 times, most recently Aug 21, 2018

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch to 8b533b2 Aug 21, 2018

DrahtBot referenced this pull request Aug 23, 2018

This comment has been minimized.

DrahtBot commented Aug 25, 2018

DrahtBot added the Needs rebase label Aug 25, 2018

Sjors reviewed Sep 2, 2018 View changes

Sjors left a comment

This comment has been minimized.

This comment has been minimized.

MarcoFalke commented Aug 12, 2018 •

edited

practicalswift reviewed Aug 12, 2018

View changes

practicalswift reviewed Aug 12, 2018

View changes

DrahtBot commented Aug 12, 2018 •

edited

clodhopp reviewed Aug 12, 2018

View changes

sdaftuar reviewed Aug 13, 2018

View changes

sdaftuar reviewed Aug 14, 2018

View changes

MarcoFalke reviewed Aug 14, 2018

View changes

stevenroose suggested changes Aug 20, 2018

View changes

practicalswift Aug 20, 2018 •

edited

MarcoFalke force-pushed the MarcoFalke:Mf1804-dandelion branch to `8b533b2` Aug 21, 2018

Sjors reviewed Sep 2, 2018

View changes

rodasmith reviewed Sep 30, 2018

View changes

AM5800 reviewed Oct 25, 2018

View changes