DigiByte flowers with Dandelion
I want to talk today about the implementation of Dandelion in to DigiByte, why it matters, how it works, and why you should care.
The DigiByte developers have been liaising with the creators of Dandelion and are looking at including this in to future versions of DigiByte Core. You can read a more technical overview of Dandelion here: https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki
What is Dandelion?
Dandelion helps to protect your physical privacy by making it significantly harder to identify where your transaction came from. This prevents people from using the IP address that a transaction came from to attempt to locate you. Dandelion does not make transactions private in the way that RingCT (Monero)or zkSNARKs (ZCash) would, however it does help DigiByte take a major step forward towards protecting the privacy and security of our users.
Dandelion is about protecting your location by making it difficult to ascertain from a transactions source IP Address.
Think of it like a default / built-in protection on the network-layer of the DigiByte blockchain so that people don’t need to rely on TOR or i2p (Though, Dandelion can work in tandem with TOR etc).
You see if somebody malicious was able to find your IP address, and they knew that you were sitting on half a million dollars worth of cryptocurrency (Not just DigiByte, but say also Bitcoin), then they could potentially use that in an attempt to physically track you down with the goal of stealing your computer, private keys and cryptocurrency.
Naturally nobody wants this, but it’s something to be mindful of and aware of the way that blockchains work. It’s also where Dandelion comes in as a solution.
What does Dandelion do differently?
Dandelion is an adjustment to the way that your transactions are sent using the DigiByte Core client.
Traditionally when you send a transaction, you tell all the people you’re connected to that you want to send from A to B. This goes in to what’s known as the “Mempool” (Memory pool), a sort of cloud / cluster of pending transactions. When a Miner finds a block, they incorporate these transactions in to their block, and get the transaction fees.
With Dandelion, you start by creating the “stem”, and send your transaction to just one other person who then relays the transaction. This second person has a 10% chance to “flower” the transaction and send it off in to the world, kind of similar to if you were to blow a dandelion and watch the fluff flying out into the world.
If they don’t flower the transaction, they add to the stem and send the transaction on to just one more person.
This is how the stem is created, as the transaction is expected to hop between a number of people, hiding the original IP address in the process.
This way, should somebody malicious look at the IP address used, they won’t be able to get any information about you.
Will this slow down DigiByte?
The DigiByte block timing will remain at 15 seconds, this is completely unaffected.
Dandelion does add some slight overhead to the transaction timing as the stem is created, as the transaction hops between person to person before being broadcast (Like the fluff being blown into the wind).
However, if we hypothesize a user creates and broadcasts a transaction traditionally at 13:00:00 and the next block is found at 13:00:12, the transaction has likely propagated through the network and will be included in the next block.
If we hypothesize a user creates a transaction with Dandelion implemented in DigiByte Core, at 13:00:00 also, and the stem takes 8 seconds to create before flowering at 13:00:08, and the next block is found at 13:00:12, the transaction would still be included in that next block.
The difference comes in to play if you were to broadcast the transaction, say, at 13:00:10, and the block is found at 13:00:12
For a traditionally created / broadcast transaction, it would likely be included, however the Dandelion transaction would still be in the stem phase at 13:00:12 and so would be included in the next block which is found at, say, 13:00:27.
This means the time for a transaction to be included in the blockchain has increased to 19 seconds in this scenario, even though blocks are still being found at 15 second intervals.
So in this scenario, presuming blocks are found at precisely 15 seconds, you would reach 6 confirmations after 92 seconds without Dandelion, but 107 seconds with Dandelion.
It’s an unknown in terms of the time taken for your transaction stem, to then flower, vs the timing of the next block.
We feel with DigiByte having 15 second block timings, this trade-off is significantly minimized compared to other blockchains with 2.5 minute or 10 minute block timings.
Is that the only down-side?
Yes, for most users we believe that the additional layer of protection of their IP address is a good trade-off vs the speed of a transaction being included in a block. The block timing remains the same afterwards.
It would mean that zero-conf transactions could take longer, however those are not things that users / businesses / entities should rely on regardless for a number of reasons.
We are looking at ways for this to optionally be mitigated in the event a user wanted to ensure their transaction was included in the blockchain as quickly as possible, potentially compromising on protecting their privacy. Effectively this would cut the stem length to nothing, and “flower” or “fluff” the transaction immediately. At this time though, the benefits or even the need for such a tweak are unknown, which is why we are looking to include Dandelion as a default option to ensure the broadest adoption.
Dandelion is almost fully backwards compatible. If at any stage during the stem creation, Dandelion comes across a ‘legacy’ node that doesn’t yet support it, the stem goes in to immediate flowering, with the legacy node basically ignoring the Dandelion improvements.
For this reason, Dandelion is most effective when more nodes on the network are using it, eventually with the goal that all nodes will support Dandelion.
The only aspect that is not fully compatible is “RBF” — “Replace by Fee” (BIP125). BIP125 is something DigiByte has ‘inherited’ from keeping up with Bitcoin Core, but is not something that DigiByte specifically needs or largely has a use for, predominantly due to our scaling blocks and faster block timings. In discussions with the authors of the Dandelion protocol, although they are working on a “lite” version that compromises between the privacy while still keeping RBF, we feel at this stage it best if we grandfather RBF and opt for a pure / ideal implementation of Dandelion.
Some may see that as a benefit, doing away with RBF. The necessity of RBF is far, far slimmer on DigiByte compared to Bitcoin regardless.
Will this make DigiByte a ‘privacy coin’?
We would say Dandelion represents a major shift of DigiByte moving to protect the privacy and security of users around the world. More privacy features will be adopted in the future as new threats arise. Dandelion will improve your physical locations privacy by masking your IP Address and helping prevent attackers from targeting address with large amounts of DGB, both in the digital and real-world.
However, this does not currently include Confidential Transactions as we want to maintain the immutability of the blockchain.
Everything else is still as it was, and you can still use the DigiByte Blockchain Explorers such as DigiExplorer as you have previously.
Who else is using Dandelion?
Right now we only know of ZCoin who implemented Dandelion in September 2018.
As we did with SegWit, DigiByte wants to continue to remain forward-thinking and to lead by example regarding protocol improvements.
When will this happen?
There is currently no ETA on the implementation going mainstream. We have however been testing builds and they are currently working on the DigiByte “mainnet”, based on the latest 6.17.2 release of DigiByte Core.
So what are we waiting for?
Well, we’re testing it obviously, before pushing it out to everyone.
When you’re dealing with millions / billions of dollars worth of peoples assets, you don’t want to move too fast and break things. There’s a fine balance to manage, where we are responsible with the network as it is, while still embracing new technology and being forward-thinking.
So we want your help to test it.
You can build it over here from the 6.17.3 tree:
We welcome any feedback over on Telegram: https://t.me/DigiByteDevelopers
We can also give you a few other IP’s of Dandelion nodes if you want to specifically connect to them as well.
When building, DigiByte 6.17.3 will enable Dandelion by default, however if you want the additional logging you need to launch with:
digibyte-qt -debug=dandelion
This will show you additional information in ~/.digibyte/debug.log about it starting with Dandelion being enabled, along with additional information about sending / receiving the Dandelion transactions, and the embargo timings too.
Once we’ve conducted further testing, taken more feedback from the community, and have concluded this is the best way forward, we’ll then look at getting this out as a formal release.
Work is still underway with Odocrypt in 7.17.1 which is separate to this, Odocrypt has not been included in 6.17.3.
